On 12/2/15, Salz, Rich <rs...@akamai.com> wrote: >> 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.) >
Without a concrete proposal, I don't think we have any protection. My thoughts were more about the idea that we would *want* protection of SNI data - it seems blindingly obvious to me that we want it as we know SNI is used for attacks in addition to multi-homing tricks. I'm aware that layer issues make for many layers of selectors for attack. If we can avoid adding them in TLS, we can also work on improving things on every level. IP address blocking has the "collateral freedom" problem, of course. > 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. > I'm certainly interested in reviewing any cryptographic details for a possible SNI protection scheme. It sounds interesting and am looking forward to learning more. All the best, Jacob _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
