Bruce, On 12/07/2013 07:29 AM, Bruce Perens wrote: > On 12/06/2013 01:20 PM, Nicholas Weaver wrote: >> If the attacker can see your fetches he can execute a >> man-on-the-side attack through packet injection. > This is the first one I've seen that is actually compelling.
I agree that Nicholas' posting is compelling. It really is. I also agree that a bunch of the non-technical analogy-driven stuff is not at all compelling. But one compelling argument is enough really. > But it's an . authentication problem rather than a confidentiality > one. I don't think so. The lack of confidentiality lets the adversary win the race unless you assume 100% coverage of authenticated JS and 100% validation of that and that there are no diginotar like entities involved in the currently non-existent JS authentication infrastructure. Even ignoring the race condition, it'd only be reasonable to treat this as an authentication-only problem if there was a solution for the JS authentication problem. Today, there's no such solution for how to load JS with integrity but without TLS after an https:// "landing page" load. I've thought about ways to do it with RFC 6920, but so far without finding a way that could scale or would be likely to get adopted - apparently the JS code gets updated too often for a 6920 based approach to help very much. So, while authenticated-JS is also a fine problem on which to work, today we have tooling for addressing the problem via ubiquitous TLS but we do not have the kind of tooling that would be needed for a solution that does not provide confidentiality. Even if we only did opportunistic encryption then an observatory could spot a pervasive attack against that, or against that for Air France to use the example cited. (Air France might be motivated to want such an observatory to exist for example.) Separately, if one considers the long-tail bits of JS code loaded from the long-tail set of web sites then again there is some benefit in confidentiality since without that the adversary can pervasively find the vulnerable code and sites from those. The "long-tail" here is relevant because we should assume the adversary knows the vulnerabilities for the top-10^N sites and JS packages. I think any IETF approach to this kind of thing should not give a high preference to the top-10^N anything really, which again argues for doing this based on TLS or similar I think. So what I see is a compelling problem-statement, and an existing set of tools that can address that if more widely deployed, and where confidentiality is in reality an inherent part of doing that. Cheers, S. _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
