3.1.Topologies

                +---------------------+                |                     |                |   2001:DB8::1111    |                |                     |Client <----->  | private.example.org |                |                     |                | public.example.com  |                |                     |                +---------------------+                        Server          (Client-Facing and Backend Combined)

In Shared Mode, the provider is the origin server for all the domains whose DNSrecords point to it. In this mode, the TLS connection is terminated by theprovider.¶

           +--------------------+     +---------------------+           |                    |     |                     |           |   2001:DB8::1111   |     |   2001:DB8::EEEE    |Client <----------------------------->|                     |           | public.example.com |     | private.example.com |           |                    |     |                     |           +--------------------+     +---------------------+            Client-Facing Server            Backend Server

In Split Mode, the provider is not the origin server for private domains.Rather, the DNS records for private domains point to the provider, and theprovider's server relays the connection back to the origin server, whoterminates the TLS connection with the client. Importantly, the service providerdoes not have access to the plaintext of the connection beyond the unencryptedportions of the handshake.¶

In the remainder of this document, we will refer to the ECH-service provider asthe "client-facing server" and to the TLS terminator as the "backend server".These are the same entity in Shared Mode, but in Split Mode, the client-facingand backend servers are physically separated.¶

3.2.Encrypted ClientHello (ECH)

A client-facing server enables ECH by publishing an ECH configuration, whichis an encryption public key and associated metadata. The server must publishthis for all the domains it serves via Shared or Split Mode. This documentdefines the ECH configuration's format, but delegates DNS publication detailsto[HTTPS-RR]. Other delivery mechanisms are alsopossible. For example, the client may have the ECH configuration preconfigured.¶

When a client wants to establish a TLS session with some backend server, itconstructs a private ClientHello, referred to as the ClientHelloInner.The client then constructs a public ClientHello, referred to as theClientHelloOuter. The ClientHelloOuter contains innocuous values forsensitive extensions and an "encrypted_client_hello" extension(Section 5), which carries the encrypted ClientHelloInner.Finally, the client sends ClientHelloOuter to the server.¶

The server takes one of the following actions:¶

1. If it does not support ECH or cannot decrypt the extension, it completesthe handshake with ClientHelloOuter. This is referred to as rejecting ECH.¶
2. If it successfully decrypts the extension, it forwards the ClientHelloInnerto the backend server, which completes the handshake. This is referred toas accepting ECH.¶

Upon receiving the server's response, the client determines whether or not ECHwas accepted (Section 6.1.4) and proceeds with the handshakeaccordingly. When ECH is rejected, the resulting connection is not usable bythe client for application data. Instead, ECH rejection allows the client toretry with up-to-date configuration (Section 6.1.6).¶

The primary goal of ECH is to ensure that connections to servers in the sameanonymity set are indistinguishable from one another. Moreover, it shouldachieve this goal without affecting any existing security properties of TLS 1.3.SeeSection 10.1 for more details about the ECH security and privacy goals.¶

4.1.Configuration Identifiers

A client-facing server has a set of known ECHConfig values, with correspondingprivate keys. This set SHOULD contain the currently published values, as well asprevious values that may still be in use, since clients may cache DNS recordsup to a TTL or longer.¶

Section 7.1 describes a trial decryption process for decrypting theClientHello. This can impact performance when the client-facing server maintainsmany known ECHConfig values. To avoid this, the client-facing server SHOULDallocate distinctconfig_id values for each ECHConfig in its known set. TheRECOMMENDED strategy is via rejection sampling, i.e., to randomly selectconfig_id repeatedly until it does not match any known ECHConfig.¶

It is not necessary forconfig_id values across different client-facingservers to be distinct. A backend server may be hosted behind two differentclient-facing servers with collidingconfig_id values without any performanceimpact. Values may also be reused if the previous ECHConfig is no longer in theknown set.¶

4.2.Configuration Extensions

ECH configuration extensions are used to provide room for additionalfunctionality as needed. SeeSection 12 for guidance onwhich types of extensions are appropriate for this structure.¶

The format is as defined in[RFC8446],Section 4.2.The same interpretation rules apply: extensions MAY appear in any order, butthere MUST NOT be more than one extension of the same type in the extensionsblock. An extension can be tagged as mandatory by using an extension typecodepoint with the high order bit set to 1.¶

Clients MUST parse the extension list and check for unsupported mandatoryextensions. If an unsupported mandatory extension is present, clients MUSTignore theECHConfig.¶

5.1.Encoding the ClientHelloInner

Before encrypting, the client pads and optionally compresses ClientHelloInnerinto a EncodedClientHelloInner structure, defined below:¶

    struct {        ClientHello client_hello;        uint8 zeros[length_of_padding];    } EncodedClientHelloInner;

Theclient_hello field is computed by first making a copy of ClientHelloInnerand setting thelegacy_session_id field to the empty string. Note this fielduses the ClientHello structure, defined inSection 4.1.2 of [RFC8446] whichdoes not include the Handshake structure's four byte header. Thezeros fieldMUST be all zeroes.¶

Repeating large extensions, such as "key_share" with post-quantum algorithms,between ClientHelloInner and ClientHelloOuter can lead to excessive size. Toreduce the size impact, the client MAY substitute extensions which it knowswill be duplicated in ClientHelloOuter. It does so by removing and replacingextensions from EncodedClientHelloInner with a single "ech_outer_extensions"extension, defined as follows:¶

    enum {       ech_outer_extensions(0xfd00), (65535)    } ExtensionType;    ExtensionType OuterExtensions<2..254>;

OuterExtensions contains the removed ExtensionType values. Each value referencesthe matching extension in ClientHelloOuter. The values MUST be orderedcontiguously in ClientHelloInner, and the "ech_outer_extensions" extension MUSTbe inserted in the corresponding position in EncodedClientHelloInner.Additionally, the extensions MUST appear in ClientHelloOuter in the samerelative order. However, there is no requirement that they be contiguous. Forexample, OuterExtensions may contain extensions A, B, C, while ClientHelloOutercontains extensions A, D, B, C, E, F.¶

The "ech_outer_extensions" extension can only be included inEncodedClientHelloInner, and MUST NOT appear in either ClientHelloOuter orClientHelloInner.¶

Finally, the client pads the message by setting thezeros field to a bytestring whose contents are all zeros and whose length is the amount of paddingto add.Section 6.1.3 describes a recommended padding scheme.¶

The client-facing server computes ClientHelloInner by reversing this process.First it parses EncodedClientHelloInner, interpreting all bytes afterclient_hello as padding. If any padding byte is non-zero, the server MUSTabort the connection with an "illegal_parameter" alert.¶

Next it makes a copy of theclient_hello field and copies thelegacy_session_id field from ClientHelloOuter. It then looks for an"ech_outer_extensions" extension. If found, it replaces the extension with thecorresponding sequence of extensions in the ClientHelloOuter. The server MUSTabort the connection with an "illegal_parameter" alert if any of the followingare 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 OuterExtensionsdo not occur in the same order.¶

These requirements prevent an attacker from performing a packet amplificationattack, by crafting a ClientHelloOuter which decompresses to a much largerClientHelloInner. This is discussed further inSection 10.11.4.¶

Implementations SHOULD bound the time to compute a ClientHelloInnerproportionally to the ClientHelloOuter size. If the cost is disproportionatelylarge, a malicious client could exploit this in a denial of service attack.Appendix B describes a linear-time procedure that may be usedfor this purpose.¶

5.2.Authenticating the ClientHelloOuter

To prevent a network attacker from modifying the reconstructed ClientHelloInner(seeSection 10.11.3), ECH authenticates ClientHelloOuter bypassing ClientHelloOuterAAD as the associated data for HPKE sealing and openingoperations. The ClientHelloOuterAAD is a serialized ClientHello structure,defined inSection 4.1.2 of [RFC8446], which matches the ClientHelloOuterexcept thepayload field of the "encrypted_client_hello" is replaced with abyte string of the same length but whose contents are zeros. This value doesnot include the four-byte header from the Handshake structure.¶

The client follows the procedure inSection 6.1.1 to firstconstruct ClientHelloOuterAAD with a placeholderpayload field, then replacethe field with the encrypted value to compute ClientHelloOuter.¶

The server then receives ClientHelloOuter and computes ClientHelloOuterAAD bymaking a copy and replacing the portion corresponding to thepayload fieldwith zeros.¶

The payload and the placeholder strings have the same length, so it is notnecessary for either side to recompute length prefixes when applying the abovetransformations.¶

The decompression process inSection 5.1 forbids"encrypted_client_hello" in OuterExtensions. This ensures the unauthenticatedportion of ClientHelloOuter is not incorporated into ClientHelloInner.¶

6.1.Offering ECH

To offer ECH, the client first chooses a suitable ECHConfig from the server'sECHConfigList. To determine if a givenECHConfig is suitable, it checks thatit supports the KEM algorithm identified byECHConfig.contents.kem_id, atleast one KDF/AEAD algorithm identified byECHConfig.contents.cipher_suites,and the version of ECH indicated byECHConfig.contents.version. Once asuitable configuration is found, the client selects the cipher suite it willuse for encryption. It MUST NOT choose a cipher suite or version not advertisedby the configuration. If no compatible configuration is found, then the clientSHOULD proceed as described inSection 6.2.¶

Next, the client constructs the ClientHelloInner message just as it does astandard ClientHello, with the exception of the following rules:¶

1. It MUST NOT offer to negotiate TLS 1.2 or below. This is necessary to ensurethe backend server does not negotiate a TLS version that is incompatible withECH.¶
2. It MUST NOT offer to resume any session for TLS 1.2 and below.¶
3. If it intends to compress any extensions (seeSection 5.1), it MUSTorder those extensions consecutively.¶
4. It MUST include the "encrypted_client_hello" extension of typeinner asdescribed inSection 5. (This requirement is not applicablewhen the "encrypted_client_hello" extension is generated as described inSection 6.2.)¶

The client then constructs EncodedClientHelloInner as described inSection 5.1. It also computes an HPKE encryption context andenc valueas:¶

    pkR = DeserializePublicKey(ECHConfig.contents.public_key)    enc, context = SetupBaseS(pkR,                              "tls ech" || 0x00 || ECHConfig)

Next, it constructs a partial ClientHelloOuterAAD as it does a standardClientHello, with the exception of the following rules:¶

1. It MUST offer to negotiate TLS 1.3 or above.¶
2. If it compressed any extensions in EncodedClientHelloInner, it MUST copy thecorresponding extensions from ClientHelloInner. The copied extensionsadditionally MUST be in the same relative order as in ClientHelloInner.¶
3. It MUST copy the legacy_session_id field from ClientHelloInner. Thisallows the server to echo the correct session ID for TLS 1.3's compatibilitymode (see Appendix D.4 of[RFC8446]) when ECH is negotiated.¶
4. It MAY copy any other field from the ClientHelloInner exceptClientHelloInner.random. Instead, It MUST generate a freshClientHelloOuter.random using a secure random number generator. (SeeSection 10.11.1.)¶
5. The value ofECHConfig.contents.public_name MUST be placed in the"server_name" extension.¶
6. When the client offers the "pre_shared_key" extension in ClientHelloInner, itSHOULD also include a GREASE "pre_shared_key" extension in ClientHelloOuter,generated in the manner described inSection 6.1.2. The client MUST NOT usethis extension to advertise a PSK to the client-facing server. (SeeSection 10.11.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.¶
7. When the client offers the "early_data" extension in ClientHelloInner, itMUST also include the "early_data" extension in ClientHelloOuter. Thisallows servers that reject ECH and use ClientHelloOuter to safely ignore anyearly data sent by the client per[RFC8446],Section 4.2.10.¶

Note that these rules may change in the presence of an application profilespecifying otherwise.¶

The client might duplicate non-sensitive extensions in both messages. However,implementations need to take care to ensure that sensitive extensions are notoffered in the ClientHelloOuter. SeeSection 10.5 for additionalguidance.¶

Finally, the client encrypts the EncodedClientHelloInner with the above values,as described inSection 6.1.1, to construct a ClientHelloOuter. Itsends this to the server, and processes the response as described inSection 6.1.4.¶

    final_payload = context.Seal(ClientHelloOuterAAD,                                 EncodedClientHelloInner)

6.2.GREASE ECH

If the client attempts to connect to a server and does not have an ECHConfigstructure available for the server, it SHOULD send a GREASE[RFC8701]"encrypted_client_hello" extension in the first ClientHello as follows:¶

• Set theconfig_id field to a random byte.¶
• Set thecipher_suite field to a supported HpkeSymmetricCipherSuite. Theselection SHOULD vary to exercise all supported configurations, but MAY beheld constant for successive connections to the same server in the samesession.¶
• Set theenc field to a randomly-generated valid encapsulated public keyoutput by the HPKE KEM.¶
• Set thepayload field to a randomly-generated string of L+C bytes, where Cis the ciphertext expansion of the selected AEAD scheme and L is the size ofthe EncodedClientHelloInner the client would compute when offering ECH, paddedaccording toSection 6.1.3.¶

If sending a second ClientHello in response to a HelloRetryRequest, theclient copies the entire "encrypted_client_hello" extension from the firstClientHello. The identical value will reveal to an observer that the value of"encrypted_client_hello" was fake, but this only occurs if there is aHelloRetryRequest.¶

If the server sends an "encrypted_client_hello" extension in eitherHelloRetryRequest or EncryptedExtensions, the client MUST check the extensionsyntactically and abort the connection with a "decode_error" alert if it isinvalid. It otherwise ignores the extension. It MUST NOT save the "retry_config"value in EncryptedExtensions.¶

Offering a GREASE extension is not considered offering an encrypted ClientHellofor purposes of requirements inSection 6.1. In particular, the clientMAY offer to resume sessions established without ECH.¶

7.1.Client-Facing Server

Upon receiving an "encrypted_client_hello" extension in an initialClientHello, the client-facing server determines if it will accept ECH, priorto negotiating any other TLS parameters. Note that successfully decrypting theextension will result in a new ClientHello to process, so even the client's TLSversion preferences may have changed.¶

First, the server collects a set of candidate ECHConfig values. This list isdetermined by one of the two following methods:¶

1. Compare ECHClientHello.config_id against identifiers of each known ECHConfigand select the ones that match, if any, as candidates.¶
2. Collect all known ECHConfig values as candidates, with trial decryptionbelow determining the final selection.¶

Some uses of ECH, such as local discovery mode, may randomize theECHClientHello.config_id since it can be used as a tracking vector. In suchcases, the second method should be used for matching the ECHClientHello to aknown ECHConfig. SeeSection 10.4. Unless specified by the applicationprofile or otherwise externally configured, implementations MUST use the firstmethod.¶

The server then iterates over the candidate ECHConfig values, attempting todecrypt the "encrypted_client_hello" extension:¶

The server verifies that the ECHConfig supports the cipher suite indicated bythe ECHClientHello.cipher_suite and that the version of ECH indicated by theclient matches the ECHConfig.version. If not, the server continues to the nextcandidate ECHConfig.¶

Next, the server decrypts ECHClientHello.payload, using the private key skRcorresponding 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 inSection 5.2. Theinfo parameter to SetupBaseR is theconcatenation "tls ech", a zero byte, and the serialized ECHConfig. Ifdecryption fails, the server continues to the next candidate ECHConfig.Otherwise, the server reconstructs ClientHelloInner fromEncodedClientHelloInner, as described inSection 5.1. It then stopsiterating over the candidate ECHConfig values.¶

Upon determining the ClientHelloInner, the client-facing server checks that themessage includes a well-formed "encrypted_client_hello" extension of typeinner and that it does not offer TLS 1.2 or below. If either of these checksfails, the client-facing server MUST abort with an "illegal_parameter" alert.¶

If these checks succeed, the client-facing server then forwards theClientHelloInner to the appropriate backend server, which proceeds as inSection 7.2. If the backend server responds with a HelloRetryRequest, theclient-facing server forwards it, decrypts the client's second ClientHelloOuterusing the procedure inSection 7.1.1, and forwards the resultingsecond ClientHelloInner. The client-facing server forwards all other TLSmessages between the client and backend server unmodified.¶

Otherwise, if all candidate ECHConfig values fail to decrypt the extension, theclient-facing server MUST ignore the extension and proceed with the connectionusing 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; seeSection 10.9.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-datekeys. 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 (seeSection 6.2), so it is necessary for servers to proceed with the connectionand rely on the client to abort if ECH was required. In particular, theunrecognized value alone does not indicate a misconfigured ECH advertisement(Section 8.1). Instead, servers can measure occurrences of the"ech_required" alert to detect this case.¶

    EncodedClientHelloInner = context.Open(ClientHelloOuterAAD,                                         ECHClientHello.payload)

7.2.Backend Server

Upon receipt of an "encrypted_client_hello" extension of typeinner in aClientHello, if the backend server negotiates TLS 1.3 or higher, then it MUSTconfirm ECH acceptance to the client by computing its ServerHello as describedhere.¶

The backend server embeds in ServerHello.random a string derived from the innerhandshake. It begins by computing its ServerHello as usual, except the last 8bytes of ServerHello.random are set to zero. It then computes the transcripthash for ClientHelloInner up to and including the modified ServerHello, asdescribed in[RFC8446],Section 4.4.1. Let transcript_ech_conf denote theoutput. Finally, the backend server overwrites the last 8 bytes of theServerHello.random with the following string:¶

   accept_confirmation = HKDF-Expand-Label(      HKDF-Extract(0, ClientHelloInner.random),      "ech accept confirmation",      transcript_ech_conf,      8)

where HKDF-Expand-Label is defined in[RFC8446],Section 7.1, "0" indicates astring of Hash.length bytes set to zero, and Hash is the hash function used tocompute the transcript hash.¶

The backend server MUST NOT perform this operation if it negotiated TLS 1.2 orbelow. Note that doing so would overwrite the downgrade signal for TLS 1.3 (see[RFC8446],Section 4.1.3).¶

   hrr_accept_confirmation = HKDF-Expand-Label(      HKDF-Extract(0, ClientHelloInner1.random),      "hrr ech accept confirmation",      transcript_hrr_ech_conf,      8)

8.1.Misconfiguration and Deployment Concerns

It is possible for ECH advertisements and servers to become inconsistent. Thismay occur, for instance, from DNS misconfiguration, caching issues, or anincomplete rollout in a multi-server deployment. This may also occur if a serverloses its ECH keys, or if a deployment of ECH must be rolled back on the server.¶

The retry mechanism repairs inconsistencies, provided the server isauthoritative for the public name. If server and advertised keys mismatch, theserver will reject ECH and respond with "retry_configs". If the server doesnot understandthe "encrypted_client_hello" extension at all, it will ignore it as required bySection 4.1.2 of [RFC8446]. Provided the server can present a certificatevalid for the public name, the client can safely retry with updated settings,as described inSection 6.1.6.¶

Unless ECH is disabled as a result of successfully establishing a connection tothe public name, the client MUST NOT fall back to using unencryptedClientHellos, as this allows a network attacker to disclose the contents of thisClientHello, including the SNI. It MAY attempt to use another server from theDNS results, if one is provided.¶

8.2.Middleboxes

When connecting through a TLS-terminating proxy that does not support thisextension,[RFC8446],Section 9.3 requires the proxy still act as aconforming TLS client and server. The proxy must ignore unknown parameters, andgenerate its own ClientHello containing only parameters it understands. Thus,when presenting a certificate to the client or sending a ClientHello to theserver, the proxy will act as if connecting to the public name, without echoingthe "encrypted_client_hello" extension.¶

Depending on whether the client is configured to accept the proxy's certificateas authoritative for the public name, this may trigger the retry logic describedinSection 6.1.6 or result in a connection failure. A proxy which is notauthoritative for the public name cannot forge a signal to disable ECH.¶

10.1.Security and Privacy Goals

ECH considers two types of attackers: passive and active. Passive attackers canread packets from the network, but they cannot perform any sort of activebehavior such as probing servers or querying DNS. A middlebox that filters basedon plaintext packet contents is one example of a passive attacker. In contrast,active attackers can also write packets into the network for malicious purposes,such as interfering with existing connections, probing servers, and queryingDNS. In short, an active attacker corresponds to the conventional threat modelfor TLS 1.3[RFC8446].¶

Given these types of attackers, the primary goals of ECH are as follows.¶

1. Security preservation. Use of ECH does not weaken the security properties ofTLS without ECH.¶
2. Handshake privacy. TLS connection establishment to a host with a specificECHConfig and TLS configuration is indistinguishable from a connection toany other host with the same ECHConfig and TLS configuration. (The set ofhosts which share the same ECHConfig and TLS configuration is referred toas the anonymity set.)¶
3. Downgrade resistance. An attacker cannot downgrade a connection thatattempts to use ECH to one that does not use ECH.¶

These properties were formally proven in[ECH-Analysis].¶

With regards to handshake privacy, client-facing server configurationdetermines the size of the anonymity set. For example, if a client-facingserver uses distinct ECHConfig values for each host, then each anonymity sethas size k = 1. Client-facing servers SHOULD deploy ECH in such a way so as tomaximize the size of the anonymity set where possible. This means client-facingservers should use the same ECHConfig for as many hosts as possible. Anattacker can distinguish two hosts that have different ECHConfig values basedon the ECHClientHello.config_id value. This also means public information in aTLS handshake should be consistent across hosts. For example, if aclient-facing server services many backend origin hosts, only one of whichsupports some cipher suite, it may be possible to identify that host based onthe contents of unencrypted handshake messages.¶

Beyond these primary security and privacy goals, ECH also aims to hide, to someextent, the fact that it is being used at all. Specifically, the GREASE ECHextension described inSection 6.2 does not change the security properties ofthe TLS handshake at all. Its goal is to provide "cover" for the real ECHprotocol (Section 6.1), as a means of addressing the "do not stick out"requirements of[RFC8744]. SeeSection 10.9.4 for details.¶

10.2.Unauthenticated and Plaintext DNS

In comparison to[I-D.kazuho-protected-sni], wherein DNS Resource Records aresigned via a server private key, ECH records have no authenticity or provenanceinformation. This means that any attacker which can inject DNS responses orpoison DNS caches, which is a common scenario in client access networks, cansupply clients with fake ECH records (so that the client encrypts data to them)or strip the ECH record from the response. However, in the face of an attackerthat controls DNS, no encryption scheme can work because the attacker canreplace the IP address, thus blocking client connections, or substitute aunique IP address which is 1:1 with the DNS name that was looked up (modulo DNSwildcards). Thus, allowing the ECH records in the clear does not make thesituation significantly worse.¶

Clearly, DNSSEC (if the client validates and hard fails) is a defense againstthis form of attack, but DoH/DPRIVE are also defenses against DNS attacks byattackers on the local network, which is a common case where ClientHello and SNIencryption are desired. Moreover, as noted in the introduction, SNI encryptionis less useful without encryption of DNS queries in transit via DoH or DPRIVEmechanisms.¶

10.3.Client Tracking

A malicious client-facing server could distribute unique, per-client ECHConfigstructures as a way of tracking clients across subsequent connections. On-pathadversaries which know about these unique keys could also track clients in thisway by observing TLS connection attempts.¶

The cost of this type of attack scales linearly with the desired number oftarget clients. Moreover, DNS caching behavior makes targeting individual usersfor extended periods of time, e.g., using per-client ECHConfig structuresdelivered via HTTPS RRs with high TTLs, challenging. Clients can help mitigatethis problem by flushing any DNS or ECHConfig state upon changing networks.¶

10.4.Ignored Configuration Identifiers and Trial Decryption

Ignoring configuration identifiers may be useful in scenarios where clients andclient-facing servers do not want to reveal information about the client-facingserver in the "encrypted_client_hello" extension. In such settings, clients senda randomly generated config_id in the ECHClientHello. Servers in these settingsmust perform trial decryption since they cannot identify the client's chosen ECHkey using the config_id value. As a result, ignoring configurationidentifiers may exacerbate DoS attacks. Specifically, an adversary may sendmalicious ClientHello messages, i.e., those which will not decrypt with anyknown ECH key, in order to force wasteful decryption. Servers that support thisfeature should, for example, implement some form of rate limiting mechanism tolimit the potential damage caused by such attacks.¶

Unless specified by the application using (D)TLS or externally configured,implementations MUST NOT use this mode.¶

10.5.Outer ClientHello

Any information that the client includes in the ClientHelloOuter is visible topassive observers. The client SHOULD NOT send values in the ClientHelloOuterwhich would reveal a sensitive ClientHelloInner property, such as the trueserver name. It MAY send values associated with the public name in theClientHelloOuter.¶

In particular, some extensions require the client send a server-name-specificvalue in the ClientHello. These values may reveal information about thetrue 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 theClientHelloOuter. It MAY send such values in the ClientHelloInner.¶

A client may also use different preferences in different contexts. For example,it may send a different ALPN lists to different servers or in differentapplication contexts. A client that treats this context as sensitive SHOULD NOTsend context-specific values in ClientHelloOuter.¶

Values which are independent of the true server name, or other information theclient wishes to protect, MAY be included in ClientHelloOuter. If they matchthe corresponding ClientHelloInner, they MAY be compressed as described inSection 5.1. However, note the payload length reveals information aboutwhich extensions are compressed, so inner extensions which only sometimes matchthe corresponding outer extension SHOULD NOT be compressed.¶

Clients MAY include additional extensions in ClientHelloOuter to avoidsignaling unusual behavior to passive observers, provided the choice of valueand value itself are not sensitive. SeeSection 10.9.4.¶

10.6.Related Privacy Leaks

ECH requires encrypted DNS to be an effective privacy protection mechanism.However, verifying the server's identity from the Certificate message,particularly when using the X509 CertificateType, may result in additionalnetwork traffic that may reveal the server identity. Examples of this trafficmay include requests for revocation information, such as OCSP or CRL traffic, orrequests for repository information, such as authorityInformationAccess. It mayalso include implementation-specific traffic for additional information sourcesas part of verification.¶

Implementations SHOULD avoid leaking information that may identify the server.Even when sent over an encrypted transport, such requests may result in indirectexposure of the server's identity, such as indicating a specific CA or servicebeing used. To mitigate this risk, servers SHOULD deliver such informationin-band when possible, such as through the use of OCSP stapling, and clientsSHOULD take steps to minimize or protect such requests during certificatevalidation.¶

Attacks that rely on non-ECH traffic to infer server identity in an ECHconnection are out of scope for this document. For example, a client thatconnects to a particular host prior to ECH deployment may later resume aconnection to that same host after ECH deployment. An adversary that observesthis can deduce that the ECH-enabled connection was made to a host that theclient previously connected to and which is within the same anonymity set.¶

10.7.Cookies

Section 4.2.2 of [RFC8446] defines a cookie value that servers may send inHelloRetryRequest for clients to echo in the second ClientHello. While ECHencrypts the cookie in the second ClientHelloInner, the backend server'sHelloRetryRequest is unencrypted.This means differences in cookies betweenbackend servers, such as lengths or cleartext components, may leak informationabout the server identity.¶

Backend servers in an anonymity set SHOULD NOT reveal information in the cookiewhich identifies the server. This may be done by handling HelloRetryRequeststatefully, thus not sending cookies, or by using the same cookie constructionfor all backend servers.¶

Note that, if the cookie includes a key name, analogous to Section 4 of[RFC5077], this may leak information if different backend servers issuecookies with different key names at the time of the connection. In particular,if the deployment operates in Split Mode, the backend servers may not sharecookie encryption keys. Backend servers may mitigate this by either handlingkey rotation with trial decryption, or coordinating to match key names.¶

10.8.Attacks Exploiting Acceptance Confirmation

To signal acceptance, the backend server overwrites 8 bytes of itsServerHello.random with a value derived from the ClientHelloInner.random. (SeeSection 7.2 for details.) This behavior increases the likelihood of theServerHello.random colliding with the ServerHello.random of a previous session,potentially reducing the overall security of the protocol. However, theremaining 24 bytes provide enough entropy to ensure this is not a practicalavenue of attack.¶

On the other hand, the probability that two 8-byte strings are the same isnon-negligible. This poses a modest operational risk. Suppose the client-facingserver terminates the connection (i.e., ECH is rejected or bypassed): if thelast 8 bytes of its ServerHello.random coincide with the confirmation signal,then the client will incorrectly presume acceptance and proceed as if thebackend server terminated the connection. However, the probability of a falsepositive occurring for a given connection is only 1 in 2^64. This value issmaller than the probability of network connection failures in practice.¶

Note that the same bytes of the ServerHello.random are used to implementdowngrade protection for TLS 1.3 (see[RFC8446],Section 4.1.3). Thesemechanisms do not interfere because the backend server only signals ECHacceptance in TLS 1.3 or higher.¶

10.9.Comparison Against Criteria

[RFC8744] lists several requirements for SNI encryption.In this section, we re-iterate these requirements and assess the ECH designagainst them.¶

10.10.Padding Policy

Variations in the length of the ClientHelloInner ciphertext could leakinformation about the corresponding plaintext.Section 6.1.3 describes aRECOMMENDED padding mechanism for clients aimed at reducing potentialinformation leakage.¶

10.11.Active Attack Mitigations

This section describes the rationale for ECH properties and mechanics asdefenses against active attacks. In all the attacks below, the attacker ison-path between the target client and server. The goal of the attacker is tolearn private information about the inner ClientHello, such as the true SNIvalue.¶

 Client                         Attacker               Server   ClientHello   + key_share   + ech         ------>      (intercept)     -----> X (drop)                             ServerHello                             + key_share                   {EncryptedExtensions}                   {CertificateRequest*}                          {Certificate*}                    {CertificateVerify*}                 <------   Alert                 ------>

 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)

      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                                          <--------

11.1.Update of the TLS ExtensionType Registry

IANA is requested to create the following entries in the existing registry forExtensionType (defined in[RFC8446]):¶

1. encrypted_client_hello(0xfe0d), with "TLS 1.3" column values set to"CH, HRR, EE", and "Recommended" column set to "Yes".¶
2. ech_outer_extensions(0xfd00), with the "TLS 1.3" column values set to "",and "Recommended" column set to "Yes".¶

11.2.Update of the TLS Alert Registry

IANA is requested to create an entry, ech_required(121) in the existing registryfor Alerts (defined in[RFC8446]), with the "DTLS-OK" column set to"Y".¶

A.1.TLS-layer

A.2.Application-layer

D.1.Since draft-ietf-tls-esni-15

• Add CCS2022 reference and summary (#539)¶

D.2.Since draft-ietf-tls-esni-14

• Keep-alive¶

D.3.Since draft-ietf-tls-esni-13

• Editorial improvements¶

D.4.Since draft-ietf-tls-esni-12

• Abort on duplicate OuterExtensions (#514)¶
• Improve EncodedClientHelloInner definition (#503)¶
• Clarify retry configuration usage (#498)¶
• Expand on config_id generation implications (#491)¶
• Server-side acceptance signal extension GREASE (#481)¶
• Refactor overview, client implementation, and middleboxsections (#480, #478, #475, #508)¶
• Editorial iprovements (#485, #488, #490, #495, #496, #499, #500,#501, #504, #505, #507, #510, #511)¶

D.5.Since draft-ietf-tls-esni-11

• Move ClientHello padding to the encoding (#443)¶
• Align codepoints (#464)¶
• Relax OuterExtensions checks for alignment with RFC8446 (#467)¶
• Clarify HRR acceptance and rejection logic (#470)¶
• Editorial improvements (#468, #465, #462, #461)¶

D.6.Since draft-ietf-tls-esni-10

• Make HRR confirmation and ECH acceptance explicit (#422, #423)¶
• Relax computation of the acceptance signal (#420, #449)¶
• Simplify ClientHelloOuterAAD generation (#438, #442)¶
• Allow empty enc in ECHClientHello (#444)¶
• Authenticate ECHClientHello extensions position in ClientHelloOuterAAD (#410)¶
• Allow clients to send a dummy PSK and early_data in ClientHelloOuter whenapplicable (#414, #415)¶
• Compress ECHConfigContents (#409)¶
• Validate ECHConfig.contents.public_name (#413, #456)¶
• Validate ClientHelloInner contents (#411)¶
• Note split-mode challenges for HRR (#418)¶
• Editorial improvements (#428, #432, #439, #445, #458, #455)¶

D.7.Since draft-ietf-tls-esni-09

• Finalize HPKE dependency (#390)¶
• Move from client-computed to server-chosen, one-byte configidentifier (#376, #381)¶
• Rename ECHConfigs to ECHConfigList (#391)¶
• Clarify some security and privacy properties (#385, #383)¶