Original text:
yet seen significant (or really any) security analysis.  It should not be used as a basis for building production systems. <del> Although TLS 1.3 I-D.ietf-tls-tls13 encrypts most of the handshake, including the server certificate, there are several other channels that allow an on-path attacker to determine the domain name the client is trying to connect to, including: </del>  Cleartext client DNS queries. A list of extensions that the client can take into consideration when generating a Client Hello message.  The format is defined in <del> I-D.ietf-tls-tls13; Section 4.2.  The purpose of the field is to provide room for additional features in the future; this document does not define any extension. </del>  The semantics of this structure are simple: any of the listed keys may be used to encrypt the SNI for the associated domain name.  The The encrypted SNI is carried in an "encrypted_server_name" extension, which contains an EncryptedSNI structure:  A cryptographic hash of the ESNIKeys structure from which the ESNI key was obtained, i.e., from the first byte of "checksum" to the end of the structure.  This hash is computed using the hash function associated with "suite". <del> The cipher suite used to encrypt the SNI. </del> The original ServerNameList from the "server_name" extension, padded and AEAD-encrypted using cipher suite "suite" and with the key generated as described below. In order to send an encrypted SNI, the client MUST first select one of the server ESNIKeyShareEntry values and generate an (EC)DHE share <del> in the matching group.  This share is then used for the client's "key_share" extension and will be used to derive both the SNI encryption key and the (EC)DHE shared secret which is used in the TLS key schedule.  This has two important implications: The client MUST only provide one KeyShareEntry </del>  <del> The server is committing to support every group in the ESNIKeys list (see below for server behavior). </del>  <del> The SNI encryption key is computed from the DH shared secret Z as follows: </del>  The client then creates a PaddedServerNameList: The EncryptedSNI.encrypted_sni value is then computed using the usual TLS 1.3 AEAD:  Note: future extensions may end up reusing the server's ESNIKeyShareEntry for other purposes within the same message (e.g., encrypting other values).  Those usages MUST have their own HKDF necessary to prevent downgrade attacks.  [[OPEN ISSUE: We looked at ignoring the extension but concluded this was better.]] <del> If more than one KeyShareEntry has been provided, or if that share's group does not match that for the SNI encryption key, it MUST abort the connection with an "illegal_parameter" alert. </del>  If the length of the "encrypted_server_name" extension is inconsistent with the advertised padding length (plus AEAD If DNS is misconfigured so that a client receives ESNI keys for a server which is not prepared to receive ESNI, then the server will <del> ignore the "encrypted_server_name" extension, as required by I- D.ietf-tls-tls13; Section 4.1.2.  If the servers does not require SNI, it will complete the handshake with its default certificate. Most likely, this will cause a certificate name mismatch and thus handshake failure.  Clients SHOULD not fall back to cleartext SNI, because that allows a network attacker to disclose the SNI.  They MAY attempt to use another server from the DNS results, if one is provided. </del>  6.2. A more serious problem is MITM proxies which do not support this <del> extension.  I-D.ietf-tls-tls13; Section 9.3 requires that such proxies remove any extensions they do not understand.  This will have one of two results when connecting to the client-facing server: </del>  The handshake will fail if the client-facing server requires SNI. 7.2.8. This design has no impact on application layer protocol negotiation. <del> It only affects connection routing, server certificate selection, and </del>  client certificate verification.  Thus, it is compatible with multiple protocols. 8.1. IANA is requested to Create an entry, encrypted_server_name(0xffce), <del> in the existing registry for ExtensionType (defined in I-D.ietf-tls- tls13), with "TLS 1.3" column values being set to "CH", and "Recommended" column being set to "Yes". </del>  8.2.

Reviewer comments:
Replace "It only affects connection routing, server certificate selection, and client certificate verification." with "It may affect connection routing, server certificate selection, and client certificate verification."
URL It is relative to "This design has no impact on application layer protocol negotiation.", so "only" is more explicit.
This was fixed in and I forgot to close.

Revised text:
yet seen significant (or really any) security analysis.  It should not be used as a basis for building production systems.  <ins> Although TLS 1.3 RFC8446 encrypts most of the handshake, including the server certificate, there are several other channels that allow an on-path attacker to determine the domain name the client is trying to connect to, including: </ins> Cleartext client DNS queries. A list of extensions that the client can take into consideration when generating a Client Hello message.  The format is defined in  <ins> RFC8446; Section 4.2.  The purpose of the field is to provide room for additional features in the future; this document does not define any extension. </ins> The semantics of this structure are simple: any of the listed keys may be used to encrypt the SNI for the associated domain name.  The The encrypted SNI is carried in an "encrypted_server_name" extension, which contains an EncryptedSNI structure: <ins> The cipher suite used to encrypt the SNI. The KeyShareEntry carrying the client's public ephemeral key shared used to derive the ESNI key. </ins> A cryptographic hash of the ESNIKeys structure from which the ESNI key was obtained, i.e., from the first byte of "checksum" to the end of the structure.  This hash is computed using the hash function associated with "suite".  The original ServerNameList from the "server_name" extension, padded and AEAD-encrypted using cipher suite "suite" and with the key generated as described below. In order to send an encrypted SNI, the client MUST first select one of the server ESNIKeyShareEntry values and generate an (EC)DHE share  <ins> in the matching group.  This share will then be sent to the server in the EncryptedSNI extension and used to derive the SNI encryption key. It does not affect the (EC)DHE shared secret used in the TLS key schedule. </ins>  <ins> Let Z be the DH shared secret derived from a key share in ESNIKeys and the corresponding client share in EncryptedSNI.key_share.  The SNI encryption key is computed from Z as follows: </ins>  <ins> where ESNIContents is as specified below and Hash is the hash function associated with the HKDF instantiation. </ins> The client then creates a PaddedServerNameList: The EncryptedSNI.encrypted_sni value is then computed using the usual TLS 1.3 AEAD: <ins> Including ClientHello.KeyShareClientHello in the AAD of AEAD-Encrypt binds the EncryptedSNI value to the ClientHello and prevents cut-and- paste attacks. </ins> Note: future extensions may end up reusing the server's ESNIKeyShareEntry for other purposes within the same message (e.g., encrypting other values).  Those usages MUST have their own HKDF necessary to prevent downgrade attacks.  [[OPEN ISSUE: We looked at ignoring the extension but concluded this was better.]]  <ins> If the EncryptedSNI.key_share group does not match one in the ESNIKeys.keys, it MUST abort the connection with an "illegal_parameter" alert. </ins> If the length of the "encrypted_server_name" extension is inconsistent with the advertised padding length (plus AEAD If DNS is misconfigured so that a client receives ESNI keys for a server which is not prepared to receive ESNI, then the server will  <ins> ignore the "encrypted_server_name" extension, as required by RFC8446; Section 4.1.2.  If the servers does not require SNI, it will complete the handshake with its default certificate.  Most likely, this will cause a certificate name mismatch and thus handshake failure. Clients SHOULD NOT fall back to cleartext SNI, because that allows a network attacker to disclose the SNI.  They MAY attempt to use another server from the DNS results, if one is provided. </ins> 6.2. A more serious problem is MITM proxies which do not support this  <ins> extension.  RFC8446; Section 9.3 requires that such proxies remove any extensions they do not understand.  This will have one of two results when connecting to the client-facing server: </ins> The handshake will fail if the client-facing server requires SNI. 7.2.8. This design has no impact on application layer protocol negotiation.  <ins> It may affect connection routing, server certificate selection, and </ins> client certificate verification.  Thus, it is compatible with multiple protocols. 8.1. IANA is requested to Create an entry, encrypted_server_name(0xffce),  <ins> in the existing registry for ExtensionType (defined in RFC8446), with "TLS 1.3" column values being set to "CH", and "Recommended" column being set to "Yes". </ins> 8.2.