Re: [TLS] About encrypting SNI

[Alyssa Rowan <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 14/04/2014 18:13, Eric Rescorla wrote:

> I'm not sure that this addresses the requests I have heard for SNI 
> encryption which is to conceal the sites people are going to by
> default rather than as a special case for the privacy conscious.

Precisely.

Tor (for example) wants to look like a common-or-garden browser to
avoid Eve fingerprinting it (and real, actual jackboots knocking doors
in as a result). This means, say, browsers should make - and be able
to make - the most privacy-preserving choices, too. That benefits
everyone.

Plaintext SNI makes it really easy to demux connections to the same
ip:port tuple without needing state from DNS lookups. That's an
advantage for Bob, where Bob has a lot of servers (like Rich does) -
but it's also a huge advantage for Eve and Mallory.

We should also consider if we can use the same method to protect
returned certificates, and any other plain-text ClientHello fields
(notably ALPN). We do want that if we can get it practically, so maybe
we want something slightly more general than just for SNI.

> It's certainly the case that there are some additional changes
> that would be required to make concealing SNI worth doing 
> (principally encrypted name resolution, but also a clear model for
> how to do traffic padding and other things), but conversely if we
> don't change TLS to permit concealing the SNI, then we won't get as
> much value from encrypted DNS.

What I'm worried about is the circular argument of doom and defeat:

· We don't have encrypted DNS requests, so why encrypt SNI?
· We don't have encrypted SNI, so why encrypt DNS?
· We don't have encrypted IP: why encrypt over TCP which can be RST'd?
· Privacy is hard: let's go shopping.

Maybe we should worry less about what we don't have yet: and instead,
let's do what we can to build the things we don't have to make Eve's
life a little harder in steps.

Counterbalancing our wishes of course is how much is useful,
practical, and technically feasible, especially at the scales Rich
needs to worry about. And I empathise with his troubles there. (I
seriously doubt any solution that requires iteration in linear-time
with the number of hosted domains is workable, for example!)

How can we protect the Hellos in general from Eve and Mallory as much
as we can without making Bob's (or, to a lesser extent, Alice's) life
too hard? Can we do that in a backward-compatible way? (I'm getting
the vague sense that if we can't, things look more like TLS 2.0?)

But I don't think we should give up on doing it just because it's a
tough problem to solve. It's literally the first thing listed in the
WG charter as a "do want" for TLS 1.3: so if we can't deliver that
easily, then I think we need to try harder!

I'll let you know if any sudden epiphanies arise. Anyone got any
bright ideas?
- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTTCtiAAoJEOyEjtkWi2t6y0kP/1IIj9/ckBXw4Uqsxc2hi998
oPyAC6txJug13s1HyB0Xy0hpcCBiUpzVudbuboBTAc5gEixNFifT+P+GtcpTEcWB
MqgRsQd5yCQGsEEzPIqQHwiuaY2bx/V1o4FT6bKqoKAr18aafUuUqD26IchEEVEy
4eaXwNtbAdVOOioke8CBRe4TvdSYg38wpAqMZIdEUlRAOb5wIJ0C+RWNOfLFW7CL
OxA1xXNq0y1OOdoOH1rzgfxdi443GskKOWRdcz2NAvBfDQzakvz5NEe9kpF1CFgW
fSBk5Z+uIONOlU5rWvXaGuNk+kuSIUquHyLo6pdkBgfD0qE2Z84jEcN83knEHT29
fRNl/OxTUbvjRUv5rfhwGNs/BgLKB/tX4X8hLYLAo6Z/cqdD/hXjZiTDAEEQaqgt
Lp1lWqBNKXQbp7FaOC9+RcrETTMw4EW364To9zwn+xFZG94E2Duy0daowZZapVVM
0sNWvvtIMCC2a71NfNqi0BhGkk8ExGwUVsEj333H4ljBb6ywnzPeYpCHXpk9oVYP
OFwhzHxlul7qAXq8O7gzuMkQs0BhqbiZR2Myur70kOcdiUkqRuuDh6j6x4W4q9gh
YffPV9RrTHVgO+5WxyPk6WCHgKRc2OzSB7g9T7ccmQZ/lzRCrSbEfl89EHWe6wYo
LJbuQo1ZYP6GXO63mFyX
=wBko
-----END PGP SIGNATURE-----