On Thursday, 11 May 2017 16:31:26 CEST Brian Sniffen wrote: > Daniel Kahn Gillmor <d...@fifthhorseman.net> writes: > > 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. > > Who's the audience for that draft? If it's meant to document the blind > alleys we've found, perhaps we could list both alleys, and the walls at > the end: > > - hash the name [adversaries can hash too] > - hash the name with a salt [adversaries can check the salted hash > too, as if operating all the banned sites] > - encrypt the SNI under the pre-shared key > > But beware of: > > - the adversary can replay this SNI and see what site he gets > - DDoS risk: servers can't be try lots of crypto (no asymmetric ops, > no operations that scale linearly with number of sites hosted)
Doesn't that create a Catch 22? I need to get the key to encrypt the SNI. But if we don't want the names to leak, how do I authenticate the key without telling the server what certificate I will accept to authenticate the key? That doesn't look to me like a problem we can solve with typical symmetric or asymmetric crypto - it looks to me like more of a zero-knowledge proof issue. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
