> I think that is false. One could easily use the "cleartext" SNI field and > insert an encrypted value. A hash of the name would be a simple example but > not a secure example, of course.
Encrypted SNI doesn't give you the kind of protection you think that it does. We (me and a colleague) did a pretty thorough analysis that showed this. It was not a conclusion we expected, or wanted, to reach. It was presented at the TLS Interim before the IETF in Toronto. Slides should be online. (For example, the adversary will know the IP address or might not care about false positives, etc.) In spite of this, another colleague (Brian Sniffen) came up with a way to do it at the tail end of the Seattle interim. Encrypt the "true" SNI in the semi-static DH key of a "fronting" site. And then the front decrypts the true SNI and forwards to the obscured site. Ekr and dkg presented it in Yokohama, but not very well. :) They're presumably working on something better. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
