On Wednesday, May 10, 2017 03:28:48 pm Ilari Liusvaara wrote: > On Wed, May 10, 2017 at 07:28:51PM +0200, Hubert Kario wrote: > > Yes, encrypted SNI was discussed and ultimately rejected. > > > > But do we really have to send the literal value? Don't we need to just make > > sure that the client and server agree on the host that the client wants to > > connect? > > > > Couldn't we "encrypt" the SNI by hashing the host name with a salt, sending > > the salt and the resulting hash, making the server calculate the same hash > > with each of the virtual host names it supports and comparing with the > > client > > provided value? > > What makes encrypting SNI nasty is replay attacks. > > There also was proposal for putting SNI mapping into DNS (which limits the > leakage if DNS lookups are private). However, I came up with a way to use > that to attack HTTPS (the usual "default vhost" attacks).
On Wednesday, May 10, 2017 04:24:05 pm Daniel Kahn Gillmor wrote: > On Wed 2017-05-10 12:12:34 -0700, Christian Huitema wrote: > > It certainly was. But then the clear text SNI is a gaping privacy hole > > in TLS, the kind of issue that should keep us awake at night until it is > > resolved. We need to make sure that we make progress, rather than rehash > > the old arguments. Maybe we should invest some time and document the > > various proposals in a draft. I am willing to work on that. Any other > > volunteers? > > I agree with Christian's assessment of the problem, and i'd be > interested in collaborating on such a draft. > > The DNS folks are making strides to protect name information (the other > main place where this kind of data is leaking). TLS needs to keep up. Encrypted SNI has been talked to death, and coming up with new schemes that warrant air quotes in the subject around "encrypted" feels like a waste of time. Wouldn't it be better to just focus on finishing the encrypt-all-the-things approach and plan out a way to distribute a host DH key (+ a few params, e.g. port(s)+protocol(s) to use with encrypted hellos) via DNS to encrypt everything straight from the ClientHello? Stick a supported_groups in there as well and we can make HRR unneeded while we're at it. This would also protect against 3rd parties attempting to fingerprint clients via ClientHello parameters. (probably a few other things that could be listed that could be helped, too) Simply put, some of us were convinced a while ago that encrypted SNI isn't nearly as useful as it first seems, however fully encrypted hellos address that problem and more. I think it'd be better to work towards a more complete solution here than just worrying about SNI. Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
