Original text:
7.2.  ESNI 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 SHOULD take steps to minimize or protect such requests during certificate validation. <del> 7.3. </del>  I-D.ietf-tls-sni-encryption lists several requirements for SNI encryption.  In this section, we re-iterate these requirements and assess the ESNI design against them. <del> 7.3.1. </del>  Since the SNI encryption key is derived from a (EC)DH operation between the client's ephemeral and server's semi-static ESNI key, the Hello, with a different ephemeral key share, as the terminating server will fail to decrypt and verify the ESNI value. <del> 7.3.2. </del>  This design depends upon DNS as a vehicle for semi-static public key distribution.  Server operators may partition their private keys by sending different Resource Records containing ESNIRecord and ESNIKeys values with different keys using a short TTL. <del> 7.3.3. </del>  This design requires servers to decrypt ClientHello messages with ClientEncryptedSNI extensions carrying valid digests.  Thus, it is server.  This attack is bound by the number of valid TCP connections an attacker can open. <del> 7.3.4. </del>  As more clients enable ESNI support, e.g., as normal part of Web browser functionality, with keys supplied by shared hosting ESNI extensions (see grease-extensions), which helps ensure the ecosystem handles the values correctly. <del> 7.3.5. </del>  This design is not forward secret because the server's ESNI key is static.  However, the window of exposure is bound by the key lifetime.  It is RECOMMENDED that servers rotate keys frequently. <del> 7.3.6. </del>  This design permits servers operating in Split Mode to forward connections directly to backend origin servers, thereby avoiding unnecessary MiTM attacks. <del> 7.3.7. </del>  Assuming ESNI records retrieved from DNS are validated, e.g., via DNSSEC or fetched from a trusted Recursive Resolver, spoofing a client validates the server certificate against the public name before retrying. <del> 7.3.8. </del>  This design has no impact on application layer protocol negotiation. It may affect connection routing, server certificate selection, and client certificate verification.  Thus, it is compatible with multiple protocols. <del> 7.4. </del>  Note that the backend server has no way of knowing what the SNI was, but that does not lead to additional privacy exposure because the

Reviewer comments:
Addresses .
This seems to be somewhat discussed in the draft and in issues, but I fail to see the motivation behind not using the ESNI key to encrypt other extensions such as ALPN. The main concern seems to be around entities seeing the value of decrypted ALPN, but that's still better than ALPN being the clear. Another concern is a middlebox blocking this extension, but if the client decides to fail hard, blocking is better than leaking; and if a client falls back to unencrypted then the connection works regardless. If I'm missing something, can that be clarified in the draft?
I think that the goal with ALPN is to ensure that the set of values that are advertised remains small and fixed. That is, everyone can offer h2+http/1.1 and no more. This gives no advantage to a passive observer in terms of distinguishing traffic; the pattern of TLS extensions (order and so forth) gives more away.
The other point is that SNI designates the server the client wants to handshakes with. ALPN (as well as other properties of ClientHello) is a property of the handshake. Consider the split case. SNI is decrypted by the fronting server. ALPN will be a property that will be taken into consideration by the backend server.
I agree that in current usage, ALPN is only used for h2 vs http/1.1. But if we had a way to hide ALPN from censors, we could use it to run a VPN over TLS to evade censorship - I'd like to have a TLS server on port 443 that mostly serves HTTPS but can also serve VPN to select clients. In the split case, having the fronting server decrypt the ALPN and pass it decrypted to the backend server is fine - I'm mostly concerned about threats between the client and the fronting server.
Current draft is designed in a way to allow stock TLS servers to be run as a hidden server. Creating a way to pass the decrypted ALPN (or decrypted SNI) from the client-facing server to hidden server destroys that design. Generally speaking, I am not opposed to protecting more properties. OTOH, I might prefer doing things in small steps; we have the extensions field in ESNIKeys.
NAME if you want to advertise a VPN ALPN on all your connections, then that would work. I'd prefer to establish privacy-preserving usage patterns as the norm so that this is considered acceptable (and not a reason to block a connection). Advertising a willingness to use a VPN connection in addition to HTTP would be analogous to what we're doing here; the observer doesn't know what you ended up using. They could decide to block based on the possibility that you are doing something bad, but that applies to encrypted SNI in equal measure.
This sounds reasonable to me. If we build this solution in a way that allows us to encrypt ALPN later without it being distinguishable from ESNI by a MitM, then I'm happy
NAME this should be fixed by -- please reopen if that's not the case!
NAME works for me, thanks.

Revised text:
7.2. <ins> ESNI protects only the SNI in transit.  Other ClientHello extensions, such as ALPN, might also reveal privacy-sensitive information to the network.  As such, it might be desirable to encrypt other extensions alongside the SNI.  However, the SNI extension is unique in that non- TLS-terminating servers or load balancers may act on its contents. Thus, using keys specifically for SNI encryption promotes key separation between client-facing servers and endpoints party to TLS connections.  Moreover, the ESNI design described herein does not preclude a mechanism for generic ClientHello extension encryption. 7.3. </ins> ESNI 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 SHOULD take steps to minimize or protect such requests during certificate validation.  <ins> 7.4. </ins> I-D.ietf-tls-sni-encryption lists several requirements for SNI encryption.  In this section, we re-iterate these requirements and assess the ESNI design against them.  <ins> 7.4.1. </ins> Since the SNI encryption key is derived from a (EC)DH operation between the client's ephemeral and server's semi-static ESNI key, the Hello, with a different ephemeral key share, as the terminating server will fail to decrypt and verify the ESNI value.  <ins> 7.4.2. </ins> This design depends upon DNS as a vehicle for semi-static public key distribution.  Server operators may partition their private keys by sending different Resource Records containing ESNIRecord and ESNIKeys values with different keys using a short TTL.  <ins> 7.4.3. </ins> This design requires servers to decrypt ClientHello messages with ClientEncryptedSNI extensions carrying valid digests.  Thus, it is server.  This attack is bound by the number of valid TCP connections an attacker can open.  <ins> 7.4.4. </ins> As more clients enable ESNI support, e.g., as normal part of Web browser functionality, with keys supplied by shared hosting ESNI extensions (see grease-extensions), which helps ensure the ecosystem handles the values correctly.  <ins> 7.4.5. </ins> This design is not forward secret because the server's ESNI key is static.  However, the window of exposure is bound by the key lifetime.  It is RECOMMENDED that servers rotate keys frequently.  <ins> 7.4.6. </ins> This design permits servers operating in Split Mode to forward connections directly to backend origin servers, thereby avoiding unnecessary MiTM attacks.  <ins> 7.4.7. </ins> Assuming ESNI records retrieved from DNS are validated, e.g., via DNSSEC or fetched from a trusted Recursive Resolver, spoofing a client validates the server certificate against the public name before retrying.  <ins> 7.4.8. </ins> This design has no impact on application layer protocol negotiation. It may affect connection routing, server certificate selection, and client certificate verification.  Thus, it is compatible with multiple protocols.  <ins> 7.5. </ins> Note that the backend server has no way of knowing what the SNI was, but that does not lead to additional privacy exposure because the