Draft: draft-ietf-tls-esni

Commentary: 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 . 
 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 does n'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 
 this should be fixed by -- please reopen if that 's not the case ! 
 works for me , thanks .
Paragraph (version B):
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.