Change:
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

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.