TLS Encrypted Client Hello

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

In the remainder of this document, we will refer to the ECH-service provider as the "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-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.¶

3.2. Encrypted ClientHello (ECH)

A client-facing server enables ECH by publishing an ECH configuration, which is an encryption public key and associated metadata. The server must publish this for all the domains it serves via Shared or Split Mode. This document defines the ECH configuration's format, but delegates DNS publication details to [RFC9460]. See [ECH-IN-DNS] for specifics about how ECH configurations are advertised in HTTPS records. Other delivery mechanisms are also possible. For example, the client may have the ECH configuration preconfigured.¶

When a client wants to establish a TLS session with some backend server, it constructs a private ClientHello, referred to as the ClientHelloInner. The client then constructs a public ClientHello, referred to as the ClientHelloOuter. The ClientHelloOuter contains innocuous values for sensitive 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 completes the handshake with ClientHelloOuter. This is referred to as rejecting ECH.¶

2. If it successfully decrypts the extension, it forwards the ClientHelloInner to the backend server, which completes the handshake. This is referred to as accepting ECH.¶

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

The primary goal of ECH is to ensure that connections to servers in the same anonymity set are indistinguishable from one another. Moreover, it should achieve this goal without affecting any existing security properties of TLS 1.3. See Section 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 corresponding private keys. This set SHOULD contain the currently published values, as well as previous values that may still be in use, since clients may cache DNS records up to a TTL or longer.¶

Section 7.1 describes a trial decryption process for decrypting the ClientHello. This can impact performance when the client-facing server maintains many known ECHConfig values. To avoid this, the client-facing server SHOULD allocate distinct config_id values for each ECHConfig in its known set. The RECOMMENDED strategy is via rejection sampling, i.e., to randomly select config_id repeatedly until it does not match any known ECHConfig.¶

It is not necessary for config_id values across different client-facing servers to be distinct. A backend server may be hosted behind two different client-facing servers with colliding config_id values without any performance impact. Values may also be reused if the previous ECHConfig is no longer in the known set.¶

4.2. Configuration Extensions

ECH configuration extensions are used to provide room for additional functionality as needed. See Appendix A for guidance on which types of extensions are appropriate for this structure.¶

The format is as 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 using an extension type codepoint with the high order bit set 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.¶

5.1. Encoding the ClientHelloInner

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

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

The client_hello field is computed by first making a copy of ClientHelloInner and setting the legacy_session_id field to the empty string. Note this field uses the ClientHello structure, defined in Section 4.1.2 of [RFC8446] which does not include the Handshake structure's four byte header. The zeros field MUST be all zeroes.¶

Repeating large extensions, such as "key_share" with post-quantum algorithms, between ClientHelloInner and ClientHelloOuter can lead to excessive size. To reduce the size impact, the client MAY substitute extensions which it knows will be duplicated in ClientHelloOuter. It does so by removing and replacing extensions 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 references 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. Additionally, the extensions MUST appear in ClientHelloOuter in the same relative order. However, there is no requirement that they be contiguous. For example, OuterExtensions may contain extensions A, B, C, while ClientHelloOuter contains extensions A, D, B, C, E, 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 whose contents are all zeros and whose length is the amount of padding to 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 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. It then looks for an "ech_outer_extensions" extension. If found, it replaces the extension with the corresponding sequence of extensions in the 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 requirements prevent an attacker from performing a packet amplification attack, by crafting a ClientHelloOuter which decompresses to a much larger ClientHelloInner. This is discussed further in Section 10.12.4.¶

Implementations SHOULD construct the ClientHelloInner in linear time. Quadratic time implementations (such as may happen via naive copying) create a denial of service risk. Appendix B describes a linear-time procedure that may be used for this purpose.¶

5.2. Authenticating the ClientHelloOuter

To prevent a network attacker from modifying 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. The ClientHelloOuterAAD is a serialized ClientHello structure, defined in Section 4.1.2 of [RFC8446], which matches the ClientHelloOuter except that the payload field of the "encrypted_client_hello" is replaced with a byte string of the same length but whose contents are zeros. This value does not include the four-byte header from the Handshake structure.¶

6.1. Offering ECH

To offer ECH, the client first chooses a suitable ECHConfig from the server's ECHConfigList. To determine if a given ECHConfig is suitable, it checks that it supports the KEM algorithm identified by ECHConfig.contents.kem_id, at least one KDF/AEAD algorithm identified by ECHConfig.contents.cipher_suites, and the version of ECH indicated by ECHConfig.contents.version. Once a suitable configuration is found, the client selects the cipher suite it will use for encryption. It MUST NOT choose a cipher suite or version not advertised by the configuration. If no compatible configuration is found, then the client SHOULD proceed as described in Section 6.2.¶

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

1. It MUST NOT offer to negotiate TLS 1.2 or below. This is necessary to ensure the backend server does not negotiate a TLS version that is incompatible with ECH.¶

2. It MUST NOT offer to resume any session for TLS 1.2 and below.¶

3. If it intends to compress any extensions (see Section 5.1), it MUST order those extensions consecutively.¶

4. 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.)¶

The client then constructs EncodedClientHelloInner as described in Section 5.1. It also computes an HPKE encryption context and enc value as:¶

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

Next, it constructs a partial ClientHelloOuterAAD as it does a standard ClientHello, 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 the corresponding extensions from ClientHelloInner. The copied extensions additionally MUST be in the same relative order as in ClientHelloInner.¶

3. It MUST copy the legacy_session_id field 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.¶

4. It MAY copy any other field from the ClientHelloInner except ClientHelloInner.random. Instead, It MUST generate a fresh ClientHelloOuter.random using a secure random number generator. (See Section 10.12.1.)¶

5. It SHOULD place the value of ECHConfig.contents.public_name in 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.¶

6. 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.¶

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

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

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

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

    final_payload = context.Seal(ClientHelloOuterAAD,
                                 EncodedClientHelloInner)

6.2. GREASE ECH

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

• Set the config_id field to a random byte.¶

• Set the cipher_suite field to a supported HpkeSymmetricCipherSuite. The selection SHOULD vary to exercise all supported configurations, but MAY be held constant for successive connections to the same server in the same session.¶

• 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 sending a second ClientHello in response to a HelloRetryRequest, the client 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 occurs 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. It otherwise 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 purposes of requirements in Section 6.1. In particular, the client MAY offer to resume sessions established without ECH.¶

7.1. Client-Facing Server

Upon receiving an "encrypted_client_hello" extension in an initial ClientHello, the client-facing server determines if it will accept ECH, prior to negotiating any other TLS parameters. Note that successfully decrypting the extension will result 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:¶

1. Compare ECHClientHello.config_id against identifiers of each known ECHConfig and select the ones that match, if any, as candidates.¶

2. 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 "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. It 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 allows the server to 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 then 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.¶

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

7.2. Backend Server

Upon receipt of an "encrypted_client_hello" extension of type inner in a ClientHello, if the backend server negotiates TLS 1.3 or higher, then it MUST confirm ECH acceptance to the client by computing its ServerHello as described here.¶

The backend server embeds in ServerHello.random a string derived from the inner handshake. It begins by computing its ServerHello as usual, except the last 8 bytes of ServerHello.random are set to zero. It then 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 the ServerHello.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 a string of Hash.length bytes set to zero, and Hash is the hash function used to compute the transcript hash.¶

The backend server MUST NOT perform this operation if it negotiated TLS 1.2 or below. 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. Compatibility Issues

Unlike most TLS extensions, placing the SNI value in an ECH extension is not interoperable with existing servers, which expect the value in the existing plaintext extension. Thus server operators SHOULD ensure servers understand a given set of ECH keys before advertising them. Additionally, servers SHOULD retain support for any previously-advertised keys for the duration of their validity.¶

However, in more complex deployment scenarios, this may be difficult to fully guarantee. Thus this protocol was designed to be robust in case of inconsistencies between systems that advertise ECH keys and servers, at the cost of extra round-trips due to a retry. Two specific scenarios are detailed below.¶

8.2. Deployment Impact

Some use cases which depend on information ECH encrypts may break with the deployment of ECH. The extent of breakage depends on a number of external factors, including, for example, whether ECH can be disabled, whether or not the party disabling ECH is trusted to do so, and whether or not client implementations will fall back to TLS without ECH in the event of disablement.¶

Depending on implementation details and deployment settings, use cases which depend on plaintext TLS information may require fundamentally different approaches to continue working. For example, in managed enterprise settings, one approach may be to disable ECH entirely via group policy and for client implementations to honor this action.¶

In the context of Section 6.1.6, another approach may be to intercept and decrypt client TLS connections. The feasibility of alternative solutions is specific to individual deployments.¶

10.1. Security and Privacy Goals

ECH considers two types of attackers: passive and active. Passive attackers can read packets from the network, but they cannot perform any sort of active behavior such as probing servers or querying DNS. A middlebox that filters based on 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 querying DNS. In short, an active attacker corresponds to the conventional threat model for TLS 1.3 [RFC8446].¶

Passive and active attackers can exist anywhere in the network, including between the client and client-facing server, as well as between the client-facing and backend servers when running ECH in Split Mode. However, for Split Mode in particular, ECH makes two additional assumptions:¶

1. The channel between each client-facing and each backend server is authenticated such that the backend server only accepts messages from trusted client-facing servers. The exact mechanism for establishing this authenticated channel is out of scope for this document.¶

2. The attacker cannot correlate messages between client and client-facing server with messages between client-facing and backend server. Such correlation could allow an attacker to link information unique to a backend server, such as their server name or IP address, with a client's encrypted ClientHelloInner. Correlation could occur through timing analysis of messages across the client-facing server, or via examining the contents of messages sent between client-facing and backend servers. The exact mechanism for preventing this sort of correlation is out of scope for this document.¶

Given this threat model, the primary goals of ECH are as follows.¶

1. Security preservation. Use of ECH does not weaken the security properties of TLS without ECH.¶

2. Handshake privacy. TLS connection establishment to a host within an anonymity set is indistinguishable from a connection to any other host within the anonymity set. (The anonymity set is defined in Section 1.)¶

3. Downgrade resistance. An attacker cannot downgrade a connection that attempts 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 configuration determines the size of the anonymity set. For example, if a client-facing server uses distinct ECHConfig values for each host, then each anonymity set has size k = 1. Client-facing servers SHOULD deploy ECH in such a way so as to maximize the size of the anonymity set where possible. This means client-facing servers should use the same ECHConfig for as many hosts as possible. An attacker can distinguish two hosts that have different ECHConfig values based on the ECHClientHello.config_id value. This also means public information in a TLS handshake should be consistent across hosts. For example, if a client-facing server services many backend origin hosts, only one of which supports some cipher suite, it may be possible to identify that host based on the contents of unencrypted handshake message. Similarly, if a backend origin reuses KeyShare values, then that provides a unique identifier for that server.¶

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

10.2. Unauthenticated and Plaintext DNS

In comparison to [I-D.kazuho-protected-sni], wherein DNS Resource Records are signed via a server private key, ECH records have no authenticity or provenance information. This means that any attacker which can inject DNS responses or poison DNS caches, which is a common scenario in client access networks, can supply 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 attacker that controls DNS, no encryption scheme can work because the attacker can replace the IP address, thus blocking client connections, or substitute a unique IP address which is 1:1 with the DNS name that was looked up (modulo DNS wildcards). Thus, allowing the ECH records in the clear does not make the situation significantly worse.¶

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

10.3. Client Tracking

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

The cost of this type of attack scales linearly with the desired number of target clients. Moreover, DNS caching behavior makes targeting individual users for extended periods of time, e.g., using per-client ECHConfig structures delivered via HTTPS RRs with high TTLs, challenging. Clients can help mitigate this 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 and client-facing servers do not want to reveal information about the client-facing server in the "encrypted_client_hello" extension. In such settings, clients send a randomly generated config_id in the ECHClientHello. Servers in these settings must perform trial decryption since they cannot identify the client's chosen ECH key using the config_id value. As a result, ignoring configuration identifiers may exacerbate DoS attacks. Specifically, an adversary may send malicious ClientHello messages, i.e., those which will not decrypt with any known ECH key, in order to force wasteful decryption. Servers that support this feature should, for example, implement some form of rate limiting mechanism to limit 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 to passive observers. The client SHOULD NOT send values in the ClientHelloOuter which would reveal a sensitive ClientHelloInner property, such as the true server name. It MAY send values associated with the public name in the ClientHelloOuter.¶

In particular, some extensions require the client send a server-name-specific value in the ClientHello. These values may reveal information 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. 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 different application contexts. A client that treats this context as sensitive SHOULD NOT send context-specific values in ClientHelloOuter.¶

Values which are independent of the true server name, or other information the client wishes to protect, MAY be included in ClientHelloOuter. If they match the corresponding ClientHelloInner, they MAY be compressed as described in Section 5.1. However, note that the payload length reveals information about which extensions are compressed, so inner extensions which 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, provided the choice of value and value itself are not sensitive. See Section 10.10.4.¶

10.6. Inner ClientHello

Values which depend on the contents of ClientHelloInner, such as the true server name, can influence how client-facing servers process this message. In particular, timing side channels can reveal information about the contents of ClientHelloInner. Implementations should take such side channels into consideration when reasoning about the privacy properties that ECH provides.¶

10.7. 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 additional network traffic that may reveal the server identity. Examples of this traffic may include requests for revocation information, such as OCSP or CRL traffic, or requests for repository information, such as authorityInformationAccess. It may also include implementation-specific traffic for additional information sources as 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 indirect exposure of the server's identity, such as indicating a specific CA or service being used. To mitigate this risk, servers SHOULD deliver such information in-band when possible, such as through the use of OCSP stapling, and clients SHOULD take steps to minimize or protect such requests during certificate validation.¶

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

10.8. Cookies

Section 4.2.2 of [RFC8446] defines a cookie value that servers may send in HelloRetryRequest for clients to echo in the second ClientHello. While ECH encrypts the cookie in the second ClientHelloInner, the backend server's HelloRetryRequest is unencrypted.This means differences in cookies between backend servers, such as lengths or cleartext components, may leak information about the server identity.¶

Backend servers in an anonymity set SHOULD NOT reveal information in the cookie which identifies the server. This may be done by handling HelloRetryRequest statefully, thus not sending cookies, or by using the same cookie construction for 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 issue cookies with different key names at the time of the connection. In particular, if the deployment operates in Split Mode, the backend servers may not share cookie encryption keys. Backend servers may mitigate this by either handling key rotation with trial decryption, or coordinating to match key names.¶

10.9. Attacks Exploiting Acceptance Confirmation

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 behavior increases the likelihood of the ServerHello.random colliding with the ServerHello.random of a previous session, potentially reducing the overall security of the protocol. However, the remaining 24 bytes provide enough entropy to ensure this is not a practical avenue of attack.¶

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

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

10.10. Comparison Against Criteria

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

10.11. Padding Policy

Variations in the length of the ClientHelloInner ciphertext could leak information about the corresponding plaintext. Section 6.1.3 describes a RECOMMENDED padding mechanism for clients aimed at reducing potential information leakage.¶

10.12. Active Attack Mitigations

This section describes the rationale for ECH properties and mechanics as defenses against active attacks. In all the attacks below, the attacker is on-path between the target client and server. The goal of the attacker is to learn private information about the inner ClientHello, such as the true SNI value.¶

 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 for ExtensionType (defined in [RFC8446]):¶

1. encrypted_client_hello(0xfe0d), with "TLS 1.3" column values set to "CH, HRR, EE", "DTLS-Only" column set to "N", and "Recommended" column set to "Yes".¶

2. ech_outer_extensions(0xfd00), with the "TLS 1.3" column values set to "CH", "DTLS-Only" column set to "N", "Recommended" column set to "Yes", and the "Comment" column set to "Only appears in inner CH."¶

11.2. Update of the TLS Alert Registry

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

11.3. ECH Configuration Extension Registry

IANA is requested to create a new "ECHConfig Extension" registry in a new "TLS Encrypted Client Hello (ECH) Configuration Extensions" page. New registrations need to 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 if the extension is TLS WG recommends that the extension be supported. This column is assigned a value of "N" unless explicitly requested. Adding a value with 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 "ECHConfig Extension" registry are subject to the Specification Required registration policy ([RFC8126], Section 4.6), with the policies described in [RFC8447], Section 17. IANA [shall add/has added] the following note to the TLS ECHConfig Extension registry:¶

Note: The role of the designated expert is described in RFC 8447. 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. These can be used by servers to "grease" the contents of the ECH configuration, as inspired by [RFC8701]. This helps ensure clients process ECH extensions correctly. When constructing ECH configurations, servers SHOULD randomly select from reserved values with the high-order bit clear. Correctly-implemented client 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. These extraneous ECH configurations SHOULD have invalid keys, and public names which the server does not respond to. Correctly-implemented clients will ignore these configurations.¶

The initial contents for this registry consists 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:

This document¶

Notes:

None¶

12.1. Normative References

[ECH-IN-DNS]

Schwartz, B. M., Bishop, M., and E. Nygren, "Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings", Work in Progress, Internet-Draft, draft-ietf-tls-svcb-ech-05, 3 September 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-svcb-ech-05>.

[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/rfc/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/rfc/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/rfc/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/rfc/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/rfc/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/rfc/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/rfc/rfc8446>.

[RFC8447]

Salowey, J. and S. Turner, "IANA Registry Updates for TLS and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, <https://www.rfc-editor.org/rfc/rfc8447>.

[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/rfc/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/rfc/rfc9460>.

12.2. Informative References

[ECH-Analysis]

"A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Client Hello", November 2022, <https://www.cs.ox.ac.uk/people/vincent.cheval/publis/BCW-ccs22.pdf>.

[I-D.kazuho-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>.

[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/rfc/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/rfc/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/rfc/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/rfc/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/rfc/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/rfc/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/rfc/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/rfc/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/rfc/rfc8744>.

[WHATWG-IPV4]

"URL Living Standard - IPv4 Parser", May 2021, <https://url.spec.whatwg.org/#concept-ipv4-parser>.

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

• Keep-alive¶

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

• Add CCS2022 reference and summary (#539)¶

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

• Keep-alive¶

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

• Editorial improvements¶

D.5. 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 middlebox sections (#480, #478, #475, #508)¶

• Editorial iprovements (#485, #488, #490, #495, #496, #499, #500, #501, #504, #505, #507, #510, #511)¶

D.6. 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.7. 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 when applicable (#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.8. Since draft-ietf-tls-esni-09

• Finalize HPKE dependency (#390)¶

• Move from client-computed to server-chosen, one-byte config identifier (#376, #381)¶

• Rename ECHConfigs to ECHConfigList (#391)¶

• Clarify some security and privacy properties (#385, #383)¶