On Saturday, December 05, 2015 01:32:11 pm Eric Rescorla wrote: > Subject: SNI Encryption Part XLVIII > > Folks, > > TL;DR. > This message describes a technique for doing SNI encryption that just > requires (re)adding EncryptedExtensions to the client's first flight [0] > defining an extension that indicates "tunnelled TLS" and (maybe) a new > TLS content type. We would only tunnel the first flight and everything > else would be handed off to the hidden service. This seems like the > minimal change to enable Encrypted SNI while retaining our existing > analytical frame for the rest of TLS. [...snip...]
Neat. This design is modeled more similarly to what SNI is actually for and this generalized approach may be useful for other applications. Not that simple, but we knew that we weren't going to get that here. This is actually more than just SNI encryption; every possible indicator in a server's first flight gets encrypted here. We can get encrypted ALPN through this too, which could be nice to have. It would give ideal protection against attempts to identify the intended server via ClientHello fingerprinting, in general. (still a finite amount of virtual hosts to guess from, but that's not fixable here) Sounds like a good proposal to me. :) Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
