On Thu, Nov 17, 2016 at 3:12 PM, Nick Lamb <[email protected]> wrote: > There's a recurring pattern in most of the examples. A technical > counter-measure would be possible, therefore you suppose it's OK to screw-up > and the counter-measure saves us. I believe this is the wrong attitude. These > counter-measures are defence in depth. We need this defence because people > will screw up, but that doesn't make screwing up OK.
I think there's an even more telling pattern in Brian's examples - they're all looking in the past. That is, the technical mitigations only exist because of the ability of UAs to change to implement those mitigations, and the only reason those mitigations exist is because UAs could leverage the CA/B Forum to prevent issues. That is, imagine if this was 4 years ago, and TCSCs were the vogue, and as a result, most major sites had 5 year 1024-bit certificates. The browser wants the lock to signify something - that there's some reasonable assurance of confidentiality, integrity, and authenticity. Yet neither 5 year certs nor 1024-bit certificates met that bar. As I understand the argument being put forward, this would have involved browsers just breaking things - saying "no more" and just adding the checks. That is, actively breaking an untold number of sites - and without CT, this information would have been even harder to obtain. Until they did, none of the argument that "It's not a big deal" holds - the lock is meaningfully less secure and actively misleading, but to change the display, it involves actively breaking sites - which we know UAs are loathe to do. While it's easy to argue "Well, we have these checks now, it's not a problem" - it completely ignores the fact that security is not a static target, that we will need to deprecate more things in the future (such as SHA-1), and adopting the position being advocated means that UAs should bear all of the cost in breakage, and have no levers except 'all or nothing'. Worse, it amplifies the coordination problem - from coordinating between browsers and several hundred CAs to trying to coordinate between browsers and millions of sites. The rate of progress of the Web in deprecating JS APIs (read: glacially slow and extremely painfully) suggests this is exactly the model we should NOT be striving for, by adopting a "TCSCs don't matter" position. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
