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

[Martin Thomson <[e-mail]>]

There are a lot of inaccuracies in that presentation, so I wouldn't
pin too much on it.

In any case, before we all get too excited about this, there are some
solutions, I've seen a write-up of one of them, but it was a little
hard to follow first time around.  Some of the things that are
described as impossible aren't that hard to fix.  On the flip site, it
doesn't provide a fully general solution.

Expect to see something very soon.  Until then, I don't think that an
in-depth on what isn't even at a straw-man level of detail is that
helpful.  We need details before we can say whether the cost-benefit
makes sense.

On 3 December 2015 at 14:38, Jacob Appelbaum <[e-mail]> wrote:
> 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
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls