Ryan, If you look at the wide range of user agents accessing google.com today you'd see many legacy applications and older versions of browsers and custom browsers built from variants of the commercial browsers. By the time all/most users upgraded to new browsers, it would be time to change the roots out again and this will impact the ability for web site operators to enable TLS for all visitors.
Before we can implement a short Root usage policy we'd need to convince all browsers to follow a process for rapid updates of root stores. GlobalSign visitors use Nokia, NetFront, SeaMonkey, Amazon Silk, Blackberry and others, and assume ecommerce sites have even more legacy user agents (at percentages they cannot ignore). We'd need to be sure that these vendors change how they manage their root stores before we move to short use Roots (maybe some of them relay on the underlying operating system already and these are not all an issue). Mobile devices will perhaps be the most challenging as their OS support lifetime is relatively short but users hang onto them for longer. For example, Android 4.1 and 4.2 account for about 7% of the Android market share: https://developer.android.com/about/dashboards/index.html Android browser has about 6% market share: https://www.netmarketshare.com/browser-market-share.aspx?qprid=1&qpcustomb=1 but Android 4.1 and 4.2 are no longer supported: https://www.extremetech.com/mobile/197346-google-throws-nearly-a-billion-android-users-under-the-bus-refuses-to-patch-os-vulnerability Sure, 6% of 7% is around .5%, so in itself not a huge driver, but add up the other unsupported Android versions and those of all other mobile devices and this will become more meaningful. Under your proposal, how would you see mobile device manufacturers as well as OS and browser vendors supporting the requirement to keep updating root stores even after the end of support? Doug > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign....@lists.mozilla.org] On Behalf Of Ryan > Sleevi via dev-security-policy > Sent: Tuesday, May 16, 2017 7:48 AM > To: Peter Gutmann <pgut...@cs.auckland.ac.nz> > Cc: Nick Lamb <tialara...@gmail.com>; MozPol <mozilla-dev-security- > pol...@lists.mozilla.org>; Alex Gaynor <agay...@mozilla.com>; Cory Benfield > <c...@lukasa.co.uk>; Ryan Sleevi <r...@sleevi.com>; Gervase Markham > <g...@mozilla.org> > Subject: Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser > Consumption > > On Tue, May 16, 2017 at 7:19 AM, Peter Gutmann > <pgut...@cs.auckland.ac.nz> > wrote: > > > Ryan Sleevi <r...@sleevi.com> writes: > > > > >Mozilla updates every six to eight weeks. And that works. That's all > > >that matters for this discussion. > > > > Do all the world's CAs know this? > > > Does that matter, if all participants in Mozilla's Root Program _could_ know > this? > > I can't help but feel you're raising concerns that aren't relevant. Perhaps I > didn't explain sufficiently why even if a client takes a single copy of the > Mozilla root store and *never updates after that*, things could still work for > 20+ years for those clients, and with reduced risk for Mozilla users. I feel > like > if that point had been clearer, perhaps you would understand why it could fly. > > Perhaps you're confused and think the roots themselves have 5 year validity > (e.g. notBefore to notAfter). That's also not what I said - I said bound the > time > for inclusion of that root in Mozilla products. They're very different things, > you see, and the latter doesn't prescribe the validity period of the root - > precisely so it can support such broken 'legacy' cases without requiring too > much of the world to adopt modern security practices. > > That said, Mozilla's mission to ensure the Internet is a global public > resource > that is safe would, among other things, entitle them to push this particular > vision, since it would help make users safe. However, I merely proposed a > smaller step in that. > > Perhaps you could re-read the proposal with a fresh perspective, as I hope it > might become clearer how it could address many of these issues. As it relates > to the topic at hand, by limiting the lifetime of the roots themselves, it > reduces the risk/need to impose additional contraints - there are fewer legacy > roots, they're bounded in validity period, and things move onward towards > distrust much easier. That does seem a net-positive for the ecosystem. > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
