ECH in DNS: Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings
How a server publishes its Encrypted ClientHello settings in DNS so clients can find them before connecting.
Schwartz, B., Bishop, M., and E. Nygren, "Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings", RFC 9848, DOI 10.17487/RFC9848, March 2026, <https://www.rfc-editor.org/info/rfc9848>.
@misc{rfc9848,
series = {Request for Comments},
number = 9848,
howpublished = {RFC 9848},
publisher = {RFC Editor},
doi = {10.17487/RFC9848},
url = {https://www.rfc-editor.org/info/rfc9848},
author = {B. Schwartz and M. Bishop and E. Nygren},
title = {{Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings}},
pagetotal = 9,
year = 2026,
month = mar,
} RFC text
Contents
Internet Engineering Task Force (IETF) B. Schwartz
Request for Comments: 9848 Meta Platforms, Inc.
Category: Standards Track M. Bishop
ISSN: 2070-1721 E. Nygren
Akamai Technologies
March 2026
Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings
Abstract
To use TLS Encrypted ClientHello (ECH), the client needs to learn the
ECH configuration for a server before it attempts a connection to the
server. This specification provides a mechanism for conveying the
ECH configuration information via DNS, using a SVCB or HTTPS resource
record (RR).
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9848.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents
1. Overview
2. Terminology
3. SvcParam for ECH Configuration
4. Requirements for Server Deployments
5. Requirements for Client Implementations
5.1. Disabling Fallback
5.2. ClientHello Construction
5.3. Performance Optimizations
6. Interaction with HTTP Alt-Svc
7. Examples
8. Security Considerations
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Authors' Addresses
1. Overview
The Service Bindings framework [SVCB] allows server operators to
publish a detailed description of their service in the Domain Name
System (DNS) (see [RFC1034] and [BCP219]) using SVCB or HTTPS
records. Each SVCB record describes a single "alternative endpoint"
and contains a collection of "SvcParams" that can be extended with
new kinds of information that may be of interest to a client.
Clients can use the SvcParams to improve the privacy, security, and
performance of their connection to this endpoint.
This specification defines a new SvcParam to enable the use of TLS
Encrypted ClientHello [ECH] in TLS-based protocols. This SvcParam
can be used in SVCB, HTTPS, or any future SVCB-compatible DNS records
and is intended to serve as the primary bootstrap mechanism for ECH.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. SvcParam for ECH Configuration
The "ech" SvcParamKey conveys the ECH configuration of an alternative
endpoint. It is applicable to all schemes that use TLS-based
protocols (including DTLS [RFC9147] and QUIC version 1 [RFC9001])
unless otherwise specified.
In wire format, the value of the parameter is an ECHConfigList
(Section 4 of [ECH]), including the redundant length prefix. In
presentation format, the value is the ECHConfigList in Base 64
encoding (Section 4 of [RFC4648]). Base 64 is used here to simplify
integration with TLS server software. To enable simpler parsing,
this SvcParam MUST NOT contain escape sequences.
This example uses line wrapping per [RFC8792].
ech="AEj+DQBEAQAgACAdd+scUi0IYFsXnUIU7ko2Nd9+F8M26pAGZVpz/KrWPgAEAAE\
AAWQVZWNoLXNpdGVzLmV4YW1wbGUubmV0AAA="
Figure 1: ECH SvcParam with a public_name of "ech-sites.example.net"
4. Requirements for Server Deployments
When publishing a record containing an "ech" parameter, the publisher
MUST ensure that all IP addresses of TargetName correspond to servers
that have access to the corresponding private key or are
authoritative for the public name. (See Sections 6.1.7 and 8.1.1 of
[ECH] for requirements related to the public name.) Otherwise,
connections will fail entirely.
These servers SHOULD support a protocol version that is compatible
with ECH. At the time of writing, the compatible versions are TLS
1.3, DTLS 1.3, and QUIC version 1. If the server does not support a
compatible version, each connection attempt will have to be retried,
delaying the connection and wasting resources.
5. Requirements for Client Implementations
This section describes client behavior in using ECH configurations
provided in SVCB or HTTPS records.
5.1. Disabling Fallback
The SVCB-optional client behavior specified in Section 3 of [SVCB]
permits clients to fall back to a direct connection if all SVCB
options fail. This behavior is not suitable for ECH, because
fallback would negate the privacy benefits of ECH. Accordingly, ECH-
capable, SVCB-optional clients MUST switch to SVCB-reliant connection
establishment if SVCB resolution succeeded (as defined in Section 3
of [SVCB]) and all alternative endpoints have an "ech" SvcParam.
5.2. ClientHello Construction
When ECH is in use, the TLS ClientHello is divided into an
unencrypted "outer" and an encrypted "inner" ClientHello. The outer
ClientHello is an implementation detail of ECH, and its contents are
controlled by the ECHConfig in accordance with [ECH]. The inner
ClientHello is used for establishing a connection to the service, so
its contents may be influenced by other SVCB parameters. For
example, the requirements related to Application-Layer Protocol
Negotiation (ALPN) protocol identifiers in Section 7.1.2 of [SVCB]
apply only to the inner ClientHello. Similarly, it is the inner
ClientHello whose Server Name Indication (SNI) identifies the desired
service.
5.3. Performance Optimizations
Prior to retrieving the SVCB records, the client does not know
whether they contain an "ech" parameter. As a latency optimization,
clients MAY prefetch DNS records that will only be used if this
parameter is not present (i.e., only in SVCB-optional mode).
The "ech" SvcParam alters the contents of the TLS ClientHello if it
is present. Therefore, clients that support ECH MUST NOT issue any
TLS ClientHello until after SVCB resolution has completed. (See
Section 5.1 of [SVCB].)
6. Interaction with HTTP Alt-Svc
HTTP clients that implement both HTTP Alt-Svc [RFC7838] and the HTTPS
record type [SVCB] can use them together, provided that they only
perform connection attempts that are "consistent" with both sets of
parameters (Section 9.3 of [SVCB]). At the time of writing, there is
no defined parameter related to ECH for Alt-Svc. Accordingly, a
connection attempt that uses ECH is considered "consistent" with an
Alt-Svc field value that does not mention ECH.
Origins that publish an "ech" SvcParam in their HTTPS record SHOULD
also publish an HTTPS record with the "ech" SvcParam for every alt-
authority offered in its Alt-Svc field values. Otherwise, clients
might reveal the name of the server in an unencrypted ClientHello to
an alt-authority.
If all HTTPS records for an alt-authority contain "ech" SvcParams,
the client MUST adopt SVCB-reliant behavior (as in Section 5.1) for
that resource record set (RRSet). This precludes the use of certain
connections that Alt-Svc would otherwise allow, as discussed in
Section 9.3 of [SVCB].
7. Examples
$ORIGIN simple.example. ; Simple example zone
@ 300 IN A 192.0.2.1
AAAA 2001:db8::1
HTTPS 1 . ech=ABC...
www 300 IN A 192.0.2.1
AAAA 2001:db8::1
HTTPS 1 . ech=ABC...
Figure 2: Simple Example Zone with the Same Configuration on the
Apex and Web Domain
The example above is compatible with clients that do or do not
support HTTPS records.
$ORIGIN heterogeneous.example. ; Example zone with 2 pools of servers
pool1 300 IN A 192.0.2.1
AAAA 2001:db8:1::a
pool2 300 IN A 192.0.2.2
AAAA 2001:db8:2::a
service 300 IN SVCB 1 pool1 ech=ABC...
SVCB 1 pool2 ech=DEF...
A 192.0.2.1
A 192.0.2.2
AAAA 2001:db8:1::a
AAAA 2001:db8:2::a
Figure 3: Service That Allows Clients to Choose Between Two
Server Pools with Different ECH Configurations
$ORIGIN cdn.example. ; CDN operator zone
pool 300 IN A 192.0.2.1
AAAA 2001:db8::1
HTTPS 1 . ech=ABC...
$ORIGIN customer.example. ; CDN customer's zone
@ 3600 IN HTTPS 0 pool.cdn.example.
; Apex IP records for compatibility with clients that do not support
; HTTPS records.
@ 300 IN A 192.0.2.1
AAAA 2001:db8::1
www 300 IN CNAME pool.cdn.example.
Figure 4: ECH Usage Pattern for an Aliasing-Based CDN
$ORIGIN secret.example. ; High confidentiality zone
www 3600 IN HTTPS 1 backend ech=ABC... mandatory=ech
backend 300 IN A 192.0.2.1
AAAA 2001:db8::1
Figure 5: A Domain That is Only Reachable Using ECH
$ORIGIN cdn1.example. ; First CDN operator zone
pool 300 IN A 192.0.2.1
AAAA 2001:db8::1
HTTPS 1 . ech=ABC...
$ORIGIN cdn2.example. ; Second CDN operator zone
pool 300 IN A 192.0.2.2
AAAA 2001:db8::2
HTTPS 1 . ech=DEF...
;; Multi-CDN customer zone (version 1)
$ORIGIN customer.example.
@ 3600 IN HTTPS 0 pool.cdn1.example.
; Apex IP records for compatibility with clients that do not support
; HTTPS records.
@ 300 IN A 192.0.2.1
AAAA 2001:db8::1
www 3600 IN CNAME pool.cdn1.example.
;; Multi-CDN customer zone (version 2)
@ 3600 IN HTTPS 0 pool.cdn2.example.
@ 300 IN A 192.0.2.2
AAAA 2001:db8::2
www 3600 IN CNAME pool.cdn2.example.
Figure 6: Multi-CDN Configuration Using Server-Side Selection
$ORIGIN dns.example. ; DNS server example.
@ 3600 IN A 192.0.2.1
AAAA 2001:db8::1
HTTPS 1 . ech=ABC... alpn=h3 dohpath=/q{?dns}
_dns 3600 IN SVCB 1 @ ech=ABC... alpn=dot,doq,h3 dohpath=/q{?dns}
Figure 7: Example of a DNS Server That Supports ECH
8. Security Considerations
A SVCB RRSet containing some RRs with "ech" and some without is
vulnerable to a downgrade attack: A network intermediary can block
connections to the endpoints that support ECH, causing the client to
fall back to a non-ECH endpoint. This configuration is NOT
RECOMMENDED, but it may be unavoidable when combining endpoints from
different providers or conducting a staged rollout. Zone owners who
do use such a mixed configuration SHOULD mark the RRs with "ech" as
more preferred (i.e., lower SvcPriority value) than those without, in
order to maximize the likelihood that ECH will be used in the absence
of an active adversary.
When Encrypted ClientHello is deployed, the inner TLS SNI is
protected from disclosure to attackers. However, there are still
many ways that an attacker might infer the SNI. Even in an idealized
deployment, ECH's protection is limited to an anonymity set
consisting of all the ECH-enabled server domains supported by a given
client-facing server that share an ECH configuration. An attacker
who can enumerate this set can always guess the encrypted SNI with a
probability of at least 1/K, where K is the number of domains in the
set. Some attackers may achieve much greater accuracy using traffic
analysis, popularity weighting, and other mechanisms (e.g., see
[CLINIC]).
ECH ensures that TLS does not disclose the SNI, but the same
information is also present in the DNS queries used to resolve the
server's hostname. This specification does not conceal the server
name from the DNS resolver. If DNS messages are sent between the
client and resolver without authenticated encryption, an attacker on
this path can also learn the destination server name. A similar
attack applies if the client can be linked to a request from the
resolver to a DNS authority.
An attacker who can prevent SVCB resolution can deny clients any
associated security benefits. A hostile recursive resolver can
always deny service to SVCB queries, but network intermediaries can
often prevent resolution as well, even when the client and recursive
resolver validate DNSSEC [RFC9364] and use a secure transport. These
downgrade attacks can prevent a client from being aware that "ech" is
configured, which could result in the client sending the ClientHello
in cleartext. To prevent downgrades, Section 3.1 of [SVCB]
recommends that clients abandon the connection attempt when such an
attack is detected.
9. IANA Considerations
IANA has modified the entry for "ech" in the "DNS SVCB Service
Parameter Keys (SvcParamKeys)" registry in the "DNS Service Bindings
(SVCB)" registry group as follows:
+========+======+====================+============+===========+
| Number | Name | Meaning | Change | Reference |
| | | | Controller | |
+========+======+====================+============+===========+
| 5 | ech | TLS Encrypted | IETF | RFC 9848 |
| | | ClientHello Config | | |
+--------+------+--------------------+------------+-----------+
Table 1
10. References
10.1. Normative References
[ECH] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", RFC 9849, DOI 10.17487/RFC9849,
March 2026, <https://www.rfc-editor.org/info/rfc9849>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/info/rfc9364>.
[SVCB] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (SVCB and HTTPS
Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
November 2023, <https://www.rfc-editor.org/info/rfc9460>.
10.2. Informative References
[BCP219] Best Current Practice 219,
<https://www.rfc-editor.org/info/bcp219>.
At the time of writing, this BCP comprises the following:
Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
[CLINIC] Miller, B., Huang, L., Joseph, A., and J. Tygar, "I Know
Why You Went to the Clinic: Risks and Realization of HTTPS
Traffic Analysis", Lecture Notes in Computer Science, vol.
8555, pp. 143-163, DOI 10.1007/978-3-319-08506-7_8, 2014,
<https://doi.org/10.1007/978-3-319-08506-7_8>.
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>.
[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/info/rfc9001>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/info/rfc9147>.
Authors' Addresses
Ben Schwartz
Meta Platforms, Inc.
Email: ietf@bemasc.net
Mike Bishop
Akamai Technologies
Email: mbishop@evequefou.be
Erik Nygren
Akamai Technologies
Email: erik+ietf@nygren.org
ISO Plain Language
On this page
§1Overview
The Service Bindings framework lets server operators publish a detailed description of their service in the Domain Name System, using SVCB or HTTPS records. Each SVCB record describes a single alternative endpoint and holds a collection of service parameters, which can be extended with new kinds of information. Clients use those parameters to improve the privacy, security and performance of their connection to the endpoint.
This document defines a new service parameter that enables the use of TLS Encrypted ClientHello in TLS-based protocols. It can be used in SVCB records, HTTPS records, or any future SVCB-compatible DNS records, and it is intended to serve as the primary bootstrap mechanism for Encrypted ClientHello. The Encrypted ClientHello specification itself is RFC 9849.
A DNS record can carry extra information about a service, and clients use it to set up a better connection. This document adds one such piece of information: the encryption settings a client needs in order to hide the name of the server inside the first message of a TLS handshake.
§3The ech Service Parameter
The ech parameter key conveys the Encrypted ClientHello configuration of an alternative endpoint. It applies to all schemes that use TLS-based protocols, including DTLS and QUIC version 1, unless otherwise specified.
In wire format, the value of the parameter is an ECHConfigList, including the redundant length prefix. In presentation format, which is how it appears in a zone file, the value is that ECHConfigList in Base 64 encoding. Base 64 is used to simplify integration with TLS server software. To enable simpler parsing, the parameter must not contain escape sequences.
The example given in the document is an ech parameter whose configuration has a public name of ech-sites.example.net:
ech="AEj+DQBEAQAgACAdd+scUi0IYFsXnUIU7ko2Nd9+F8M26pAGZVpz/KrWPgAEAAEAAWQVZWNoLXNpdGVzLmV4YW1wbGUubmV0AAA="
The parameter's value is the server's encryption configuration, which is a list of one or more entries. In a zone file it is written as Base 64 text so that it can be copied straight into server software without being re-encoded.
§4Requirements for Server Deployments
When publishing a record containing an ech parameter, the publisher must ensure that all the IP addresses of the target name correspond to servers that have access to the corresponding private key or are authoritative for the public name. Otherwise the connections fail entirely.
These servers should support a protocol version that is compatible with Encrypted ClientHello. At the time of writing, the compatible versions are TLS 1.3, DTLS 1.3 and QUIC version 1. If the server does not support a compatible version, each connection attempt has to be retried, which delays the connection and wastes resources.
Every address the record points at must be a server that can actually decrypt the client's first message, or one that is the authority for the name the client is hiding. If that does not hold, the connection simply fails. The server must also speak a version of TLS that supports the encryption, or every connection attempt has to be tried again.
§5Requirements for Client Implementations
Section 5.1 deals with fallback. The SVCB-optional client behaviour permits a client to fall back to a direct connection if all the SVCB options fail. That is not suitable for Encrypted ClientHello, because a fallback would cancel out the privacy benefit. A client that supports Encrypted ClientHello and uses SVCB-optional mode must therefore switch to SVCB-reliant connection establishment if SVCB resolution succeeded and all the alternative endpoints have an ech parameter.
Section 5.2 covers the ClientHello. When Encrypted ClientHello is in use, the TLS ClientHello is divided into an unencrypted outer ClientHello and an encrypted inner ClientHello. The outer ClientHello is an implementation detail of Encrypted ClientHello, and its contents are controlled by the ECH configuration. The inner ClientHello is used for establishing the connection to the service, so its contents may be influenced by the other service parameters. For example, the requirements on Application-Layer Protocol Negotiation identifiers apply only to the inner ClientHello, and it is the inner ClientHello whose Server Name Indication identifies the desired service.
Section 5.3 covers performance. Before the client retrieves the SVCB records it does not know whether they contain an ech parameter, so as a latency optimization clients may prefetch DNS records that will only be used if the parameter is absent, which is the case only in SVCB-optional mode. Because the ech parameter alters the contents of the TLS ClientHello when it is present, clients that support Encrypted ClientHello must not issue any TLS ClientHello until SVCB resolution has completed.
Three rules govern the client. It must not fall back to a plain connection when the record said the server supports the encryption, because that would defeat the purpose. The name of the service goes only in the inner, encrypted part of the hello, never in the outer part. And the client must finish its DNS lookup before it sends the hello at all, so that it knows whether the hello has to be encrypted.
- RESOLVEThe client looks up the HTTPS or SVCB record for the name.
- HTTPS RECORDThe record carries the ech parameter with the server's ECH configuration.
- OUTER CLIENTHELLOThe outer ClientHello is encrypted and names no service in the clear.
- HANDSHAKEThe server reads the inner ClientHello, whose Server Name Indication names the real service.
- No fallbackIf SVCB resolution succeeded and every endpoint has an ech parameter, the client must not fall back to a direct connection.
- Wait for the lookupA client that supports ECH must not send any TLS ClientHello until SVCB resolution has completed.
- Inner ClientHello onlyThe Application-Layer Protocol Negotiation rules and the Server Name Indication apply to the inner ClientHello.
§6Interaction with HTTP Alt-Svc
HTTP clients that implement both HTTP Alt-Svc and the HTTPS record type can use them together, provided that they only perform connection attempts that are consistent with both sets of parameters. At the time of writing there is no defined parameter related to Encrypted ClientHello for Alt-Svc, so a connection attempt that uses Encrypted ClientHello is considered consistent with an Alt-Svc field value that does not mention it.
Origins that publish an ech parameter in their HTTPS record should also publish an HTTPS record with the ech parameter for every alt-authority offered in their Alt-Svc field values. Otherwise clients might reveal the name of the server in an unencrypted ClientHello to an alt-authority.
If all the HTTPS records for an alt-authority contain ech parameters, the client must adopt SVCB-reliant behaviour for that record set. This rules out some connections that Alt-Svc would otherwise allow.
Alt-Svc lets a server point clients at a different host. If a server uses it, it must publish the same encryption parameter for each of the alternative hosts it names, otherwise a client would send the real name in the clear to one of them. When every record for an alternative host carries the parameter, the client must not fall back to a plain connection for that host either.
§7Examples
The document gives six example zones. The first places the same configuration on the apex of a zone and on a web name, with an HTTPS record carrying an ech parameter at each, and it notes that the zone is compatible with clients that do or do not support HTTPS records.
The second example describes a service that lets clients choose between two pools of servers, each with its own ECH configuration, using two SVCB records that point at the two pools and carry different ech values.
The third example is an aliasing-based content delivery network. The CDN operator's zone holds the pool with the ech parameter, and the customer's zone holds an HTTPS record that aliases to that pool, with apex address records kept for clients that do not support HTTPS records.
The fourth example is a domain that is only reachable using Encrypted ClientHello. The HTTPS record names a backend, carries the ech parameter, and adds the mandatory parameter, which tells the client that it must not connect without Encrypted ClientHello.
The fifth example is a multi-CDN configuration using server-side selection, with two versions of the customer's zone pointing at two different CDN operators' pools, each with its own ech value. The last example is a DNS server zone where the ech parameter is published alongside the Application-Layer Protocol Negotiation and DoH path parameters, at the apex and at a _dns name with a SVCB record.
The examples show the parameter being used in several ways. A single server can publish it at one name; two server pools behind one name can each publish their own, so the client picks one; a content delivery network can publish it in its own zone and let the customer's zone point there; and a domain that must never be contacted in the clear marks the parameter as mandatory, which tells the client not to try without it.
$ORIGIN secret.example. ; High confidentiality zone
www 3600 IN HTTPS 1 backend ech=ABC... mandatory=ech
backend 300 IN A 192.0.2.1
AAAA 2001:db8::1§8Security Considerations
A record set containing some records with an ech parameter and some without is vulnerable to a downgrade attack. A network intermediary can block connections to the endpoints that support Encrypted ClientHello, causing the client to fall back to an endpoint without it. This configuration is not recommended, but it may be unavoidable when combining endpoints from different providers or during a staged rollout. Zone owners who do use a mixed configuration should mark the records with ech as more preferred, that is, with a lower SvcPriority value, than those without, to maximize the likelihood that Encrypted ClientHello is used in the absence of an active adversary.
When Encrypted ClientHello is deployed, the inner TLS Server Name Indication is protected from disclosure. There are still many ways an attacker might infer it. Even in an idealized deployment, the protection is limited to an anonymity set consisting of all the Encrypted-ClientHello-enabled server domains supported by a given client-facing server that share an ECH configuration. An attacker who can enumerate this set can always guess the encrypted name with a probability of at least 1/K, where K is the number of domains in the set. Some attackers may achieve much greater accuracy using traffic analysis, popularity weighting and other mechanisms.
Encrypted ClientHello ensures that TLS does not disclose the name, but the same information is also present in the DNS queries used to resolve the server's hostname. This specification does not conceal the server name from the DNS resolver. If DNS messages are sent between the client and the resolver without authenticated encryption, an attacker on that path can also learn the destination server name, and a similar attack applies if the client can be linked to a request from the resolver to a DNS authority.
An attacker who can prevent SVCB resolution can deny clients any associated security benefits. A hostile recursive resolver can always deny service to SVCB queries, and network intermediaries can often prevent resolution as well, even when the client and the recursive resolver validate DNSSEC and use a secure transport. These downgrade attacks can prevent a client from being aware that ech is configured, which could result in the client sending the ClientHello in cleartext. To prevent downgrades, the Service Bindings specification recommends that clients abandon the connection attempt when such an attack is detected.
Four limits are worth knowing. A record set that offers the parameter on some servers but not others lets an attacker block the protected ones and force the client onto an unprotected one. The name is hidden only among the domains that share the same configuration, so an attacker who lists them can still guess it. The name is still visible in the DNS query, so it is not hidden from the resolver. And an attacker who blocks the DNS lookup can stop the client from ever learning that protection was available.
| Limit | What it means |
|---|---|
| Mixed record sets | An intermediary can block the endpoints that support ECH and force the client onto one that does not |
| Anonymity set | The name can be guessed with a probability of at least 1/K, where K is the number of domains sharing the configuration |
| DNS queries | The server name is still visible in the DNS query, so this document does not hide it from the resolver |
| Blocked resolution | Stopping the DNS lookup can stop the client from learning that ECH was configured at all |