Re: Propose Removal of E-Guven root

[Peter Kurrasch]

That's fine. I don't necessarily disagree with removing the root entirely but I do think it's a more heavy-handed remedy than is necessary. I view it as the difference between a punch in the chest vs a strenuous poke. This action is a little more elective on Mozilla's part than other cases we've come across. It's warranted and justifiable, certainly, but not ‎critical like SSLv3 and such. It's very much possible there will be no fallout from this action, but still it's better to be prepared in advance. I do still think it would be a good idea to "get the word out" so that concerned admins can fix their sites before things suddenly stop working. Thanks. From: Richard Barnes Sent: Friday, March 20, 2015 10:44 AM To: ryan-mozdevsecpol...@sleevi.com Cc: Peter Kurrasch; mozilla-dev-security-pol...@lists.mozilla.org; Kathleen Wilson Subject: Re: Propose Removal of E-Guven root On Fri, Mar 20, 2015 at 10:37 AM, Ryan Sleevi <ryan-mozdevsecpol...@sleevi.com> wrote: On Thu, March 19, 2015 3:53 pm, Peter Kurrasch wrote: > There are 2 differences. First, in >  the event HSTS was activated on the site there will be no chance to >  override. Second, a user in that region may want to or need to activate >  that root because he or she relies on the impacted websites. Another >  concern is that the case by case override might still result in marginally >  usable sites because the embedded requests (css, js, images, iframes) >  could fail ("unknown issuer") without any chance to add exceptions for >  them. Being able to manually re-enable trust would serve as a useful >  remedy for them while still protecting the rest of the Internet >  populace. Peter, While I do appreciate your efforts to think of the users here, I do think it does a disservice to them to suggest that enabling trust in this certificate is something desirable. That is, in a matter of opinionated design, if the Mozilla Root Program has decided that the Certificate Authority is not operating in the interests of Mozilla's users and security at large, it does seem counter-productive to suggest that users should be able to trivially re-enable support. If it helps, think about how the SSL warnings themselves behave and used to behave; it used to be a single click could bypass the error and permanently save it. Increasingly, browsers have explored designs to make it more difficult to bypass the error - with corresponding studies showing that user understanding is increasing, and click through rate is decreasing. Sometimes, making things a little bit harder can make a lot more people secure. On the matter of HSTS, this is working by design with HSTS. The mere act of distrusting will prevent an override. Leaving the root in doesn't/shouldn't affect this. So I'm strongly supportive of removing both the certificate AND the trust records. For users who do have a critical need to trust this root, and are willing to accept the attendant risks that Mozilla is (rightfully) not, then they can get that root from the CA and install it in the trust store, same as they would do a self-signed root or other roots that have not been audited/are not auditable. I'm in the same place as Ryan here.  In many security decisions we make, we have to balance breakage for some people vs. risks for everyone else. When we turned off SSLv3 in Firefox, it was still required by something like 0.3% of websites -- several orders of magnitude more than will be broken by removing e-Guven.  We decided to do it  because supporting that small fraction of sites would impose a downgrade risk for every other site on the web. The situation is analogous here.  The benefit of supporting the very small number of sites that use e-Guven (thanks, Peter B!) does not balance the risk posed to every other web site by having a non-compliant CA still accepted. --Richard   _______________________________________________ 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