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 <ja...@appelbaum.net> wrote: > On 12/2/15, Dave Garrett <davemgarr...@gmail.com> 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
