On Mon, May 22, 2017 at 5:35 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > It is within the above that I can see a real problem in making more broad > use of TCSCs problematic. If the browser community does not effectively > move in the fashion of a single actor with a breaking change when necessary > for addressing a security concern, I would agree that frankly anything > which adds additional field deployment scenarios into the ecosystem will > only make things worse. > > On the other hand, perhaps the lesson to be learned there is that better > concensus as to scheduling of impact of breaking changes should be > negotiated amongst the browser participants and handed down in one voice to > the Root CAs and onward to the web community. > > The user can't blame Chrome if Safari and Firefox break for the same use > case in quite near term. When there is no one left to blame for a broken > website BUT the broken website, the blame will be taxed where it is > deserved. >
There are both technical and non-technical hurdles that prevent that from being meaningfully accomplished. On the non-technical front, the nature of relationships with third-party entities (CAs) makes it complex to act in a coordinated fashion, for what are hopefully obvious reasons. On a pragmatic, technical front, the asymmetric release cycles prevent there from ever being a true Flag Day, and as such, means there's always a first mover penalty, and there's always jockeying to avoid the pain of that first-mover penalty. I'm not sure whether to draw the parallel to the prisoner's dilemma, but it's worth pointing out that Microsoft was the first to announce a SHA-1 date, and the last to implement it (having only recently shipped it, after other browsers worked through the issues - and the user pain). To achieve parity, one would need to implement a concerted flag day, much like World IPv6 Day. Unfortunately, such flag days inherently mean there is a limit to the degree of testing and assessing breakage, and any bugs - bugs that would cause the change to be reverted or fixed - cannot be fixed ahead of time. These are issues that the browser community is unable to solve. Not unwilling, but on a purely technical front, unable to achieve while also serving their goals of shipping reliable products to users. > One particular hesitation that I have in fully accepting your position is > that it would seem that your position would recommend a Web PKI with a very > few concentrated actors working subject to the best practices and with > minimal differentiation. (Say, for example, a LetsEncrypt and 3 distinct > competitors diverse of geography and management but homogenous as to intent > and operational practice.) The 4 CAs could quickly be communicated with > and could adapt to the needs of the community. Extrapolating from > LetsEncrypt's performance also suggests it would be technologically > feasible for just a few entities to pull this off, too. Yet, I don't see a > call for that. Where's the balance in between and how does one arrive at > that? The Web PKI already has virtually zero differentiation. That's a foregone conclusion, by virtue of compliance to the Baseline Requirements. That is, the only real differentiation is on ubiquity of roots, probability of removal (due to misissuance), and price. That said, despite this, it should be for very obvious reasons, much like above, why the obvious conclusion is not one that is actively pursued. Would such a system be better on a security front? In many ways, yes. The distributed nature of the Web PKI was not, as some might claim, an intentional design goal for security, but was done moreso for non-technical reasons, such as perceived liability. Having 5 entities with keys to the Internet is, unquestionably, better than having 5000 entities with the keys to the Internet. To date, most systems have maintained an unbounded root store (modulo per-company limits), because there has not been a desire to include technical differentiation. One could just as easily see a goal that, in the furtherance of Internet security, a root store limiting it to 10 CAs, all implementing a common issuance API, and objectively measured in terms of things like performance, availability, and systemtic security. However, as you can see from just the inclusion reviews as it stands, that's a time consuming and difficult task, and for most root stores, the amount of time that vendors are dedicating average around 1.5 - 2 people for the entire company, which is far less than needed to implement such changes. But to the original point - can browsers unilaterally cut off (potentially large) swaths of the Internet? No. And a profile of TCSCs that has 10,000 of them can easily mean that's what it entails. If it was otherwise possible, we would have HTTPS-by-default by now - but as you can see from those discussions, or the discussions of disabling plugins (which are an security disaster) by default, changes in the Web Platform move glacially slow compared to the current agility and flexibility of the Web PKI. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
