Hi *, Jacob Appelbaum wrote: > I'm sorry but that analysis is just not a serious and rigorous analysis.
No it's not. It's a very short presentation from a TLS-WG interim meeting. The threat-model concerns Akamai's (and other's) current and - possibly - future use of TLS. We're not trying to build an Onion routing protocol. Given the FUD on the Tor dev list, this is a good thing. While the presentation might have flaws from the perspective of an Onion routing protocol developer, it reflects the point of view of a lot of people/companies on this list, I assume. > >> 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. See above, different point of views on the same problem. I agree here and think we should continue to find a proper solution for encrypted-SNI for TLS 1.3 - if at all possible. What we currently have on our hands is not very convincing to me. > >> 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. +1. > >> 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. > While kind of a political/policy document I agree that IETF WG's should follow (and participants read) it. I remember the STRINT meeting in 2014 where a lot of people were very pissed about NSA activity and we decided we want to do something about it. If it takes a standard a few months longer to be finished, please give it the proper amount of time for enough people to put their ideas into it. Most people do not come up with solid engineering solutions over night. And crypto is hard as we all know. We should not forget that TLS has a very different threat-model and performance assumptions than Tor though. Thanks, Aaron
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
