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

[Jacob Appelbaum <[e-mail]>]

On 12/2/15, Dave Garrett <[e-mail]> wrote:
> On Wednesday, December 02, 2015 01:00:26 pm Salz, Rich wrote:
>> Encrypted SNI doesn't give you the kind of protection you think that it
>> does.  We (me and a colleague) did a pretty thorough analysis that showed
>> this.  It was not a conclusion we expected, or wanted, to reach.   It was
>> presented at the TLS Interim before the IETF in Toronto.  Slides should be
>> online.  (For example, the adversary will know the IP address or might not
>> care about false positives, etc.)
>
> URL from Rich's previous email citing this:
> https://drive.google.com/file/d/0B8YgrWYHqacSV2hnZmR3VjJtRUk/view
>

I've read these slides. I'm... at a bit of a loss. The entire slide
deck seems so flippant as to be not worth addressing. It just doesn't
even pass the giggle test.

Though upon reading it, I am struck by two core points:

One is that big companies will be pressured by governments.
Ironically, Akamai isn't one of those as they're willingly in bed with
governments around the world. But I guess as the slides say, the
author isn't speaking on behalf of Akamai. That said - good, I want
governments to have to go to a company rather than to the user - the
company may have a legal team, the user may have hidden or otherwise
protected themselves. Hopefully the company is in a position to do
nothing or will take action to protect the user's basic liberties.

The second is a constant security nihilism. Yeah, a lot of stuff is
broken - so lets acknowledge it bit by bit and then fix it all.

I would encourage everyone to read the slides as the conclusion in the
presentation simply do not follow. If I had been in the audience when
they were presented, I would have been at the microphone objecting.
The idea that this convinced anyone is baffling.

It is clear that privacy concerns exist in many many different
protocols and that many protocols need to be fixed. Many people point
at other protocols as a way to punt on the issue for their own
protocol. The cycle continues and the privacy violations continue
without end.

> Please don't brush this argument off in favor of the "obvious" answer that
> encrypted SNI is helpful. The sad truth is that it's a lot of effort with a
> lot of risk for virtually no gain. I was quite in favor of encrypted SNI
> before reading it, and I had to concede the point after. If we can come up
> with a way to do it easily, ok, but it's not an avenue worth spending too
> much time on.
>

The idea of splitting the world, as the slides do, into three basic
camps (liberal democracy with good traffic analysis, liberal democracy
with bad traffic analysis and horrible dangerous places) is simply not
serious. The idea that our liberal democracies do perfect traffic
analysis and so we should ensure *everyone* including *non-NSA*
attackers can do it for *free* is just bizarre to me. It is incorrect
as a conclusion to do nothing because some people somewhere *may* be
good at traffic analysis. The logic of the slides suggest that raising
the cost from a kid-in-a-cafe to NSA is proof that we shouldn't
bother. Again, the security nihilism monster appears. We should reject
this nihilism and fix the problem.

Encrypted SNI makes sense as it makes traffic analysis harder.
Encrypting DNS queries makes sense too. Composing it with other
systems may or may not make sense. Even when TLS is composed with a
tool to do traffic analysis resistance, the exit node of the
TA-resistance network can still do selective attacks based on SNI. In
that case the DNS is likely to be resolved at a different exit point.
Thus if we want to punt again and say, hey, traffic analysis
resistance is better left to Tor or something else, please consider
that plaintext selectors make Tor's job harder.

These changes make it more expensive and in some cases, it will stop
attackers who would otherwise be able to make an attack happen
undetected. It requires an attacker to spend more money on CPU, memory
and on other resources to do correlation across multiple collection
points.

Kicking the can down the road doesn't even begin to summarize why
leaving SNI unencrypted is incorrect. Metadata is a serious problem
and reducing it whenever possible (eg: we won't fix TCP/IP on the IETF
TLS list), even in liberal democracies, helps to solve the problems we
face from mass surveillance.

All the best,
Jacob