Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

[Jacob Appelbaum <[e-mail]>]

On 12/3/15, Eric Mill <[e-mail]> wrote:
> On Wed, Dec 2, 2015 at 7:52 PM, Jacob Appelbaum <[e-mail]>
> wrote:
>
>> On 12/2/15, Salz, Rich <[e-mail]> wrote:
>> >> it seems blindingly obvious to me that we want it
>> >
>> > Few things, particularly in the security arena, are blindingly obvious.
>> If
>> > it actually provides no true protection, then it's just as bad as the
>> > security theater in US airports.
>>
>> It provides protection. Specifically it provides confidentially.
>>
>> It doesn't solve the fact that the DNS is a privacy violating
>> nightmare. It doesn't change the fact that the NSA breaks the rules.
>>
>
> And what Don and Rich's analysis is trying to isolate is how much real
> protection you get from that level of confidentiality, so that a decision
> that weighs all available factors can be made, including the complexity
> cost.

I'm sorry but that analysis is just not a serious and rigorous analysis.

> It's not just a collective action problem because DNS isn't encrypted too.

The conclusion summary is that because there are many problems, we
won't address our part of the problems. The conclusion is that SNI
privacy isn't worth it because those who live in liberal democracies
with poor traffic analysis, well they just don't matter much. Which
is... just... well, as I said above, I just don't take this seriously.

> Their analysis also looks at what you get when both are encrypted. And
> regardless of DNS being encrypted, rainbow-table style reverse lookups of
> IP to DNS name are always possible. That doesn't mean encrypted SNI isn't
> worth it -- it clearly provides a security attribute (confidentiality) to
> an important piece of information.

You're now suggesting an attacker that computes rainbow-tables to
arrive a possibility which in itself sounds like a massive improvement
over what was an absolute certainty.

> But it's not enough to drive ahead and say that some attribute outweighs
> every other consideration. For example, HSTS' persistence of memory can be
> abused as a tracking device:
>
> http://zyan.scripts.mit.edu/sniffly/
>
> And this was known at the time the spec was finalized:
>
> https://tools.ietf.org/html/rfc6797#section-14.9
>
> But HSTS creates security benefits that are well worth the cost of that
> tracking potential (which can also be mitigated through preloading). There
> are a lot of browsers and communities which use and advocate for HSTS that
> might generally balk at creating tracking devices.
>

Yes, tracking with HSTS is a problem and there is work being done to
mitigate that tracking concern.

> I'm not advocating a strong stance on whether encrypted SNI is worth
> pursuing, or whether TLS record headers should be encrypted in TLS 1.3. But
> it's useful to keep the debate framed in its full context, rather than
> narrowing it to a black-and-white discussion over whether a generally good
> attribute is good or not.

Sure and that full context includes RFC 7258: "Pervasive Monitoring Is
an Attack" - something that defines reasonably clearly many of the
concerns I've stated.

All the best,
Jacob