Change:
SHOULD take steps to minimize or protect such requests during certificate validation. <del> 7.3. </del> <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. <del> 7.3.1. </del> <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

Discussion:
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.