On Tue, Sep 22, 2015 at 2:37 PM, Salz, Rich <rs...@akamai.com> wrote: > We discussed this before. Not that we can't discuss it again. Here's a link > to slides I presented at the Toronto Interim in July 2015. > > > https://drive.google.com/file/d/0B8YgrWYHqacSV2hnZmR3VjJtRUk/view?usp=sharing >
Thanks for that link, Rich! Please forgive me if my analysis has already been gone over, but I believe that there are at least three problematic aspects in the argument as presented in your slides. 1) Entrenchment of codependent vulnerabilities This is a strong antipattern in security design, and it's been practiced by some of the great minds of the field, but I think it's fundamentally mistaken. Here's how it works: There are two systems, A and B. Each has a problem that enables some kind of attack. The people who maintain system A say: "There is no point in fixing A, because any attacker who breaks A could achieve the same results via B." But the people who maintain system B say: "There is no point fixing B because any attacker who breaks B can achieve the same results via A." Both groups are using solid logic: neither one of them would materially improve user security by fixing the vulnerability in their system. The Codependent Vulnerability antipattern arises when no progress is ever made, because each group decides that the problems outside its control will probably never be fixed. In your slides, I see several instances of codependent vulnerabilities: a) Improved DNS security vs Encrypted SNI The lack of security in current DNS usage is taken to justify not improving SNI privacy. But in discussions about DNS privacy, vulnerabilities in other protocols are frequently taken as justification for not improving DNS privacy. b) Traffic analysis vs encryption Traffic analysis is indeed strong today, but it's not omnipotent, and good research on resisting it is happening all the time. But if we take the weaknesses of TLS against traffic analysis a a permanent feature of the world, then such research will have less opportunity to bear fruit, since TLS will entrench the problems that anti-traffic-analysis research cannot yet solve. c) Technical attacks vs rubber-hose attacks See point 2 below. 2) Attacks are not equally costly and do not scale equally well. It's not sufficient to say "This defense will not render the attack impossible; therefore it is useless"; we also need to consider whether the defense will render the attack _more expensive_. Even for regimes unconcerned with fair play and regimes with significantly intrusive attitudes to civil liberties... intimidating citizens, applying political pressues, and backdooring infrastructure are not zero-cost operations. In nearly all cases, ithese attacks are more difficult and costly than simply reading bytes off the wire. 3) Censorship vs surveillance. The analysis in the slides is concerned with attackers against privacy rather than attackers against availability. But IMNSHO, both kinds of attacker are a significant threat to human rights. Unencrypted SNI makes a censor's job extremely easy. In today's TLS, it's trivial to block targeted domains hosted at a provider without blocking ones where the censors consider access desirable. Encrypting SNI would make this kind of blocking more difficult and technically expensive. To be fair, encrypted SNI would probably make trouble for providers who host some censored and some uncensored services. Plaintext SNI does make it easier for censors to be selective, and thereby makes it easier for hosting providers to avoid conflicts and drama. best wishes, -- Nick Mathewson <ni...@torproject.org> _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
