Re: [TLS] About encrypting SNI - Traffic Analysis Attacks?

[Nico Williams <[e-mail]>]

On Tue, May 13, 2014 at 2:57 PM, Michael StJohns <[e-mail]> wrote:
> On 5/13/2014 1:53 PM, Daniel Kahn Gillmor wrote:
> One of the things missing from this discussion is whether or not encrypting
> the SNI is sufficiently resistant to traffic analysis techniques to make it
> worthwhile:  E.g.  A trivial attack is where there are a 100 web sites at a
> particular IP address, but only one of them has a name that is 28 characters
> in length and that's the one eavesdroppers care about.  A non trivial attack
> is where the web sites can be characterized via their patterns of traffic (a
> web page with 28 items, of which 16 are pictures with known fixed lengths).

Well, and for the many cases where there are many fewer than 100 sites
at one IP address...  the IP address will reveal plenty.

> Random padding can mitigate some of this (but will require some changes to
> TLS) and random reordering of HTTP requests can also help a bit (mostly a
> client side change), but transaction based protocols like HTTP (e.g. most of
> the time I'm pretty sure that the client is sending some sort of GET even if
> I don't know exactly what its asking for) tend to reveal the underlying
> patterns, even if the actual data is protected.

HTTP has infinitely extensible headers just for this purpose ;)

We can address some of the traffic analysis problems.  I think if we
don't now, we will eventually.  It's just a question of when.  Sooner
would be better.  It might not be feasible at this time; we should
find out if it is.

So far it looks like we'd need:

a) confidentiality protection in DNS,

b) leverage DNSSEC/DANE to get zero-round-trip SNI encryption in TLS,

c) apply care to avoid leaking information via payload sizes.

What else?

Sounds like a lot to get right for 1.3!  Even if we defer (a) but make
some assumptions about it so we can ship 1.3 and enable (a) later, we
might get it wrong.

Nico
--