Original text:
Although TLS 1.3 RFC8446 encrypts most of the handshake, including the server certificate, there are several ways in which an on-path attacker can learn private information about the connection.  The <del> cleartext Server Name Indication (SNI) extension in ClientHello </del>  messages, which leaks the target domain for a given connection, is perhaps the most sensitive information unencrypted in TLS 1.3. The target domain may also be visible through other channels, such as <del> cleartext client DNS queries, visible server IP addresses (assuming </del>  the server does not use domain-based virtual hosting), or other indirect mechanisms such as traffic analysis.  DoH I-D.ietf-doh-dns- over-https and DPRIVE RFC7858 RFC8094 provide mechanisms for clients the SNI remains the primary explicit signal used to determine the server's identity. <del> The TLS WG has extensively studied the problem of protecting the SNI, </del>  but has been unable to develop a completely generic solution.  I- D.ietf-tls-sni-encryption provides a description of the problem space and some of the proposed techniques.  One of the more difficult the result often has undesirable performance consequences, incomplete coverage, or both. <del> The design in this document takes a different approach: it assumes that private origins will co-locate with or hide behind a provider (CDN, application server, etc.) which can protect SNIs for all of the domains it hosts.  As a result, SNI protection does not indicate that the client is attempting to reach a private origin, but only that it is going to a particular service provider, which the observer could already tell from the visible IP address. The design in this document introduces a new extension, called Encrypted Client Hello (ECH), which allows clients to encrypt the entirety of their ClientHello to a supporting server.  This protects the SNI and other potentially sensitive fields, such as the ALPN list.  This extension is only supported with (D)TLS 1.3 RFC8446 and newer versions of the protocol. </del>  2. 3. <del> This document is designed to operate in one of two primary topologies shown below, which we call "Shared Mode" and "Split Mode" </del>  3.1. In Shared Mode, the provider is the origin server for all the domains <del> whose DNS records point to it and clients form a TLS connection directly to that provider, which has access to the plaintext of the connection. </del>  <del> In Split Mode, the provider is _not_ the origin server for private domains.  Rather the DNS records for private domains point to the </del>  provider, and the provider's server relays the connection back to the <del> backend server, which is the true origin server.  The provider does not have access to the plaintext of the connection. </del>  3.2. <del> ECH works by encrypting the entire ClientHello, including the SNI and any additional extensions such as ALPN.  This requires that each provider publish a public key and metadata which is used for ClientHello encryption for all the domains for which it serves directly or indirectly (via Split Mode).  This document defines the format of the SNI encryption public key and metadata, referred to as an ECH configuration, and delegates DNS publication details to HTTPS- RR, though other delivery mechanisms are possible.  In particular, if some of the clients of a private server are applications rather than Web browsers, those applications might have the public key and metadata preconfigured. When a client wants to form a TLS connection to any of the domains served by an ECH-supporting provider, it constructs a ClientHello in the regular fashion containing the true SNI value (ClientHelloInner) and then encrypts it using the public key for the provider.  It then constructs a new ClientHello (ClientHelloOuter) with an innocuous SNI (and potentially innocuous versions of other extensions such as ALPN RFC7301) and containing the encrypted ClientHelloInner as an extension.  It sends ClientHelloOuter to the server. Upon receiving ClientHelloOuter, the server can then decrypt ClientHelloInner and either terminate the connection (in Shared Mode) or forward it to the backend server (in Split Mode). Note that both ClientHelloInner and ClientHelloOuter are both valid, complete ClientHello messages.  ClientHelloOuter carries an encrypted representation of ClientHelloInner in a "encrypted_client_hello" extension, defined in encrypted-client-hello. </del>  4. The serialized and encrypted ClientHelloInner structure, AEAD- encrypted using HPKE with the selected KEM, KDF, and AEAD <del> algorithm and key generated as described below.  {:br} </del>  If the server accepts ECH, it does not send this extension.  If it rejects ECH, then it sends the following structure in When the server cannot decrypt or does not process the "encrypted_client_hello" extension, it continues with the handshake <del> using the cleartext "server_name" extension instead (see server- </del>  behavior).  Clients that offer ECH then authenticate the connection with the public name, as follows: correspond to ECH PSKs.  ECH PSKs offered by the client are associated with the ECH name.  The server was unable to decrypt then ECH name, so it should not resume them when using the <del> cleartext SNI name.  This restriction allows a client to reject </del>  resumptions in auth-public-name. Note that an unrecognized ClientEncryptedCH.record_digest value may Unlike most TLS extensions, placing the SNI value in an ECH extension is not interoperable with existing servers, which expect the value in <del> the existing cleartext extension.  Thus server operators SHOULD </del>  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 Assuming ECH records retrieved from DNS are authenticated, e.g., via DNSSEC or fetched from a trusted Recursive Resolver, spoofing a <del> server operating in Split Mode is not possible.  See cleartext-dns for more details regarding cleartext DNS. </del>  Authenticating the ECHConfigs structure naturally authenticates the included public name.  This also authenticates any retry signals from

Reviewer comments:
Use the term "plaintext" consistently. Be consistent about the number of spaces following a period. (We'll go with one.) Editorial changes to Sec.1-3.

Revised text:
Although TLS 1.3 RFC8446 encrypts most of the handshake, including the server certificate, there are several ways in which an on-path attacker can learn private information about the connection.  The  <ins> plaintext Server Name Indication (SNI) extension in ClientHello </ins> messages, which leaks the target domain for a given connection, is perhaps the most sensitive information unencrypted in TLS 1.3. The target domain may also be visible through other channels, such as  <ins> plaintext client DNS queries, visible server IP addresses (assuming </ins> the server does not use domain-based virtual hosting), or other indirect mechanisms such as traffic analysis.  DoH I-D.ietf-doh-dns- over-https and DPRIVE RFC7858 RFC8094 provide mechanisms for clients the SNI remains the primary explicit signal used to determine the server's identity.  <ins> The TLS Working Group has studied the problem of protecting the SNI, </ins> but has been unable to develop a completely generic solution.  I- D.ietf-tls-sni-encryption provides a description of the problem space and some of the proposed techniques.  One of the more difficult the result often has undesirable performance consequences, incomplete coverage, or both.  <ins> The protocol specified by this document takes a different approach. It assumes that private origins will co-locate with or hide behind a provider (reverse proxy, application server, etc.) that protects SNIs for all of the domains it hosts.  As a result, SNI protection does not indicate that the client is attempting to reach a private origin, but only that it is going to a particular service provider, which the observer could already tell from the visible IP address. This document specifies a new TLS extension, called Encrypted Client Hello (ECH), that allows clients to encrypt their ClientHello to a supporting server.  This protects the SNI and other potentially sensitive fields, such as the ALPN list RFC7301.  This extension is only supported with (D)TLS 1.3 RFC8446 and newer versions of the protocol. </ins> 2. 3.  <ins> This protocol is designed to operate in one of two topologies illustrated below, which we call "Shared Mode" and "Split Mode". </ins> 3.1. In Shared Mode, the provider is the origin server for all the domains  <ins> whose DNS records point to it.  In this mode, the TLS connection is terminated by the provider. </ins>  <ins> In Split Mode, the provider is not the origin server for private domains.  Rather, the DNS records for private domains point to the </ins> provider, and the provider's server relays the connection back to the  <ins> origin server, who terminates the TLS connection with the client. Importantly, service provider does not have access to the plaintext of the connection. 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. </ins> 3.2.  <ins> ECH allows the client to encrypt sensitive ClientHello extensions, e.g., SNI, ALPN, etc., under the public key of the client-facing server.  This requires the client-facing server to publish the public key and metadata it uses for ECH for all the domains for which it serves directly or indirectly (via Split Mode).  This document defines the format of the ECH encryption public key and metadata, referred to as an ECH configuration, and delegates DNS publication details to HTTPS-RR, though other delivery mechanisms are possible. In particular, if some of the clients of a private server are applications rather than Web browsers, those applications might have the public key and metadata preconfigured. When a client wants to establish a TLS session with the backend server, it constructs its ClientHello as usual (we will refer to this as the ClientHelloInner message) and then encrypts this message using the ECH public key.  It then constructs a new ClientHello (ClientHelloOuter) with innocuous values for sensitive extensions, e.g., SNI, ALPN, etc., and with the encrypted ClientHelloInner in an "encrypted_client_hello" extension, which this document defines (encrypted-client-hello).  Finally, it sends ClientHelloOuter to the server. Upon receiving ClientHelloOuter, the client-facing server processes the encrypted ClientHelloInner and either terminates the connection (in Shared Mode) or forwards it to the backend server (in Split Mode). </ins> 4. The serialized and encrypted ClientHelloInner structure, AEAD- encrypted using HPKE with the selected KEM, KDF, and AEAD  <ins> algorithm and key generated as described below. {:br} </ins> If the server accepts ECH, it does not send this extension.  If it rejects ECH, then it sends the following structure in When the server cannot decrypt or does not process the "encrypted_client_hello" extension, it continues with the handshake  <ins> using the plaintext "server_name" extension instead (see server- </ins> behavior).  Clients that offer ECH then authenticate the connection with the public name, as follows: correspond to ECH PSKs.  ECH PSKs offered by the client are associated with the ECH name.  The server was unable to decrypt then ECH name, so it should not resume them when using the  <ins> plaintext SNI name.  This restriction allows a client to reject </ins> resumptions in auth-public-name. Note that an unrecognized ClientEncryptedCH.record_digest value may Unlike most TLS extensions, placing the SNI value in an ECH extension is not interoperable with existing servers, which expect the value in  <ins> the existing plaintext extension.  Thus server operators SHOULD </ins> 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 Assuming ECH records retrieved from DNS are authenticated, e.g., via DNSSEC or fetched from a trusted Recursive Resolver, spoofing a  <ins> server operating in Split Mode is not possible.  See plaintext-dns for more details regarding plaintext DNS. </ins> Authenticating the ECHConfigs structure naturally authenticates the included public name.  This also authenticates any retry signals from