On Tue, May 23, 2017 at 3:45 PM Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> On Tuesday, May 23, 2017 at 12:39:05 PM UTC-5, Ryan Sleevi wrote: > > > Setting aside even the 'damage' aspect, consider the ecosystem impact. > > Assume a wildwest - we would not have been able to effectively curtail > and > > sunset SHA-1. We would not have been able to deploy and require > Certificate > > Transparency. We would not have been able to raise the minimum RSA key > > size. That's because all of these things, at the time the efforts began, > > were at significantly high rates to cause breakages. Even with the > Baseline > > Requirements, even with ample communications and PR blitzes, these > changes > > still were razor thin in terms of the breakages vendors would be willing > to > > tolerate. Microsoft and Apple, for example, weren't able to tolerate the > > initial SHA-1 pain, and relied on Chrome and Firefox to push the > ecosystem > > forward in that respect. > > > > I don't disagree with the ecosystem impact concept to which you have > referred. Where I diverge is in my belief that we already do have a wild > west situation. There are LOTS of Root CA members and lots of actual roots > and way way more unconstrained intermediates. So many that SHA-1 was > already a nightmare to deprecate and move forward on. > > As a brief aside, let's talk about SHA-1 migration and the lessons that > should have been learned earlier and how they weren't and how I don't see > anything to suggest that it will be better next time, regardless of whether > my humble proposal even got consideration -- much less that someone should > take up the torch and carry it to adoption. History already provided a > great example of urgent need for deprecation of a hash algorithm in the Web > PKI. The MD5 deprecation. Not having been a participant other than as an > end-enterprise in either of these slow moving processes, I can not say for > certain... but... A few Google searches don't make me believe that the > SHA-1 migration was any smoother or more efficient than the MD5 migration. > As I read, it appears to be arguable that the SHA-1 migration to SHA-256 > was even slower and messier. I don't think that is a reasonable conclusion. The MD5 transition took 5 years from active exploit. SHA-1 was dead the same week of the shattered.it work. Way more middleboxes were prepared for the transition - and browsers had much smoother transitions. Was it ideal? No. Was it significantly better? Yes. In part because of the BRs banning issuance. > > The point I come around to is that in most ecosystems, there's a > "criticality" of size at which everything gets harder to coordinate > changes. In many such ecosystems, once you cross that boundary, increased > size of that ecosystem and number of unique participants has a diminishing > effect on the overall difficulty of coordinating changes. > > What rational basis makes you believe that the next hash algorithm > migration will be better than this most recent one? See above. The CA/Browser Forum continues to discuss the lessons learned, but it's certainly gotten better. But more importantly - there are plenty of incremental changes - like CT - that don't require wholesale replacements. For the next five years, I'm particularly concerned with improving OCSP Stapling and CT support - and those certainly don't suffer (from the CA side) of the limits you describe. The way I see it, absent some incredible new mitigating circumstances, the > next time a rotation to a new hash algorithm is needed, the corpus of Root > CA participants and Root CA Certificates / Issuance systems will be larger > than it was this time. It seems to get larger all the time, as a trend. I disagree. I believe we're getting better, in time. At this point, I feel I should back away. I feel I've made a fairly > compelling case (at least, I shall say, the best case for it that I could > make) for the limited impact that the specific changes as to Mozilla policy > pertaining to audit & disclosure for TCSCs compliant to certain guidelines > would have. I also accept that this isn't really the place to lobby for > baseline requirements changes. A CA will have to carry that torch, if any > are interested. Oh, I would say this is absolutely the place (although perhaps in a forked thread) for that discussion. The baselines are reflective of what browser baselines are, and if you want to change browser baselines, there is no greater place for that public discussion than Mozilla. To be clear: I'm critical of the goal in large part because I used to argue the same position you're now arguing, with many of the same arguments. The experiences in enacting meaningful change, and the challenges therein, as well as lots of time spent contemplating the economic incentives for the various ecosystem actors to support change, have me far more concerned about the potential harm :) _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
