RFC 9849
TLS Encrypted Client Hello
9849 TLS Encrypted Client Hello β¨
Okay bestie, this is RFC 9849, and it's giving ECH: the spec that lets a client encrypt its ClientHello to the server ππ It's a Standards Track document from the IETF, dated March 2026, and it's published with ISSN 2070-1721. It was written by E. Rescorla (Independent), ε₯₯ δΈη© (K. Oku) (Fastly), N. Sullivan (Cryptography Consulting LLC), and C. A. Wood (Apple) π¦
It doesn't obsolete or update any earlier RFCs in the title block, so this one is a fresh start πΈ
Abstract
This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key.
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/rfc9849.
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. Introduction
2. Conventions and Definitions
3. Overview
3.1. Topologies
3.2. Encrypted ClientHello (ECH)
4. Encrypted ClientHello Configuration
4.1. Configuration Identifiers
4.2. Configuration Extensions
5. The "encrypted_client_hello" Extension
5.1. Encoding the ClientHelloInner
5.2. Authenticating the ClientHelloOuter
6. Client Behavior
6.1. Offering ECH
6.1.1. Encrypting the ClientHello
6.1.2. GREASE PSK
6.1.3. Recommended Padding Scheme
6.1.4. Determining ECH Acceptance
6.1.5. Handshaking with ClientHelloInner
6.1.6. Handshaking with ClientHelloOuter
6.1.7. Authenticating for the Public Name
6.1.8. Impact of Retry on Future Connections
6.2. GREASE ECH
6.2.1. Client Greasing
6.2.2. Server Greasing
7. Server Behavior
7.1. Client-Facing Server
7.1.1. Processing ClientHello after HelloRetryRequest
7.2. Backend Server
7.2.1. Sending HelloRetryRequest
8. Deployment Considerations
8.1. Compatibility Issues
8.1.1. Misconfiguration and Deployment Concerns
8.1.2. Middleboxes
8.2. Deployment Impact
9. Compliance Requirements
10. Security Considerations
10.1. Security and Privacy Goals
10.2. Unauthenticated and Plaintext DNS
10.3. Client Tracking
10.4. Ignored Configuration Identifiers and Trial Decryption
10.5. Outer ClientHello
10.6. Inner ClientHello
10.7. Related Privacy Leaks
10.8. Cookies
10.9. Attacks Exploiting Acceptance Confirmation
10.10. Comparison Against Criteria
10.10.1. Mitigate Cut-and-Paste Attacks
10.10.2. Avoid Widely Shared Secrets
10.10.3. SNI-Based Denial-of-Service Attacks
10.10.4. Do Not Stick Out
10.10.5. Maintain Forward Secrecy
10.10.6. Enable Multi-party Security Contexts
10.10.7. Support Multiple Protocols
10.11. Padding Policy
10.12. Active Attack Mitigations
10.12.1. Client Reaction Attack Mitigation
10.12.2. HelloRetryRequest Hijack Mitigation
10.12.3. ClientHello Malleability Mitigation
10.12.4. ClientHelloInner Packet Amplification Mitigation
11. IANA Considerations
11.1. Update of the TLS ExtensionType Registry
11.2. Update of the TLS Alert Registry
11.3. ECH Configuration Extension Registry
12. References
12.1. Normative References
12.2. Informative References
Appendix A. Linear-Time Outer Extension Processing
Acknowledgements
Authors' Addresses1. Introduction π
Okay so, TLS 1.3 [RFC8446] encrypts most of the handshake, including the server certificate, but there are still a bunch of ways an on-path attacker can snoop on private info about a connection π The plaintext Server Name Indication (SNI) extension in ClientHello messages leaks the target domain for a given connection, and it's honestly the most sensitive thing still unencrypted in TLS 1.3 π
So this document specifies a brand-new TLS extension called Encrypted Client Hello (ECH) π§ It lets clients encrypt their ClientHello to the TLS server, which protects the SNI and other sensitive fields, like the Application-Layer Protocol Negotiation (ALPN) list [RFC7301] π₯ Co-located servers with consistent externally visible TLS configurations and behavior, including supported versions and cipher suites and how they respond to incoming client connections, form an anonymity set π (Note that implementation-specific choices, such as extension ordering within TLS messages or division of data into record-layer boundaries, can result in different externally visible behavior, even for servers with consistent TLS configurations.) Using this mechanism reveals that a client is connecting to a particular service provider, but it does not reveal which server from the anonymity set terminates the connection π¦ Deployment implications are discussed in Section 8.
ECH is not in itself sufficient to protect the identity of the server, bestie π The target domain may also be visible through other channels, like plaintext client DNS queries or visible server IP addresses. Encrypted DNS mechanisms such as DNS over HTTPS [RFC8484], DNS over TLS/DTLS [RFC7858] [RFC8094], and DNS over QUIC [RFC9250] help clients hide DNS lookups from network inspection π Also, many TLS servers host multiple domains on the same IP address, and private origins may be deployed behind a common provider, such as a reverse proxy. In those environments, the SNI remains the primary explicit signal observers can use to figure out the server's identity π
ECH is supported in TLS 1.3 [RFC8446], DTLS 1.3 [RFC9147], and newer versions of the TLS and DTLS protocols β¨
2. Conventions and Definitions π
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 π All TLS notation comes from [RFC8446], Section 3.
3. Overview π¦
This protocol is designed to operate in one of two topologies, which we call "Shared Mode" and "Split Mode" π These modes are described in the following section.
3.1. Topologies πΈ
+---------------------+
| |
| 2001:DB8::1111 |
| |
Client <-----> | private.example.org |
| |
| public.example.com |
| |
+---------------------+
Server
(Client-Facing and Backend Combined)
Figure 1: Shared Mode TopologyIn shared mode, the provider is the origin server for all the domains whose DNS records point to it. In this mode, the TLS connection is terminated by the provider π
+--------------------+ +---------------------+
| | | |
| 2001:DB8::1111 | | 2001:DB8::EEEE |
Client <----------------------------->| |
| public.example.com | | private.example.org |
| | | |
+--------------------+ +---------------------+
Client-Facing Server Backend Server
Figure 2: Split Mode TopologyIn split mode, the provider is not the origin server for private domains. Instead, the DNS records for private domains point to the provider, and the provider's server relays the connection back to the origin server, who terminates the TLS connection with the client π§ Importantly, the service provider does not have access to the plaintext of the connection beyond the unencrypted portions of the handshake. Main character energy, but for privacy π
In the rest of this document, we'll call the ECH-service provider the "client-facing server" and the TLS terminator the "backend server" β¨ These are the same entity in shared mode, but in split mode the client-facing and backend servers are physically separated π«Ά
See Section 10 for more discussion about the ECH threat model and how it relates to the client, client-facing server, and backend server π₯
(Part 1 of 11. More parts coming, so stay tuned, bestie π)
3.2. Encrypted ClientHello (ECH) β¨
okay so a client-facing server turns ECH on by publishing an ECH configuration, which is basically an encryption public key plus some metadata π Any domain that wants ECH has to publish this config too, using the key tied to that client-facing server π This doc defines what the config looks like but hands the DNS publishing details off to [RFC9460]. For how ECH configs get advertised in SVCB and HTTPS records, go check [RFC9848] π Other delivery methods are possible as well. Like, the client could just have the config preconfigured π§
when a client wants a TLS session with some backend server, it builds a private ClientHello called the ClientHelloInner π«£ Then it builds a public one called the ClientHelloOuter. The outer one has innocuous values for the sensitive extensions, plus an encrypted_client_hello extension (Section 5) that carries the encrypted inner one. Finally, the client sends the ClientHelloOuter to the server π
The server then does one of two things:
- If it doesn't support ECH or can't decrypt the extension, it finishes the handshake with the ClientHelloOuter. This is called rejecting ECH π ββοΈ
- If it successfully decrypts the extension, it forwards the ClientHelloInner to the backend server, which finishes the handshake. This is called accepting ECH β
After the client gets the server's response, it figures out whether or not ECH was accepted (Section 6.1.4) and keeps going from there. When ECH is rejected, the resulting connection is not usable by the client for application data π Instead, the rejection lets the client retry with up-to-date configuration (Section 6.1.6) π
The main goal of ECH is to make sure connections to servers in the same anonymity set look indistinguishable from one another π And it should do this without messing with any existing security properties of TLS 1.3. See Section 10.1 for more on the ECH security and privacy goals π
4. Encrypted ClientHello Configuration π
ECH uses Hybrid Public Key Encryption (HPKE) for public key encryption [HPKE]. The ECH configuration is defined by the following ECHConfig structure, and it's giving very precise layout energy π§
opaque HpkePublicKey<1..2^16-1>;
uint16 HpkeKemId; // Defined in RFC 9180
uint16 HpkeKdfId; // Defined in RFC 9180
uint16 HpkeAeadId; // Defined in RFC 9180
uint16 ECHConfigExtensionType; // Defined in Section 11.3
struct {
HpkeKdfId kdf_id;
HpkeAeadId aead_id;
} HpkeSymmetricCipherSuite;
struct {
uint8 config_id;
HpkeKemId kem_id;
HpkePublicKey public_key;
HpkeSymmetricCipherSuite cipher_suites<4..2^16-4>;
} HpkeKeyConfig;
struct {
ECHConfigExtensionType type;
opaque data<0..2^16-1>;
} ECHConfigExtension;
struct {
HpkeKeyConfig key_config;
uint8 maximum_name_length;
opaque public_name<1..255>;
ECHConfigExtension extensions<0..2^16-1>;
} ECHConfigContents;
struct {
uint16 version;
uint16 length;
select (ECHConfig.version) {
case 0xfe0d: ECHConfigContents contents;
}
} ECHConfig;The structure has these fields, so let's go through them π§
version: This is the version of ECH the configuration is used for. It's the same as the code point for theencrypted_client_helloextension. Clients MUST ignore any ECHConfig structure with a version they do not support. π«length: The length, in bytes, of the next field. This is what lets implementations skip over elements in the list when they can't parse that specific version of ECHConfig, which is so smart π§contents: An opaque byte string whose contents depend on the version. For this spec, the contents are an ECHConfigContents structure.
The ECHConfigContents structure has its own fields:
key_config: A HpkeKeyConfig structure carrying the configuration info for the HPKE public key (an "ECH key"). This structure has theconfig_idfield, and that one applies to the entire ECHConfigContents πmaximum_name_length: The longest name of a backend server, if it's known. If it isn't known, this can be set to zero. It's used to compute padding (Section 6.1.3), and it does not constrain server name lengths. Names can go over this length if, e.g., the server uses wildcard names or added new names to the anonymity set π«§public_name: The DNS name of the client-facing server, aka the entity trusted to update the ECH configuration. This is used to correct misconfigured clients, as described in Section 6.1.6.
See Section 6.1.7 for how the client interprets and validates the public_name. π΅οΈββοΈ
extensions: A list of ECHConfigExtension values the client must take into consideration when generating a ClientHello message. Each ECHConfigExtension has a 2-octet type and an opaque data value, where the data value is encoded with a 2-octet integer representing the length of the data, in network byte order. ECHConfigExtension values are described below (Section 4.2). π§©
The HpkeKeyConfig structure has these fields:
config_id: A one-byte identifier for the given HPKE key configuration. Clients use this to indicate which key was used for ClientHello encryption. Section 4.1 describes how client-facing servers allocate this value. πͺͺkem_id: The HPKE Key Encapsulation Mechanism (KEM) identifier that corresponds topublic_key. Clients MUST ignore any ECHConfig structure with a key using a KEM they do not support. π ββοΈpublic_key: The HPKE public key the client uses to encrypt ClientHelloInner. πcipher_suites: The list of HPKE Key Derivation Function (KDF) and Authenticated Encryption with Associated Data (AEAD) identifier pairs that clients can use for encrypting ClientHelloInner. See Section 6.1 for how clients choose from this list. π―
The client-facing server advertises a sequence of ECH configurations to clients, serialized like this π¦
ECHConfig ECHConfigList<4..2^16-1>;The ECHConfigList structure contains one or more ECHConfig structures in decreasing order of preference. This lets a server support multiple versions of ECH and multiple sets of ECH parameters at once, which is very main character of it π
4.1. Configuration Identifiers πͺͺ
A client-facing server has a set of known ECHConfig values, each with a corresponding private key. This set SHOULD contain the currently published values, plus previous values that may still be in use, since clients may cache DNS records for up to a TTL or longer π°οΈ
Section 7.1 describes a trial decryption process for decrypting the ClientHello. This can hurt performance when the client-facing server maintains lots of known ECHConfig values π© To avoid that, the client-facing server SHOULD allocate distinct config_id values for each ECHConfig in its known set. The RECOMMENDED strategy is rejection sampling, i.e., randomly selecting a config_id over and over until it doesn't match any known ECHConfig π²
It's not necessary for config_id values across different client-facing servers to be distinct. A backend server can be hosted behind two different client-facing servers with colliding config_id values without any performance impact β¨ Values can also be reused if the previous ECHConfig is no longer in the known set β»οΈ
4.2. Configuration Extensions π§©
ECH configuration extensions give us room for extra functionality whenever it's needed π The format is defined in Section 4 and mirrors Section 4.2 of [RFC8446]. However, ECH configuration extension types are maintained by IANA as described in Section 11.3. ECH configuration extensions follow the same interpretation rules as TLS extensions: extensions MAY appear in any order, but there MUST NOT be more than one extension of the same type in the extensions block. Unlike TLS extensions, an extension can be tagged as mandatory by setting the high-order bit of its extension type codepoint to 1 π©
Clients MUST parse the extension list and check for unsupported mandatory extensions. If an unsupported mandatory extension is present, clients MUST ignore the ECHConfig π
Any future information or hints that influence ClientHelloOuter SHOULD be specified as ECHConfig extensions. This is mainly because the outer ClientHello exists only to support ECH. It's both an envelope for the encrypted inner ClientHello and an enabler for authenticated key mismatch signals (see Section 7). In contrast, the inner ClientHello is the true ClientHello used when ECH is negotiated π¦
5. The "encrypted_client_hello" Extension β¨
okay so to offer ECH, the client sends an "encrypted_client_hello" extension in the ClientHelloOuter π and when it does, it MUST also send the extension in ClientHelloInner. no skipping the inner one, bestie π
enum {
encrypted_client_hello(0xfe0d), (65535)
} ExtensionType;the payload of the extension has this structure π§©
enum { outer(0), inner(1) } ECHClientHelloType;
struct {
ECHClientHelloType type;
select (ECHClientHello.type) {
case outer:
HpkeSymmetricCipherSuite cipher_suite;
uint8 config_id;
opaque enc<0..2^16-1>;
opaque payload<1..2^16-1>;
case inner:
Empty;
};
} ECHClientHello;the outer extension uses the outer variant and the inner extension uses the inner variant β¨ the inner one has an empty payload, and that's included because TLS servers aren't allowed to put extensions in ServerHello that weren't in ClientHello. so it's not random, it's required by the rules π the outer extension has these fields:
config_id: the ECHConfigContents.key_config.config_id for the chosen ECHConfig.cipher_suite: the cipher suite used to encrypt ClientHelloInner. This MUST match a value provided in the corresponding ECHConfigContents.key_config.cipher_suites list.enc: the HPKE encapsulated key that servers use to decrypt the corresponding payload field. This field is empty in a ClientHelloOuter sent in response to HelloRetryRequest.payload: the serialized and encrypted EncodedClientHelloInner structure, encrypted using HPKE as described in Section 6.1.
when a client offers the outer version of an "encrypted_client_hello" extension, the server MAY include an "encrypted_client_hello" extension in its EncryptedExtensions message, as described in Section 7.1, with this payload πΈ
struct {
ECHConfigList retry_configs;
} ECHEncryptedExtensions;the response is only valid when the server used the ClientHelloOuter. if the server sent this extension in response to the inner variant, then the client MUST abort with an "unsupported_extension" alert. no exceptions, periodt π
retry_configs: an ECHConfigList structure containing one or more ECHConfig structures, in decreasing order of preference, to be used by the client as described in Section 6.1.6. these are known as the server's "retry configurations" π¦
finally, when the client offers "encrypted_client_hello", if the payload is the inner variant and the server responds with HelloRetryRequest, it MUST include an "encrypted_client_hello" extension with this payload π«Ά
struct {
opaque confirmation[8];
} ECHHelloRetryRequest;the value of ECHHelloRetryRequest.confirmation is set to hrr_accept_confirmation, as described in Section 7.2.1.
this document also defines the "ech_required" alert. the client MUST send it when it offered an "encrypted_client_hello" extension that the server did not accept. (See Section 11.2.) π¨
5.1. Encoding the ClientHelloInner
before encrypting, the client pads and optionally compresses ClientHelloInner into an EncodedClientHelloInner structure, which looks like this π
struct {
ClientHello client_hello;
uint8 zeros[length_of_padding];
} EncodedClientHelloInner;the client_hello field is built by making a copy of ClientHelloInner and setting the legacy_session_id field to the empty string. in TLS, this field uses the ClientHello structure from Section 4.1.2 of [RFC8446]. in DTLS, it uses the ClientHello structure from Section 5.3 of [RFC9147]. it does not include the Handshake structure's four-byte header in TLS, or the twelve-byte header in DTLS. the zeros field MUST be all zeros, with a length of length_of_padding (see Section 6.1.3).
repeating big extensions, like "key_share" with post-quantum algorithms, in both ClientHelloInner and ClientHelloOuter can get excessively large π© to keep the size down, the client MAY swap out extensions it knows will be duplicated in ClientHelloOuter. it does this by removing them from EncodedClientHelloInner and replacing them with a single "ech_outer_extensions" extension, defined like so π§
enum {
ech_outer_extensions(0xfd00), (65535)
} ExtensionType;
ExtensionType OuterExtensions<2..254>;OuterExtensions holds the list of removed ExtensionType values. each value points to the matching extension in ClientHelloOuter. the values MUST be ordered contiguously in ClientHelloInner, and the "ech_outer_extensions" extension MUST be inserted in the corresponding position in EncodedClientHelloInner. on top of that, the extensions MUST appear in ClientHelloOuter in the same relative order. but they don't have to be next to each other there. for example, OuterExtensions could contain extensions A, B, and C, while ClientHelloOuter contains extensions A, D, B, C, E, and F. π
the "ech_outer_extensions" extension can only be included in EncodedClientHelloInner and MUST NOT appear in either ClientHelloOuter or ClientHelloInner. π ββοΈ
finally, the client pads the message by setting the zeros field to a byte string of all zeros, with a length equal to the amount of padding to add. Section 6.1.3 describes a recommended padding scheme π
the client-facing server rebuilds ClientHelloInner by reversing this process β¨ first, it parses EncodedClientHelloInner and treats all bytes after client_hello as padding. if any padding byte is non-zero, the server MUST abort the connection with an "illegal_parameter" alert.
next, it makes a copy of the client_hello field and copies the legacy_session_id field from ClientHelloOuter. then it looks for an "ech_outer_extensions" extension. if it finds one, it swaps that extension for the matching sequence of extensions from ClientHelloOuter. the server MUST abort the connection with an "illegal_parameter" alert if any of the following are true π«
- Any referenced extension is missing in ClientHelloOuter.
- Any extension is referenced in OuterExtensions more than once.
- "encrypted_client_hello" is referenced in OuterExtensions.
- The extensions in ClientHelloOuter corresponding to those in OuterExtensions do not occur in the same order.
these rules stop an attacker from running a packet amplification attack by crafting a ClientHelloOuter that decompresses into a much bigger ClientHelloInner. this is discussed further in Section 10.12.4. the attacker really wants this to work, so this part matters a lot π₯
receiving implementations SHOULD construct the ClientHelloInner in linear time. quadratic time implementations (like the ones you get from naive copying) create a denial-of-service risk π Appendix A describes a linear-time procedure you can use for this.
5.2. Authenticating the ClientHelloOuter
to stop a network attacker from changing the ClientHelloOuter while keeping the same encrypted ClientHelloInner (see Section 10.12.3), ECH authenticates ClientHelloOuter by passing ClientHelloOuterAAD as the associated data for HPKE sealing and opening operations π ClientHelloOuterAAD is a serialized ClientHello structure. TLS uses the one from Section 4.1.2 of [RFC8446], and DTLS uses the one from Section 5.3 of [RFC9147]. it matches ClientHelloOuter, except the payload field of the "encrypted_client_hello" is replaced with a byte string of the same length that's all zeros. this value doesn't include the Handshake structure's four-byte header in TLS or the twelve-byte header in DTLS. main character energy in the crypto world π¦
6. Client Behavior π
clients that implement the ECH extension behave in one of two ways π either they offer a real ECH extension, as described in Section 6.1, or they send a Generate Random Extensions And Sustain Extensibility (GREASE) [RFC8701] ECH extension, as described in Section 6.2. the client offers ECH if it has a compatible ECH configuration, and sends GREASE ECH (see Section 6.2) otherwise. clients in the second group don't negotiate ECH. instead, they make a dummy ECH extension that the server just ignores. (See Section 10.10.4 for an explanation.) it's also possible for clients to always send GREASE ECH without implementing the rest of this specification π
6.1. Offering ECH β¨
okay so offering ECH is where the client gets to pick its outfit π
. First it digs through the server's ECHConfigList for a suitable ECHConfig. To check that, it makes sure it supports the KEM algorithm named in ECHConfig.contents.key_config.kem_id, at least one KDF/AEAD algorithm from ECHConfig.contents.key_config.cipher_suites, and the ECH version in ECHConfig.version. Once it finds a match, it picks the cipher suite it'll encrypt with. It MUST NOT choose a cipher suite or version the configuration didn't advertise π
ββοΈ. If no compatible configuration shows up, the client SHOULD go and do what Section 6.2 describes instead π«Ά.
Then it builds the ClientHelloInner pretty much like a normal ClientHello, with a few glow-up rules:
- It MUST NOT offer to negotiate TLS 1.2 or below. This is necessary so the backend server doesn't negotiate a TLS version that's incompatible with ECH π€.
- It MUST NOT offer to resume any session for TLS 1.2 and below.
- If it intends to compress any extensions (see Section 5.1), it MUST order those extensions consecutively.
- It MUST include the
"encrypted_client_hello"extension of type inner as described in Section 5. (This requirement is not applicable when the"encrypted_client_hello"extension is generated as described in Section 6.2.)
After that, the client constructs EncodedClientHelloInner as described in Section 5.1. It also computes an HPKE encryption context and enc value like this:
pkR = DeserializePublicKey(ECHConfig.contents.key_config.public_key)
enc, context = SetupBaseS(pkR,
"tls ech" || 0x00 || ECHConfig)Next up, it builds a partial ClientHelloOuterAAD the same way it would a standard ClientHello, but with these rules π:
- It MUST offer to negotiate TLS 1.3 or above.
- If it compressed any extensions in EncodedClientHelloInner, it MUST copy the corresponding extensions from ClientHelloInner. The copied extensions additionally MUST be in the same relative order as in ClientHelloInner.
- It MUST copy the
legacy_session_idfield from ClientHelloInner. This allows the server to echo the correct session ID for TLS 1.3's compatibility mode (see Appendix D.4 of [RFC8446]) when ECH is negotiated. Note that compatibility mode is not used in DTLS 1.3, but following this rule will produce the correct results for both TLS 1.3 and DTLS 1.3 π¦. - It MAY copy any other field from the ClientHelloInner except
ClientHelloInner.random. Instead, it MUST generate a freshClientHelloOuter.randomusing a secure random number generator. (See Section 10.12.1.) - It SHOULD place the value of
ECHConfig.contents.public_namein the"server_name"extension. Clients that do not follow this step, or place a different value in the"server_name"extension, risk breaking the retry mechanism described in Section 6.1.6 or failing to interoperate with servers that require this step to be done; see Section 7.1. bestie, don't skip this one π. - When the client offers the
"pre_shared_key"extension in ClientHelloInner, it SHOULD also include a GREASE"pre_shared_key"extension in ClientHelloOuter, generated in the manner described in Section 6.1.2. The client MUST NOT use this extension to advertise a PSK to the client-facing server. (See Section 10.12.3.) When the client includes a GREASE"pre_shared_key"extension, it MUST also copy the"psk_key_exchange_modes"from the ClientHelloInner into the ClientHelloOuter. - When the client offers the
"early_data"extension in ClientHelloInner, it MUST also include the"early_data"extension in ClientHelloOuter. This allows servers that reject ECH and use ClientHelloOuter to safely ignore any early data sent by the client per [RFC8446], Section 4.2.10 π.
The client might duplicate non-sensitive extensions in both messages. However, implementations need to take care to ensure that sensitive extensions are not offered in the ClientHelloOuter. See Section 10.5 for additional guidance. This part is lowkey the most important vibe check ever π.
Finally, the client encrypts the EncodedClientHelloInner with the above values, as described in Section 6.1.1, to construct a ClientHelloOuter. It sends this to the server and processes the response as described in Section 6.1.4. β¨
6.1.1. Encrypting the ClientHello
Given an EncodedClientHelloInner, an HPKE encryption context and enc value, and a partial ClientHelloOuterAAD, the client constructs a ClientHelloOuter as follows π§.
First, the client determines the length L of encrypting EncodedClientHelloInner with the selected HPKE AEAD. This is typically the sum of the plaintext length and the AEAD tag length. The client then completes the ClientHelloOuterAAD with an "encrypted_client_hello" extension. This extension value contains the outer variant of ECHClientHello with the following fields:
config_id, the identifier corresponding to the chosen ECHConfig structure;cipher_suite, the client's chosen cipher suite;enc, as given above; andpayload, a placeholder byte string containingLzeros.
If configuration identifiers (see Section 10.4) are to be ignored, config_id SHOULD be set to a randomly generated byte in the first ClientHelloOuter and, in the event of a HelloRetryRequest (HRR), MUST be left unchanged for the second ClientHelloOuter.
The client serializes this structure to construct the ClientHelloOuterAAD. It then computes the final payload as:
final_payload = context.Seal(ClientHelloOuterAAD,
EncodedClientHelloInner)Including ClientHelloOuterAAD as the HPKE AAD binds the ClientHelloOuter to the ClientHelloInner, thus preventing attackers from modifying ClientHelloOuter while keeping the same ClientHelloInner, as described in Section 10.12.3. That's the security glue, and it's giving tamper-proof π.
Finally, the client replaces payload with final_payload to obtain ClientHelloOuter. The two values have the same length, so it is not necessary to recompute length prefixes in the serialized structure.
Note this construction requires the "encrypted_client_hello" be computed after all other extensions. This is possible because the ClientHelloOuter's "pre_shared_key" extension is either omitted or uses a random binder (Section 6.1.2).
6.1.2. GREASE PSK
When offering ECH, the client is not permitted to advertise PSK identities in the ClientHelloOuter. However, the client can send a "pre_shared_key" extension in the ClientHelloInner. In this case, when resuming a session with the client, the backend server sends a "pre_shared_key" extension in its ServerHello. This would appear to a network observer as if the server were sending this extension without solicitation, which would violate the extension rules described in [RFC8446]. When offering a PSK in ClientHelloInner, clients SHOULD send a GREASE "pre_shared_key" extension in the ClientHelloOuter to make it appear to the network as if the extension were negotiated properly π.
The client generates the extension payload by constructing an OfferedPsks structure (see [RFC8446], Section 4.2.11) as follows. For each PSK identity advertised in the ClientHelloInner, the client generates a random PSK identity with the same length. It also generates a random, 32-bit, unsigned integer to use as the obfuscated_ticket_age. Likewise, for each inner PSK binder, the client generates a random string of the same length.
Per the rules of Section 6.1, the server is not permitted to resume a connection in the outer handshake. If ECH is rejected and the client-facing server replies with a "pre_shared_key" extension in its ServerHello, then the client MUST abort the handshake with an "illegal_parameter" alert. π¨
6.1.3. Recommended Padding Scheme
If the ClientHelloInner is encrypted without padding, then the length of the ClientHelloOuter.payload can leak information about ClientHelloInner. In order to prevent this, the EncodedClientHelloInner structure has a padding field. This section describes a deterministic mechanism for computing the required amount of padding based on the following observation: individual extensions can reveal sensitive information through their length. Thus, each extension in the inner ClientHello may require different amounts of padding. This padding may be fully determined by the client's configuration or may require server input.
By way of example, clients typically support a small number of application profiles. For instance, a browser might support HTTP with ALPN values ["http/1.1", "h2"] and WebRTC media with ALPNs ["webrtc", "c-webrtc"]. Clients SHOULD pad this extension by rounding up to the total size of the longest ALPN extension across all application profiles. The target padding length of most ClientHello extensions can be computed in this way.
In contrast, clients do not know the longest SNI value in the client-facing server's anonymity set without server input. Clients SHOULD use the ECHConfig's maximum_name_length field as follows, where M is the maximum_name_length value.
- If the ClientHelloInner contained a
"server_name"extension with a name of lengthD, addmax(0, M - D)bytes of padding. - If the ClientHelloInner did not contain a
"server_name"extension (e.g., if the client is connecting to an IP address), addM + 9bytes of padding. This is the length of a"server_name"extension with anM-byte name.
Finally, the client SHOULD pad the entire message as follows:
- Let
Lbe the length of the EncodedClientHelloInner with all the padding computed so far. - Let
N = 31 - ((L - 1) % 32)and addNbytes of padding.
This rounds the length of EncodedClientHelloInner up to a multiple of 32 bytes, reducing the set of possible lengths across all clients π.
In addition to padding ClientHelloInner, clients and servers will also need to pad all other handshake messages that have sensitive-length fields. For example, if a client proposes ALPN values in ClientHelloInner, the server-selected value will be returned in an EncryptedExtension, so that handshake message also needs to be padded using TLS record layer padding. π β¨
6.1.4. Determining ECH Acceptance π₯
okay so the server gets to pick here π it can either accept ECH and use ClientHelloInner, or reject it and use ClientHelloOuter. Section 7 has the full tea, but the deciding factor is the server's very first message π
If that message doesn't negotiate TLS 1.3 or higher, the server has rejected ECH, no cap. Otherwise it's gonna be either a ServerHello or a HelloRetryRequest π¦
If it's a ServerHello, the client computes accept_confirmation (see Section 7.2). If that matches the last 8 bytes of ServerHello.random, the server accepted ECH β¨ If not, it rejected ECH π
If it's a HelloRetryRequest, the client checks for the encrypted_client_hello extension. If there isn't one, the server rejected ECH. If there is one but its length is anything other than 8, the client MUST abort the handshake with a "decode_error" alert π Otherwise, the client computes hrr_accept_confirmation (see Section 7.2.1). If that matches the extension payload, ECH is accepted. If not, it's rejected.
If the server accepts ECH, the client handshakes with ClientHelloInner like in Section 6.1.5. If not, it handshakes with ClientHelloOuter like in Section 6.1.6 πΈ
6.1.5. Handshaking with ClientHelloInner π¦
okay so if the server accepts ECH, the client keeps going with the connection just like in [RFC8446], with a few tweaks π
The client acts like it sent ClientHelloInner as the ClientHello. So it judges the handshake by ClientHelloInner's preferences, and when it computes the transcript hash (Section 4.4.1 of [RFC8446]), it uses ClientHelloInner as the first ClientHello π«Ά
If the server replies with a HelloRetryRequest, the client builds the updated ClientHello like this:
- It computes a second ClientHelloInner based on the first ClientHelloInner, same as Section 4.1.4 of [RFC8446]. The ClientHelloInner's
encrypted_client_helloextension stays unmodified β¨ - It builds EncodedClientHelloInner the way Section 5.1 describes π
- It builds a second partial ClientHelloOuterAAD message. This message MUST be syntactically valid π₯ The extensions MAY be copied from the original ClientHelloOuter unmodified, or they can be left out. If they're not sensitive, the client MAY copy updated extensions from the second ClientHelloInner for compression π§
- It encrypts EncodedClientHelloInner as described in Section 6.1.1, using the second partial ClientHelloOuterAAD, to get a second ClientHelloOuter. It reuses the original HPKE encryption context from Section 6.1 and uses the empty string for
encπ
The HPKE context keeps a sequence number, so this operation internally uses a fresh nonce for each AEAD operation π Reusing the HPKE context also dodges an attack described in Section 10.12.2 π‘οΈ
The client then sends that second ClientHelloOuter to the server. But remember, it still uses the second ClientHelloInner for preferences, and both ClientHelloInner messages go into the transcript hash π
It also checks the resulting ServerHello for ECH acceptance, as in Section 6.1.4. If the ServerHello doesn't also indicate ECH acceptance, the client MUST terminate the connection with an "illegal_parameter" alert π
6.1.6. Handshaking with ClientHelloOuter β¨
If the server rejects ECH, the client keeps going with the handshake, authenticating for ECHConfig.contents.public_name as described in Section 6.1.7 π
If authentication or the handshake fails, the client MUST return a failure to the calling application. It MUST NOT use the retry configurations π
It MUST NOT treat this as a secure signal to disable ECH π« bestie, don't let anyone talk you into that one
If the server sent an encrypted_client_hello extension in its EncryptedExtensions message, the client MUST check that it's syntactically valid, and the client MUST abort the connection with a "decode_error" alert otherwise π If an earlier TLS version was negotiated, the client MUST NOT enable the False Start optimization [RFC7918] for this handshake. If both authentication and the handshake complete successfully, the client MUST do the processing described below, and then abort the connection with an "ech_required" alert before sending any application data to the server π₯
If the server provided retry_configs, and at least one of the values contains a version the client supports, the client can regard the ECH configuration as securely replaced by the server β¨ It SHOULD retry the handshake with a new transport connection, using the retry configurations the server supplied π¦
Since the new ECH configuration replaces the old one, clients can set up the new transport connection in any way that's consistent with the previous ECH configuration. For example, clients can reuse the same server IP address, or they can pick a different IP address if DNS gave them other IP addresses for the previous configuration πΈ But it is not safe to use IP addresses found with a new DNS query, since those might belong to a different ECH server configuration, like one tied to a different ECH server with a different public_name π
The retry configurations are meant for retried connections. Using them further could yield a tracking vector π But in settings where the client already lets the server track it anyway, e.g., because the client sends cookies to the server in parallel connections, using the retry configurations for those parallel connections doesn't add a new tracking vector π§
If none of the values in retry_configs contains a supported version, or the server didn't supply an encrypted_client_hello extension in its EncryptedExtensions message, or an earlier TLS version was negotiated, the client can regard ECH as securely disabled by the server π« It SHOULD retry the handshake with a new transport connection and ECH disabled.
Clients SHOULD NOT accept "retry_config" in response to a connection that was started because of a "retry_config" π© Sending a "retry_config" in this situation is a sign the server is misconfigured. For example, the server might have multiple inconsistent configurations, so the client reached a node with configuration A on the first connection and a node with configuration B on the second. Note that this guidance doesn't apply to the cases in the previous paragraph, where the server has securely disabled ECH π€
If a client doesn't retry, it MUST report an error to the calling application π
6.1.7. Authenticating for the Public Name π«Ά
When the server rejects ECH, it keeps going with the handshake using the plaintext server_name extension instead (see Section 7). Clients that offer ECH then authenticate the connection with the public name like this π
- The client MUST verify that the certificate is valid for
ECHConfig.contents.public_name. If it's invalid, the client MUST abort the connection with the appropriate alert β - If the server requests a client certificate, the client MUST respond with an empty
Certificatemessage, which means no client certificate π
When verifying the client-facing server certificate, the client MUST interpret the public name as a DNS-based reference identity [RFC9525]. Clients that put DNS names and IP addresses into the same syntax (e.g. Section 7.4 of [RFC3986] and [WHATWG-IPV4]) MUST reject names that would be read as IPv4 addresses π
ββοΈ Clients that enforce this by checking ECHConfig.contents.public_name don't need to repeat the check when handling ECH rejection β¨
Okay, important bit π¨ authenticating a connection for the public name does NOT authenticate it for the origin. The TLS implementation MUST NOT report these connections as successful to the application π It additionally MUST ignore all session tickets and session IDs the server presents. These connections are only used to trigger retries, as described in Section 6.1.6. This might be implemented by reporting a failed connection with a dedicated error code π§Ύ
Before attempting a connection, a client SHOULD validate the ECHConfig.contents.public_name π Clients SHOULD ignore any ECHConfig structure whose public_name isn't a valid host name in preferred name syntax (see Section 2 of [DNS-TERMS]). So, to be valid, the public_name has to be a dot-separated sequence of LDH labels, as defined in Section 2.3.1 of [RFC5890], where:
- the sequence doesn't begin or end with an ASCII dot, and
- all labels are at most 63 octets.
Clients additionally SHOULD ignore the structure if the final LDH label either consists entirely of ASCII digits (i.e., '0' through '9'), or is "0x" or "0X" followed by some, possibly empty, sequence of ASCII hexadecimal digits (i.e., '0' through '9', 'a' through 'f', and 'A' through 'F'). This avoids public_name values that could get read as IPv4 literals π§
6.1.8. Impact of Retry on Future Connections π
Clients MAY use info learned from a rejected ECH for future connections, so they don't keep hitting the same server and getting forced to retry π§ But they MUST handle ECH rejection on those connections as if it were a fresh connection, instead of enforcing the single retry limit from Section 6.1.6. The reason is that if the server sends a "retry_config" and then immediately rejects the resulting connection, it's most likely misconfigured. But if the server sends a "retry_config" and the client tries to use it some time later, the server may have changed its configuration again and be trying to recover π±
Any persisted information MUST be tied to the ECHConfig source used to bootstrap the connection, such as a DNS SVCB ServiceMode record [RFC9848] π Clients MUST limit any sharing of persisted ECH-related state to connections that use the same ECHConfig source. Otherwise, the client could end up with the wrong public name for the server, and then recovery would be impossible π±
ECHConfigs learned from ECH rejection can be used as a tracking vector π Clients SHOULD apply the same lifetime and scope restrictions they use for other server-based tracking vectors, like PSKs π
In general, the safest way for clients to cut down on ECH retries is to follow any freshness rules (e.g., DNS TTLs) imposed by the ECH configuration π«Ά
6.2. GREASE ECH π
The GREASE ECH mechanism lets a connection between an ECH-capable client and a non-ECH server look like it's using ECH, which reduces how much ECH connections stick out (see Section 10.10.4) π¦β¨
6.2.1. Client Greasing β¨
Okay so, if a client tries to connect to a server and doesn't have an ECHConfig structure for it π, it SHOULD send a GREASE [RFC8701] "encrypted_client_hello" extension in the first ClientHello. Here's how to build it π :
- Set the config_id field to a random byte.
- Set the cipher_suite field to a supported HpkeSymmetricCipherSuite. The selection SHOULD vary so that all plausible configurations get exercised π, but it MAY be held constant for successive connections to the same server in the same session.
- Note: A "plausible" configuration is one that an observer might expect to see. A client that fully supports ECH will have a set of supported HPKE cipher suites to select from. A client that only supports GREASE ECH has no such list, so it should select from a set of values that are in common usage.
- Set the enc field to a randomly generated valid encapsulated public key output by the HPKE KEM.
- Set the payload field to a randomly generated string of L+C bytes, where C is the ciphertext expansion of the selected AEAD scheme and L is the size of the EncodedClientHelloInner the client would compute when offering ECH, padded according to Section 6.1.3.
If the client is sending a second ClientHello in response to a HelloRetryRequest, it copies the entire "encrypted_client_hello" extension from the first ClientHello π. The identical value will reveal to an observer that the value of "encrypted_client_hello" was fake, but this only happens if there is a HelloRetryRequest.
If the server sends an "encrypted_client_hello" extension in either HelloRetryRequest or EncryptedExtensions, the client MUST check the extension syntactically and abort the connection with a "decode_error" alert if it is invalid. Otherwise, it ignores the extension. It MUST NOT save the "retry_configs" value in EncryptedExtensions.
Offering a GREASE extension is not considered offering an encrypted ClientHello for the purposes of the requirements in Section 6.1. In particular, the client MAY offer to resume sessions established without ECH π«Ά.
6.2.2. Server Greasing π§
Section 11.3 describes a set of Reserved extensions that will never be registered. Servers can use these to "grease" the contents of the ECH configuration, as inspired by [RFC8701] π. This helps make sure clients process ECH extensions correctly. When constructing ECH configurations, servers SHOULD randomly select from reserved values with the high-order bit clear. Correctly implemented clients will ignore those extensions.
The reserved values with the high-order bit set are mandatory, as defined in Section 4.2. Servers SHOULD randomly select from these values and include them in extraneous ECH configurations. Correctly implemented clients will ignore these configurations because they do not recognize the mandatory extension. Servers SHOULD ensure that any client using these configurations encounters a warning or error message π. This can be accomplished in several ways, including:
- By giving the extraneous configurations distinctive config IDs or public names, and rejecting the TLS connection or inserting an application-level warning message when these are observed.
- By giving the extraneous configurations an invalid public key and a public name not associated with the server, so that the initial ClientHelloOuter will not be decryptable and the server cannot perform the recovery flow described in Section 6.1.6.
7. Server Behavior π
As described in Section 3.1, servers can play two roles: either the client-facing server or the backend server. The ECHClientHello will look different depending on the server's role:
- A client-facing server expects an ECHClientHello.type of outer, and proceeds as described in Section 7.1 to extract a ClientHelloInner, if one is available.
- A backend server expects an ECHClientHello.type of inner, and proceeds as described in Section 7.2.
If ECHClientHello.type is not a valid ECHClientHelloType, then the server MUST abort with an "illegal_parameter" alert.
In split mode, a client-facing server that receives a ClientHello with ECHClientHello.type of inner MUST abort with an "illegal_parameter" alert. Similarly, in split mode, a backend server that receives a ClientHello with ECHClientHello.type of outer MUST abort with an "illegal_parameter" alert.
In shared mode, a server plays both roles: it first decrypts the ClientHelloOuter and then uses the contents of the ClientHelloInner. A shared mode server that receives a ClientHello with ECHClientHello.type of inner MUST abort with an "illegal_parameter" alert, because such a ClientHello should never be received directly from the network π«.
If the "encrypted_client_hello" is not present, then the server completes the handshake normally, as described in [RFC8446].
7.1. Client-Facing Server
Upon receiving an "encrypted_client_hello" extension in an initial ClientHello, the client-facing server decides whether it will accept ECH before it negotiates any other TLS parameters. Successfully decrypting the extension results in a new ClientHello to process, so even the client's TLS version preferences may have changed π.
First, the server collects a set of candidate ECHConfig values. This list is determined by one of the two following methods:
- Compare ECHClientHello.config_id against identifiers of each known ECHConfig and select the ones that match, if any, as candidates.
- Collect all known ECHConfig values as candidates, with trial decryption below determining the final selection.
Some uses of ECH, such as local discovery mode, may randomize the ECHClientHello.config_id since it can be used as a tracking vector. In such cases, the second method SHOULD be used for matching the ECHClientHello to a known ECHConfig. See Section 10.4. Unless specified by the application profile or otherwise externally configured, implementations MUST use the first method.
The server then iterates over the candidate ECHConfig values, attempting to decrypt the "encrypted_client_hello" extension as follows π.
The server verifies that the ECHConfig supports the cipher suite indicated by the ECHClientHello.cipher_suite and that the version of ECH indicated by the client matches the ECHConfig.version. If not, the server continues to the next candidate ECHConfig.
Next, the server decrypts ECHClientHello.payload, using the private key skR corresponding to ECHConfig, as follows:
context = SetupBaseR(ECHClientHello.enc, skR,
"tls ech" || 0x00 || ECHConfig)
EncodedClientHelloInner = context.Open(ClientHelloOuterAAD,
ECHClientHello.payload)ClientHelloOuterAAD is computed from ClientHelloOuter as described in Section 5.2. The info parameter to SetupBaseR is the concatenation of "tls ech", a zero byte, and the serialized ECHConfig. If decryption fails, the server continues to the next candidate ECHConfig. Otherwise, the server reconstructs ClientHelloInner from EncodedClientHelloInner, as described in Section 5.1, and then stops iterating over the candidate ECHConfig values.
Once the server has chosen the correct ECHConfig, it MAY verify that the value in the ClientHelloOuter "server_name" extension matches the value of ECHConfig.contents.public_name, and abort with an "illegal_parameter" alert if these do not match. This optional check lets the server limit ECH connections to only use the public SNI values advertised in its ECHConfigs. The server MUST be careful not to unnecessarily reject connections if the same ECHConfig id or keypair is used in multiple ECHConfigs with distinct public names π«£.
Upon determining the ClientHelloInner, the client-facing server checks that the message includes a well-formed "encrypted_client_hello" extension of type inner and that it does not offer TLS 1.2 or below. If either of these checks fails, the client-facing server MUST abort with an "illegal_parameter" alert.
If these checks succeed, the client-facing server forwards the ClientHelloInner to the appropriate backend server, which proceeds as in Section 7.2. If the backend server responds with a HelloRetryRequest, the client-facing server forwards it, decrypts the client's second ClientHelloOuter using the procedure in Section 7.1.1, and forwards the resulting second ClientHelloInner. The client-facing server forwards all other TLS messages between the client and backend server unmodified π¨.
Otherwise, if all candidate ECHConfig values fail to decrypt the extension, the client-facing server MUST ignore the extension and proceed with the connection using ClientHelloOuter, with the following modifications:
- If sending a HelloRetryRequest, the server MAY include an "encrypted_client_hello" extension with a payload of 8 random bytes; see Section 10.10.4 for details.
- If the server is configured with any ECHConfigs, it MUST include the "encrypted_client_hello" extension in its EncryptedExtensions with the "retry_configs" field set to one or more ECHConfig structures with up-to-date keys. Servers MAY supply multiple ECHConfig values of different versions. This allows a server to support multiple versions at once πΈ.
Note that decryption failure could indicate a GREASE ECH extension (see Section 6.2), so it is necessary for servers to proceed with the connection and rely on the client to abort if ECH was required. In particular, the unrecognized value alone does not indicate a misconfigured ECH advertisement (Section 8.1.1). Instead, servers can measure occurrences of the "ech_required" alert to detect this case π.
7.1.1. Processing ClientHello after HelloRetryRequest β¨
Okay so, after the client-facing server sends or forwards a HelloRetryRequest, it does not run through Section 7.1 again for the second ClientHelloOuter π Instead, it picks up the ECHConfig selection from the first ClientHelloOuter like this:
If the client-facing server accepted ECH, it checks that the second ClientHelloOuter also has the encrypted_client_hello extension. If it doesn't, it MUST abort the handshake with a missing_extension alert π Otherwise, it checks that ECHClientHello.cipher_suite and ECHClientHello.config_id are unchanged, and that ECHClientHello.enc is empty. If any of that is off, it MUST abort the handshake with an illegal_parameter alert.
Then comes the decryption part π It opens the new ECHClientHello.payload as a second message, using the previous HPKE context:
EncodedClientHelloInner = context.Open(ClientHelloOuterAAD,
ECHClientHello.payload)ClientHelloOuterAAD gets computed the way Section 5.2 describes, except it uses the second ClientHelloOuter. If decryption fails, the client-facing server MUST abort the handshake with a decrypt_error alert. If it works, it rebuilds the second ClientHelloInner from the new EncodedClientHelloInner as described in Section 5.1, using the second ClientHelloOuter for any extensions that get referenced. Slay π
The client-facing server then forwards the resulting ClientHelloInner to the backend server. After that, it forwards all the later TLS messages between the client and backend server without changing them π¦
If the client-facing server rejected ECH, or if the first ClientHello didn't include an encrypted_client_hello extension, the client-facing server just carries on with the connection as usual. It doesn't decrypt the second ClientHello's ECHClientHello.payload value, if there even is one. Also, if the server has any ECHConfigs configured, it MUST include the encrypted_client_hello extension in its EncryptedExtensions, with the "retry_configs" field set to one or more ECHConfig structures that have up-to-date keys, as described in Section 7.1 π
Note that a client-facing server that forwards the first ClientHello cannot include its own cookie extension if the backend server sends a HelloRetryRequest. So it either has to keep state for that connection, or coordinate with the backend server to include whatever info it needs to process the second ClientHello. Main character problems π
7.2. Backend Server
Upon receiving an encrypted_client_hello extension of type inner in a ClientHello, if the backend server negotiates TLS 1.3 or higher, it MUST confirm ECH acceptance to the client by computing its ServerHello as described here π
The backend server embeds a string derived from the inner handshake in ServerHello.random β¨ It starts by computing its ServerHello as usual, except the last 8 bytes of ServerHello.random are set to zero. Then it computes the transcript hash for ClientHelloInner up to and including the modified ServerHello, as described in [RFC8446], Section 4.4.1. Let transcript_ech_conf denote the output. Finally, the backend server overwrites the last 8 bytes of ServerHello.random with this string:
accept_confirmation = HKDF-Expand-Label(
HKDF-Extract(0, ClientHelloInner.random),
"ech accept confirmation",
transcript_ech_conf,
8)HKDF-Expand-Label is defined in [RFC8446], Section 7.1, and "0" means a string of Hash.length bytes set to zero. Hash is the hash function used to compute the transcript hash. In DTLS, the modified version of HKDF-Expand-Label defined in [RFC9147], Section 5.9 is used instead π§
The backend server MUST NOT do this operation if it negotiated TLS 1.2 or below. Doing so would overwrite the downgrade signal for TLS 1.3 (see [RFC8446], Section 4.1.3), so it's a big no-no π ββοΈ
7.2.1. Sending HelloRetryRequest
When the backend server sends HelloRetryRequest in response to the ClientHello, it confirms ECH acceptance in a similar way, by adding a confirmation signal to its HelloRetryRequest π¦ The twist is that instead of embedding the signal in HelloRetryRequest.random (the value of which is specified by [RFC8446]), it sends the signal in an extension.
The backend server starts by computing HelloRetryRequest as usual, except that it also includes an encrypted_client_hello extension with a payload of 8 zero bytes. Then it computes the transcript hash for the first ClientHelloInner, called ClientHelloInner1, up to and including the modified HelloRetryRequest. Let transcript_hrr_ech_conf denote the output. Finally, the backend server overwrites the payload of the encrypted_client_hello extension with this string:
hrr_accept_confirmation = HKDF-Expand-Label(
HKDF-Extract(0, ClientHelloInner1.random),
"hrr ech accept confirmation",
transcript_hrr_ech_conf,
8)In the ServerHello message that comes next, the backend server sends the accept_confirmation value as described in Section 7.2 π
8. Deployment Considerations β¨
The design of ECH in this document necessarily requires changes to the client, the client-facing server, and the backend server π οΈ Coordinating the client-facing and backend servers takes real care, since deployment mistakes can cause compatibility issues. These are covered in Section 8.1.
Beyond the coordination headaches, ECH deployments can also make things tricky for anything that uses the information ECH protects π In particular, use cases that depend on that unencrypted information may stop working the way they used to. This is explained more in Section 8.2.
8.1. Compatibility Issues
Unlike most TLS extensions, putting the SNI value in an ECH extension is not interoperable with existing servers, because they expect the value in the existing plaintext extension π¬ So server operators SHOULD make sure their servers understand a given set of ECH keys before advertising them. On top of that, servers SHOULD keep supporting any previously advertised keys for as long as those keys are valid.
Still, in more complicated deployments, that can be hard to guarantee. This protocol was designed to be robust when the systems advertising ECH keys and the servers don't line up, but the cost is extra round-trips because of a retry. Two specific scenarios are detailed below πΈ
8.1.1. Misconfiguration and Deployment Concerns
ECH advertisements and servers can become inconsistent, which is a very real vibe π This can happen because of DNS misconfiguration, caching issues, or an incomplete rollout in a multi-server deployment. It can also happen if a server loses its ECH keys, or if an ECH deployment has to be rolled back on the server.
The retry mechanism repairs these inconsistencies, as long as the TLS server has a certificate for the public name π«Ά If the server's keys and the advertised keys don't match, the server will reject ECH and respond with "retry_configs". If the server doesn't understand the encrypted_client_hello extension at all, it will ignore it, as required by Section 4.1.2 of [RFC8446]. As long as the server can present a certificate valid for the public name, the client can safely retry with updated settings, as described in Section 6.1.6 β¨
Unless ECH gets disabled because a connection to the public name was successfully established, the client MUST NOT fall back to using unencrypted ClientHellos. Doing that would let a network attacker disclose the contents of this ClientHello, including the SNI π¨ The client MAY try another server from the DNS results, if one is provided.
To make sure the retry mechanism works, servers SHOULD make sure that every endpoint which might receive a TLS connection has an appropriate certificate for the public name π This matters extra during periods of server reconfiguration, when different endpoints might have different configurations.
8.1.2. Middleboxes
The requirements in [RFC8446], Section 9.3 say that proxies have to act as conforming TLS clients and servers. That's what gives interoperability with TLS-terminating proxies, even when the server supports ECH but the proxy doesn't π§ Here's how that plays out:
The proxy must ignore unknown parameters and generate its own ClientHello containing only parameters it understands. So when it presents a certificate to the client, or sends a ClientHello to the server, the proxy acts as if it's connecting to the ClientHelloOuter server_name. That server_name SHOULD match the public name (see Section 6.1), and the proxy doesn't echo the encrypted_client_hello extension.
Depending on whether the client is set up to accept the proxy's certificate as authoritative for the public name, this may trigger the retry logic described in Section 6.1.6, or it may just end in a connection failure. A proxy that isn't authoritative for the public name cannot forge a signal to disable ECH π‘οΈ
8.2. Deployment Impact
Some use cases that depend on information ECH encrypts may break once ECH is deployed π How bad the breakage is depends on a bunch of outside factors. That includes whether ECH can be disabled, whether the party disabling it is trusted to do so, and whether client implementations will fall back to TLS without ECH when it gets disabled.
Depending on implementation details and deployment settings, use cases that rely on plaintext TLS information might need totally different approaches to keep working π For example, in managed enterprise settings, one option is to disable ECH entirely through group policy, with client implementations honoring that action. Server deployments that depend on SNI (for example, for load balancing) may stop functioning properly without updates. The nature of those updates is out of scope for this specification.
In the context of Section 6.1.6, another approach might be to intercept and decrypt client TLS connections π Whether the alternative solutions are feasible is specific to each deployment.
9. Compliance Requirements
Unless an application profile standard says otherwise, a compliant ECH application MUST implement the following HPKE cipher suite π
- KEM:
DHKEM(X25519, HKDF-SHA256)(see Section 7.1 of [HPKE]) - KDF:
HKDF-SHA256(see Section 7.2 of [HPKE]) - AEAD:
AES-128-GCM(see Section 7.3 of [HPKE])
10. Security Considerations π
This section contains security considerations for ECH.
10.1. Security and Privacy Goals β¨
okay so ECH thinks about two kinds of attackers π. Passive attackers can read packets off the network, but that's all they can do. They can't poke at servers or query DNS. A middlebox that filters based on plaintext packet contents is a good example of a passive attacker π§. Active attackers can also write packets into the network for bad reasons, like messing with existing connections, probing servers, and querying DNS π€. Basically, an active attacker is the classic threat model from [RFC3552] for TLS 1.3 [RFC8446], and that's the one we're dealing with π .
Passive and active attackers can show up anywhere in the network π. That includes between the client and the client-facing server, and also between the client-facing and backend servers when ECH runs in split mode π°. Split mode comes with two extra assumptions though, so pay attention bestie π«Ά:
- The channel between each client-facing and each backend server is authenticated, so the backend server only accepts messages from trusted client-facing servers π. How they set up that authenticated channel is out of scope for this document.
- The attacker cannot correlate messages between a client and a client-facing server with messages between the client-facing and backend servers π«. That kind of correlation would let an attacker link stuff unique to a backend server, like its server name or IP address, with a client's encrypted ClientHelloInner π±. It could happen through timing analysis of messages across the client-facing server, or by looking at what's inside the messages sent between client-facing and backend servers. How to prevent this sort of correlation is out of scope for this document.
With that threat model in mind, the main goals of ECH are:
- Security preservation. Using ECH does not weaken the security properties of TLS without ECH π‘οΈ.
- Handshake privacy. A TLS connection set up to a server name inside an anonymity set looks exactly the same as a connection to any other server name in that anonymity set π₯Έ. (The anonymity set is defined in Section 1.)
- Downgrade resistance. An attacker cannot downgrade a connection that tries to use ECH into one that doesn't use ECH π ββοΈ.
These properties were formally proven in [ECH-Analysis] π, so they're not just vibes, they're receipts π§Ύβ¨.
About handshake privacy: the client-facing server's configuration decides how big the anonymity set is π. Say a client-facing server uses a distinct ECHConfig value for each server name. Then every anonymity set has size k = 1, which is not it π. So client-facing servers SHOULD deploy ECH in a way that maximizes the size of the anonymity set wherever possible π. Concretely, that means they should use the same ECHConfig for as many server names as they can π«. An attacker can tell apart two server names that have different ECHConfig values by looking at the ECHClientHello.config_id value π.
The public info in a TLS handshake also needs to stay consistent across server names π. For example, if a client-facing server serves lots of backend origin server names, and only one of them supports some cipher suite, the attacker might be able to figure out that server name from the unencrypted handshake message π. Same deal if a backend origin reuses KeyShare values, because then those values act like a unique ID for that server πͺͺ.
ECH also tries to hide, to some extent, the fact that it's being used at all π«£. The GREASE ECH extension from Section 6.2 doesn't change the security properties of the TLS handshake one bit π§. Its whole job is to provide "cover" for the real ECH protocol (Section 6.1), so it can address the "do not stick out" requirements of [RFC8744] π¦. See Section 10.10.4 for details.
10.2. Unauthenticated and Plaintext DNS π
ECH supports delivering configurations through DNS using SVCB or HTTPS records π¬. The catch is that there's no verifiable authenticity or provenance info required for that, see [RFC9848] π¬. So any attacker that can inject DNS responses or poison DNS caches can give clients fake ECH configurations, so the client ends up encrypting data to the attacker π₯². They could also strip the ECH configurations out of the response ποΈ. Injecting DNS responses or poisoning caches is a pretty common thing on client access networks, so yeah, this is a real concern π¨.
Here's the good news (sort of) π« : if an attacker controls DNS, no encryption scheme can really save you. The attacker can swap in a different IP address and block the client's connections, or swap in a unique IP address for each DNS name that gets looked up π. So relying on DNS records without extra authentication doesn't make things significantly worse π€·ββοΈ.
DNSSEC is a defense against this kind of attack, as long as the client validates and hard fails π. Encrypted DNS transport is also a defense against DNS attacks from attackers on the local network π , and that's a really common case where ClientHello and SNI encryption are wanted π. As the introduction noted, SNI encryption is less useful without encryption of DNS queries in transit π. Iykyk π.
10.3. Client Tracking π΅οΈββοΈ
A malicious client-facing server could hand out unique, per-client ECHConfig structures and use them to track clients across later connections π«£. On-path adversaries who know about those unique keys could track clients the same way, just by watching TLS connection attempts ποΈ.
The cost of this attack goes up linearly with the number of target clients you want to track π. DNS caching makes it hard to target individual users for long stretches of time, though π§. For example, per-client ECHConfig structures delivered through HTTPS RRs with high TTLs are pretty challenging to use for that π€. Clients can help with this by flushing any DNS or ECHConfig state when they change networks π. (That might not be possible if clients use the operating system resolver instead of doing their own resolution π₯οΈ.)
Rotation rate is also a thing for servers that aren't malicious π. Those servers may want to rotate keys often to limit exposure if a key gets compromised π. But rotating too often shrinks the client anonymity set π. In practice though, servers that handle many server names and therefore have high loads are the best candidates to be client-facing servers πͺ. So anonymity sets will usually involve many connections, even when the rotation interval is pretty fast β‘.
10.4. Ignored Configuration Identifiers and Trial Decryption π§©
Ignoring configuration identifiers can be useful when clients and client-facing servers don't want to reveal info about the client-facing server in the "encrypted_client_hello" extension π. In those settings, clients send a randomly generated config_id in the ECHClientHello π². Servers in those settings have to do trial decryption, since they can't figure out which ECH key the client picked using the config_id value π« . That makes things messier: ignoring configuration identifiers may make DoS attacks worse π₯. An adversary can send malicious ClientHello messages, meaning ones that won't decrypt with any known ECH key, just to force wasteful decryption π©. Servers that support this feature should, for example, implement some form of rate limiting to cap the damage from those attacks π¦.
Unless the application using (D)TLS specifies it, or it's configured externally, client implementations MUST NOT use this mode π«. Big no-no, bestie π ββοΈ.
10.5. Outer ClientHello π
Anything the client puts in the ClientHelloOuter is visible to passive observers π. So the client SHOULD NOT send values in the ClientHelloOuter that would reveal a sensitive ClientHelloInner property, like the true server name π€«. It MAY send values associated with the public name in the ClientHelloOuter π£.
Some extensions require the client to send a server-name-specific value in the ClientHello π¬. Those values can reveal info about the true server name. For example, the "cached_info" ClientHello extension [RFC7924] can contain the hash of a previously observed server certificate π§Ύ. The client SHOULD NOT send values associated with the true server name in the ClientHelloOuter, but it MAY send those values in the ClientHelloInner π«Ά.
A client may also use different preferences in different contexts π. For example, it might send different ALPN lists to different servers, or in different application contexts π. A client that treats this context as sensitive SHOULD NOT send context-specific values in ClientHelloOuter π.
Values that don't depend on the true server name, or on other info the client wants to protect, MAY be included in ClientHelloOuter β . If they match the corresponding ClientHelloInner, they MAY be compressed as described in Section 5.1 ποΈ. But heads up: the payload length reveals info about which extensions are compressed π. So inner extensions that only sometimes match the corresponding outer extension SHOULD NOT be compressed π ββοΈ.
Clients MAY include additional extensions in ClientHelloOuter to avoid signaling unusual behavior to passive observers π¦, as long as the choice of value and the value itself aren't sensitive πΈ. See Section 10.10.4.
10.6. Inner ClientHello π₯
Values that depend on the contents of the ClientHelloInner, like the true server name, can influence how the client-facing server processes this message π§. Timing side channels in particular can reveal info about what's inside the ClientHelloInner β±οΈ. Implementations should take those side channels into account when they reason about the privacy properties ECH provides π§ .
10.7. Related Privacy Leaks π«’
ECH needs encrypted DNS to be an effective privacy protection mechanism π. But verifying the server's identity from the Certificate message can cause extra network traffic, and that traffic can reveal the server identity π±. This is especially true when using the X509 CertificateType. Examples include requests for revocation info, like Online Certificate Status Protocol (OCSP) or Certificate Revocation List (CRL) traffic, or requests for repository info, like authorityInformationAccess π‘. It can also include implementation-specific traffic for extra info sources used during verification π οΈ.
Implementations SHOULD avoid leaking info that may identify the server π. Even when those requests go over an encrypted transport, they can still indirectly expose the server's identity, like by hinting at a specific CA or service being used π΅οΈ. To lower this risk, servers SHOULD deliver such info in-band when possible, for example through OCSP stapling π¦. And clients SHOULD take steps to minimize or protect those requests during certificate validation π‘οΈ.
Attacks that rely on non-ECH traffic to infer the server identity in an ECH connection are out of scope for this document π«. For example, say a client connects to a particular host before ECH is deployed, and later resumes a connection to that same host after ECH is deployed π. An adversary who sees this can deduce that the ECH-enabled connection went to a host the client previously connected to, and that host is within the same anonymity set π«£. Okay, that's the security tea for this part π΅π.
10.8. Cookies β¨
okay so bestie, this one is about HelloRetryRequest cookies πͺ Section 4.2.2 of [RFC8446] says servers can send a cookie inside HelloRetryRequest, and the client echoes it back in the second ClientHello. ECH encrypts the cookie inside the second ClientHelloInner, BUT the backend server's HelloRetryRequest is sent in the clear π so if different backend servers have different cookies (different lengths, or some readable bit stuck on the front), that difference can leak which server you're talking to. not it π
Backend servers in an anonymity set SHOULD NOT reveal information in the cookie which identifies the server. You can handle HelloRetryRequest statefully so you don't send cookies at all, or you can use the same cookie construction on every backend server. Both are valid ways to stop the leak π
Also, if the cookie has a key name (kinda like Section 4 of [RFC5077]), that name can leak info if different backend servers are issuing cookies with different key names at the time of the connection π Especially if the deployment is in split mode, the backend servers might not share cookie encryption keys. To deal with it, backend servers can either handle key rotation with trial decryption, or they can coordinate so the key names match π«Ά
10.9. Attacks Exploiting Acceptance Confirmation π¦
okay this one is giving "tiny collision risk, but it's fine" energy π
To signal acceptance, the backend server overwrites 8 bytes of its ServerHello.random with a value derived from the ClientHelloInner.random. (See Section 7.2 for details.) This makes it more likely that the ServerHello.random collides with the ServerHello.random of a previous session, which could lower the overall security of the protocol π¬ BUT the other 24 bytes have enough entropy that this is not a practical attack. phew πΈ
Still, the chance that two 8-byte strings match is not zero, so it's a modest operational risk π₯Ί Say the client-facing server ends the connection (so ECH is rejected or bypassed). If the last 8 bytes of its ServerHello.random happen to match the confirmation signal, the client will wrongly think ECH was accepted and act like the backend server ended the connection. The chance of a false positive for any given connection is only 1 in 2^64 though, which is smaller than regular network connection failures in real life π
Quick note: the same bytes of ServerHello.random are also used for downgrade protection in TLS 1.3 (see [RFC8446], Section 4.1.3). These two things don't interfere, because the backend server only signals ECH acceptance in TLS 1.3 or higher β¨
10.10. Comparison Against Criteria π
okay so [RFC8744] lists a bunch of requirements for SNI encryption, and in this section we go back over them and check how the ECH design holds up π§
10.10.1. Mitigate Cut-and-Paste Attacks βοΈ
Servers process either ClientHelloInner or ClientHelloOuter, and ClientHelloInner.random is encrypted. So an attacker can't "cut and paste" the ECH value into a different Client Hello and learn anything from ClientHelloInner. literally iconic π
10.10.2. Avoid Widely Shared Secrets π
This design uses DNS as a way to hand out semi-static public keys. Server operators can split up their private keys however they like, as long as every server behind an IP address has the matching private key to decrypt a key. So when one ECH key is given out, the sharing is best limited by how many hosts share an IP address π Operators can also cut down on sharing by publishing different DNS records with ECHConfig values that have different public keys, using a short TTL β±οΈ
10.10.3. SNI-Based Denial-of-Service Attacks π¨
This design requires servers to decrypt ClientHello messages that have ECHClientHello extensions carrying valid digests. So yes, an attacker can make the server do decryption work π But that attack is capped by how many valid transport connections the attacker can open.
10.10.4. Do Not Stick Out π
okay this one is about blending in π«£ As a way to cut down on network ossification, [RFC8744] recommends that SNI-protection mechanisms be designed so network operators can't tell connections using the mechanism apart from ones that don't. So ECH is built to look like a standard TLS handshake as much as possible β¨ The most obvious difference is the extension itself. As long as middleboxes ignore it, as required by [RFC8446], the rest of the handshake looks totally normal π
The GREASE ECH protocol in Section 6.2 is a low-risk way to test whether ECH is deployable π§ͺ It's designed to mimic the real ECH protocol (Section 6.1) without changing the security properties of the handshake. The theory is that if GREASE ECH can be deployed without making middleboxes misbehave, and real ECH looks enough like GREASE ECH, then real ECH should be deployable too π So the plan for handling network ossification is to deploy GREASE ECH widely enough that networks have no reason to treat real ECH differently π
Making sure networks don't tell real ECH and GREASE ECH apart might not be possible for every implementation π₯² Most middleboxes won't treat them differently, but some operators might want to block real ECH while still allowing GREASE ECH. This spec aims for a baseline security level that most deployments can reach easily, while giving implementations room to get stronger security where they can π At minimum, real ECH is designed to be indistinguishable from GREASE ECH for passive adversaries with these capabilities:
- The attacker does not know the ECHConfigList used by the server.
- The attacker keeps per-connection state only. In particular, it does not track endpoints across connections.
Real ECH and GREASE ECH are also designed so these features don't noticeably vary to the attacker, meaning they are not distinguishers:
- the code points of extensions negotiated in the clear, and their order;
- the length of messages; and
- the values of plaintext alert messages.
This leaves a bunch of practical differentiators out of scope, including (but not limited to) these:
- the value of the configuration identifier;
- the value of the outer SNI;
- the TLS version negotiated, which may depend on ECH acceptance;
- client authentication, which may depend on ECH acceptance; and
- HRR issuance, which may depend on ECH acceptance.
These can be handled by fancier implementations, but some mitigations need the client and server to coordinate, even across different client and server implementations. Those mitigations are out of scope for this spec π
10.10.5. Maintain Forward Secrecy π
This design doesn't give forward secrecy for the inner ClientHello, because the server's ECH key is static π¬ The good news is that the window of exposure is limited by the key lifetime. It is RECOMMENDED that servers rotate keys regularly π
10.10.6. Enable Multi-party Security Contexts π€
This design lets servers in split mode forward connections directly to backend origin servers. The client authenticates the backend origin server's identity, so the backend can hide behind the client-facing server without the client-facing server decrypting and re-encrypting the connection π¦
On the flip side, if the DNS records used for configuration are authenticated (e.g., with DNSSEC), spoofing a client-facing server in split mode is not possible. See Section 10.2 for more about plaintext DNS.
Authenticating the ECHConfig structure naturally authenticates the included public name. This also authenticates any retry signals from the client-facing server, because the client validates the server certificate against the public name before retrying π
10.10.7. Support Multiple Protocols π
This design has no impact on application layer protocol negotiation. It may affect connection routing, server certificate selection, and client certificate verification. So it works with multiple application and transport protocols. And since the entire ClientHello is encrypted, this design also supports encrypting the ALPN extension π«Ά
10.11. Padding Policy π
okay so the length of the ClientHelloInner ciphertext could leak info about the plaintext, which is a whole vibe-killer π Section 6.1.3 describes a RECOMMENDED padding mechanism for clients to help reduce that leakage π
10.12. Active Attack Mitigations βοΈ
this section explains why ECH works the way it does as a defense against active attacks π‘οΈ In all of these attacks, the attacker is on-path between the target client and server. The attacker's goal is to learn private info about the inner ClientHello, like the true SNI value π
10.12.1. Client Reaction Attack Mitigation π΅οΈ
this attack uses the client's reaction to a wrong certificate as an oracle π± The attacker intercepts a legit ClientHello and replies with ServerHello, Certificate, CertificateVerify, and Finished messages, where the Certificate has a "test" certificate for the domain name they want to check. If the client decrypts the Certificate and fails verification (or leaks info about its verification process through a timing side channel), the attacker learns their test certificate name was wrong. For example, say the client's SNI in its inner ClientHello is "example.com" and the attacker replies with a Certificate for "test.com". If the client throws a verification failure alert for the mismatch faster than it would for Certificate signature validation, the name leaks π The attacker can also hold back the CertificateVerify message. In that case, a client that verifies the Certificate first would respond similarly and leak the same info π
Client Attacker Server ClientHello
- key_share
- ech ------> (intercept) -----> X (drop)
ServerHello
- key_share {EncryptedExtensions} {CertificateRequest*} {Certificate*} {CertificateVerify*} <------ Alert ------>
Figure 3: Client Reaction Attack
ClientHelloInner.random stops this attack π The attacker doesn't have access to this value, so it can't produce the right transcript and handshake keys needed to encrypt the Certificate message. So the client fails to decrypt the Certificate and aborts the connection πΈ
10.12.2. HelloRetryRequest Hijack Mitigation β¨
Okay bestie, this attack is sneaky π΅οΈββοΈ. It tries to mess with how the server handles HelloRetryRequest (HRR) state so the attacker can dig up info from a legit ClientHello using its own attacker-controlled ClientHello. Here's the tea: the attacker intercepts and forwards a legit ClientHello with an "encrypted_client_hello" (ech) extension to the server, which triggers a legit HRR back. Instead of forwarding the retry to the client, the attacker makes its own ClientHello based on the first ClientHello and HRR exchange, so the server ends up encrypting the Certificate to the attacker π±. If the server used the SNI from the first ClientHello and the key share from the second (attacker-controlled) ClientHello, that Certificate would leak the client's chosen SNI to the attacker π.
Client Attacker Server
ClientHello
+ key_share
+ ech ------> (forward) ------->
HelloRetryRequest
+ key_share
(intercept) <-------
ClientHello
+ key_share'
+ ech' ------->
ServerHello
+ key_share
{EncryptedExtensions}
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}
{Finished}
<-------
(process server flight)Figure 4: HelloRetryRequest Hijack Attack
The good news is this attack gets mitigated by using the same HPKE context for both ClientHello messages π. The attacker doesn't have the context's keys, so it can't generate a valid encryption of the second inner ClientHello. Slay.
If the attacker could manipulate the second ClientHello, the server could become an oracle π if it required parameters from the first ClientHello to match those of the second. For example, say the client's original SNI value in the inner ClientHello is "example.com", and the attacker's hijacked SNI value in its inner ClientHello is "test.com". A server that checks these for equality and changes its behavior based on the result can be used as an oracle to learn the client's SNI. Not me getting nervous about this π.
10.12.3. ClientHello Malleability Mitigation π¦
This attack is all about leaking info about the secret parts of the encrypted ClientHello. The attacker adds attacker-controlled parameters and then watches how the server responds π. The compression mechanism in Section 5.1 references parts of a potentially attacker-controlled ClientHelloOuter to build ClientHelloInner, or a buggy server may incorrectly apply parameters from ClientHelloOuter to the handshake. Yikes.
Here's how it goes down. First, the attacker interacts with a server to get a resumption ticket for a given test domain, such as "example.com". Later, when it receives a ClientHelloOuter, it modifies it so the server will process the resumption ticket with ClientHelloInner. If the server only accepts resumption PSKs that match the server name, it fails the PSK binder check with an alert when ClientHelloInner is for "example.com", but it silently ignores the PSK and keeps going when ClientHelloInner is for any other name. That creates an oracle for testing encrypted SNI values π₯.
Client Attacker Server
handshake and ticket
for "example.com"
<-------->
ClientHello
+ key_share
+ ech
+ ech_outer_extensions(pre_shared_key)
+ pre_shared_key
-------->
(intercept)
ClientHello
+ key_share
+ ech
+ ech_outer_extensions(pre_shared_key)
+ pre_shared_key'
-------->
Alert
-or-
ServerHello
...
Finished
<--------Figure 5: Message Flow for Malleable ClientHello
This attack can be generalized to any parameter the server varies by server name, such as ALPN preferences π.
ECH mitigates this attack by only negotiating TLS parameters from ClientHelloInner and by authenticating all inputs to the ClientHelloInner (EncodedClientHelloInner and ClientHelloOuter) with the HPKE AEAD. See Section 5.2. The decompression process in Section 5.1 forbids "encrypted_client_hello" in OuterExtensions. This makes sure the unauthenticated portion of ClientHelloOuter doesn't get pulled into ClientHelloInner, which is so iconic π . An earlier iteration of this specification only encrypted and authenticated the "server_name" extension, which left the overall ClientHello vulnerable to an analogue of this attack. Bestie, that's a lesson in not half-doing it π«Ά.
10.12.4. ClientHelloInner Packet Amplification Mitigation π₯
Client-facing servers must decompress EncodedClientHelloInners. A malicious attacker may craft a packet that takes excessive resources to decompress, or one that may be much larger than the incoming packet π€:
- If looking up a ClientHelloOuter extension takes time linear in the number of extensions, the overall decoding process would take O(M*N) time, where M is the number of extensions in ClientHelloOuter and N is the size of OuterExtensions.
- If the same ClientHelloOuter extension can be copied multiple times, an attacker could cause the client-facing server to construct a large ClientHelloInner by including a large extension in ClientHelloOuter of length L and an OuterExtensions list referencing N copies of that extension. The client-facing server would then use O(N*L) memory in response to O(N+L) bandwidth from the client. In split mode, an O(N*L)-sized packet would then be transmitted to the backend server.
ECH mitigates this attack by requiring that OuterExtensions be referenced in order, by rejecting duplicate references, and by recommending that client-facing servers use a linear scan to perform decompression π§. These requirements are detailed in Section 5.1.
11. IANA Considerations π
11.1. Update of the TLS ExtensionType Registry π
IANA has created the following entries in the existing "TLS ExtensionType Values" registry (defined in [RFC8446]):
encrypted_client_hello(0xfe0d), with the "TLS 1.3" column values set to "CH, HRR, EE", the "DTLS-Only" column set to "N", and the "Recommended" column set to "Y".ech_outer_extensions(0xfd00), with the "TLS 1.3" column values set to "CH", the "DTLS-Only" column set to "N", the "Recommended" column set to "Y", and the "Comment" column set to "Only appears in inner CH."
11.2. Update of the TLS Alert Registry π¨
IANA has created an entry, ech_required (121), in the existing "TLS Alerts" registry (defined in [RFC8446]), with the "DTLS-OK" column set to "Y".
11.3. ECH Configuration Extension Registry π
IANA has created a new "TLS ECHConfig Extension" registry in a new "TLS Encrypted Client Hello (ECH) Configuration Extensions" registry group. New registrations will list the following attributes:
- Value: The two-byte identifier for the ECHConfigExtension, i.e., the ECHConfigExtensionType
- Extension Name: Name of the ECHConfigExtension
- Recommended: A "Y" or "N" value indicating whether the TLS Working Group recommends that the extension be supported. This column is assigned a value of "N" unless explicitly requested. Adding a value of "Y" requires Standards Action [RFC8126].
- Reference: The specification where the ECHConfigExtension is defined
- Notes: Any notes associated with the entry
New entries in the "TLS ECHConfig Extension" registry are subject to the Specification Required registration policy ([RFC8126], Section 4.6), with the policies described in [RFC9847], Section 16. IANA has added the following note to the "TLS ECHConfig Extension" registry:
Note: The role of the designated expert is described in RFC 9847. The designated expert [RFC8126] ensures that the specification is publicly available. It is sufficient to have an Internet-Draft (that is posted and never published as an RFC) or a document from another standards body, industry consortium, university site, etc. The expert may provide more in-depth reviews, but their approval should not be taken as an endorsement of the extension.
This document defines several Reserved values for ECH configuration extensions to be used for "greasing" as described in Section 6.2.2. π«§
The initial contents for this registry consist of multiple reserved values with the following attributes, which are repeated for each registration:
Value: 0x0000, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A,
0x7A7A, 0x8A8A, 0x9A9A, 0xAAAA, 0xBABA, 0xCACA, 0xDADA, 0xEAEA,
0xFAFA
Extension Name: RESERVED
Recommended: Y
Reference: RFC 9849
Notes: GREASE entries12. References π
12.1. Normative References πβ¨
Okay bestie, these are the references the spec leans on hardest, so you'll want to actually read them π€π
[HPKE] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
February 2022, <https://www.rfc-editor.org/info/rfc9180>.
[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>.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>.
[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport
Layer Security (TLS) False Start", RFC 7918,
DOI 10.17487/RFC7918, August 2016,
<https://www.rfc-editor.org/info/rfc7918>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[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>.
[RFC9460] 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>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/info/rfc9525>.
[RFC9847] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 9847, DOI 10.17487/RFC9847, December 2025,
<https://www.rfc-editor.org/info/rfc9847>.12.2. Informative References π¦π
These ones are the extra-helpful reading list: background, context, and the cousins of this whole spec π Nothing in here is required, but it's so worth a peek π
[DNS-TERMS]
Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
[ECH-Analysis]
Bhargavan, K., Cheval, V., and C. Wood, "A Symbolic
Analysis of Privacy for TLS 1.3 with Encrypted Client
Hello", CCS '22: Proceedings of the 2022 ACM SIGSAC
Conference on Computer and Communications Security, pp.
365-379, DOI 10.1145/3548606.3559360, November 2022,
<https://www.cs.ox.ac.uk/people/vincent.cheval/publis/BCW-
ccs22.pdf>.
[PROTECTED-SNI]
Oku, K., "TLS Extensions for Protecting SNI", Work in
Progress, Internet-Draft, draft-kazuho-protected-sni-00,
18 July 2017, <https://datatracker.ietf.org/doc/html/
draft-kazuho-protected-sni-00>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", RFC 7924,
DOI 10.17487/RFC7924, July 2016,
<https://www.rfc-editor.org/info/rfc7924>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017,
<https://www.rfc-editor.org/info/rfc8094>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
[RFC8701] Benjamin, D., "Applying Generate Random Extensions And
Sustain Extensibility (GREASE) to TLS Extensibility",
RFC 8701, DOI 10.17487/RFC8701, January 2020,
<https://www.rfc-editor.org/info/rfc8701>.
[RFC8744] Huitema, C., "Issues and Requirements for Server Name
Identification (SNI) Encryption in TLS", RFC 8744,
DOI 10.17487/RFC8744, July 2020,
<https://www.rfc-editor.org/info/rfc8744>.
[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over
Dedicated QUIC Connections", RFC 9250,
DOI 10.17487/RFC9250, May 2022,
<https://www.rfc-editor.org/info/rfc9250>.
[RFC9848] 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>.
[WHATWG-IPV4]
WHATWG, "URL - IPv4 Parser", WHATWG Living Standard, May
2021, <https://url.spec.whatwg.org/>. Commit snapshot:
<https://url.spec.whatwg.org/commit-
snapshots/1b8b8c55eb4bed9f139c9a439fb1c1bf5566b619/#concept-
ipv4-parser>.Appendix A. Linear-Time Outer Extension Processing π§
Okay so this is the linear-time procedure for handling "ech_outer_extensions" (see Section 5.1) π It walks through the list in linear time and makes sure each extension that gets referenced in the ClientHelloOuter is included at most once β¨ Here's how it goes:
- Let
Ibe initialized to zero andNbe set to the number of extensions in ClientHelloOuter. - For each extension type,
E, in OuterExtensions:- If
Eis"encrypted_client_hello", abort the connection with an"illegal_parameter"alert and terminate this procedure. - While
Iis less thanNand theI-th extension of ClientHelloOuter does not have typeE, incrementI. - If
Iis equal toN, abort the connection with an"illegal_parameter"alert and terminate this procedure. - Otherwise, the
I-th extension of ClientHelloOuter has typeE. Copy it to the EncodedClientHelloInner and incrementI.
- If
Acknowledgements π«Ά
This document is basically built on the shoulders of [PROTECTED-SNI] π It's a much more limited mechanism, though, because it depends on the DNS for protecting the ECH key, so it's a little more chill in scope. A huge thank-you to Richard Barnes, Christian Huitema, Patrick McManus, Matthew Prince, Nick Sullivan, Martin Thomson, and David Benjamin, who also brought important ideas and contributions to the table π
Authors' Addresses π
Eric Rescorla
Independent
Email: ekr@rtfm.com
Kazuho Oku
Fastly
Email: kazuhooku@gmail.com
Additional contact information:
ε₯₯ δΈη©
Fastly
Nick Sullivan
Cryptography Consulting LLC
Email: nicholas.sullivan+ietf@gmail.com
Christopher A. Wood
Apple
Email: caw@heapingbits.netπ¦ where this page comes from
- ietf: rfc9849 2026-03
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms