Original text:
5. The encrypted SNI is carried in an "encrypted_server_name" extension, <del> which contains an EncryptedSNI structure: </del>  The cipher suite used to encrypt the SNI. padded and AEAD-encrypted using cipher suite "suite" and with the key generated as described below.  5.1. In order to send an encrypted SNI, the client MUST first select one The client then creates a PaddedServerNameList:  This value consists of the serialized ServerNameList from the "server_name" extension, padded with enough zeroes to make the total structure ESNIKeys.padded_length bytes long.  The purpose of the encrypting other values).  Those usages MUST have their own HKDF labels to avoid reuse. <del> [[OPEN ISSUE: If in future you were to reuse these keys for 0-RTT </del>  priming, then you would have to worry about potentially expanding twice of Z_extracted.  We should think about how to harmonize these <del> to make sure that we maintain key separation.  Similarly, if the server uses the same key for ESNI as it does in ServerKeyShare, this is going to involve re-use of Z in some hard to analyze ways.  Of course, this would also involve abandoning PFS.]] </del>  This value is placed in an "encrypted_server_name" extension. innocuous dummy one (this is required for technical conformance with RFC7540; Section 9.2.)  5.2. Upon receiving an "encrypted_server_name" extension, the client- it were the "server_name" extension to finish the handshake.  It SHOULD pad the Certificate message, via padding at the record layer, such that its length equals the size of the largest possible <del> Certificate (message) covered by the same ESNI key. </del>  5.4. <del> The backend Server ignores both the "encrypted_server_name" and the "server_name" (if any) and completes the handshake as usual.  If in Shared Mode, the server will still know the true SNI, and can use it for certificate selection.  In Split Mode, it may not know the true SNI and so will generally be configured to use a single certificate. communicating-sni describes a mechanism for communicating the true SNI to the backend server. Similar to the Shared Mode behavior, the backend server in Split Mode SHOULD pad the Certificate message, via padding at the record layer such that its length equals the size of the largest possible Certificate (message) covered by the same ESNI key. </del>  6. IANA is requested to Create an entry, encrypted_server_name(0xffce), in the existing registry for ExtensionType (defined in RFC8446), with <del> "TLS 1.3" column values being set to "CH", and "Recommended" column being set to "Yes". </del>  8.2.

Reviewer comments:
This is a proposal to address the misrouting and key share replacement attacks identified by Ekr, Karthik, and Benjamin. Please help me improve it!
Some minor nits.

Revised text:
5. The encrypted SNI is carried in an "encrypted_server_name" extension,  <ins> defined as follows: For clients (in ClientHello), this extension contains the following EncryptedSNI structure: </ins> The cipher suite used to encrypt the SNI. padded and AEAD-encrypted using cipher suite "suite" and with the key generated as described below. <ins> For servers (in EncryptedExtensions), this extension contains the following structure: The contents of PaddedServerNameList.nonce.  (See client- behavior.) </ins> 5.1. In order to send an encrypted SNI, the client MUST first select one The client then creates a PaddedServerNameList: <ins> The true SNI. A random 16-octet value to be echoed by the server in the "encrypted_server_name" extension. Zero padding whose length makes the serialized struct length match ESNIKeys.padded_length. </ins> This value consists of the serialized ServerNameList from the "server_name" extension, padded with enough zeroes to make the total structure ESNIKeys.padded_length bytes long.  The purpose of the encrypting other values).  Those usages MUST have their own HKDF labels to avoid reuse.  <ins> [[OPEN ISSUE: If in the future you were to reuse these keys for 0-RTT </ins> priming, then you would have to worry about potentially expanding twice of Z_extracted.  We should think about how to harmonize these  <ins> to make sure that we maintain key separation.]] </ins> This value is placed in an "encrypted_server_name" extension. innocuous dummy one (this is required for technical conformance with RFC7540; Section 9.2.) <ins> If the server does not provide an "encrypted_server_name" extension in EncryptedExtensions, the client MUST abort the connection with an "illegal_parameter" alert.  Moreover, it MUST check that PaddedServerNameList.nonce matches the value of the "encrypted_server_name" extension provided by the server, and otherwise abort the connection with an "illegal_parameter" alert. </ins> 5.2. Upon receiving an "encrypted_server_name" extension, the client- it were the "server_name" extension to finish the handshake.  It SHOULD pad the Certificate message, via padding at the record layer, such that its length equals the size of the largest possible  <ins> Certificate (message) covered by the same ESNI key.  Moreover, the server MUST include the "encrypted_server_name" extension in EncryptedExtensions, and the value of this extension MUST match PaddedServerNameList.nonce. </ins> 5.4.  <ins> In Split Mode, the backend server must know PaddedServerNameList.nonce to echo it back in EncryptedExtensions and complete the handshake.  communicating-sni describes one mechanism for sending both PaddedServerNameList.sni and PaddedServerNameList.nonce to the backend server.  Thus, backend servers function the same as servers operating in Shared mode. </ins> 6. IANA is requested to Create an entry, encrypted_server_name(0xffce), in the existing registry for ExtensionType (defined in RFC8446), with  <ins> "TLS 1.3" column values being set to "CH, EE", and "Recommended" column being set to "Yes". </ins> 8.2.