I think you are overstating the consensus on the idea that “revocation checking doesn’t work.” Which relying parties have said that?
And much of your justification for the changes you want to make on certificate lifetime are based on that conclusion. But many disagree with that conclusion, and if we’re going to work on ways to deal with certificate revocation, then a renewed push for revocation checking is something we should also be discussing. Here is the conclusion from a well-respected 2015 academic study from Stanford measuring browser revocation checking. The study even included suggestions on how to improve CRLSets that could “could increase their coverage by several orders of magnitude”. Is Google willing to work on these issues as well? We are all in this together – CAs and browsers – in improving user security. An End-to-End Measurement of Certificate Revocation in the Web’s PKI. https://web.stanford.edu/~aschulm/docs/imc15-revocation.pdf “*** CONCLUDING DISCUSSION “Certificate revocation is a necessary component of any PKI, but it comes with costs, both real and perceived: CAs carry the cost of disseminating revocation information, while browsers risk the cost of increased web page load times. In the trade-off between low communication overheads and security, both ends of certificate revocation (those who issue and those who fetch) are naturally tempted towards the former. Indeed, the very utility of revocations has been debated and doubted [citation omitted] by the security community, but to date, these debates have had to largely depend on anecdotal CA and browser behavior. “We have presented in this paper an empirical measurement of the options at all parties' disposal - website administrators, CAs, and browsers - in terms of the communication overhead costs they impose and the extent to which they are currently being employed. “Overall, our results show that, in today's Web's PKI, there is extensive inaction with respect to certificate revocation. While many certificates are revoked (over 8% of fresh certificates and almost 1% of alive certificates), many web browsers either fail to check certificate revocation information or soft-fail by accepting a certificate if revocation information is unavailable. “On the positive side, our results also demonstrate that there are several clear paths to improvement. To reduce CRL sizes, CAs can simply maintain more, smaller CRLs (in the extreme, each certificate could be assigned a unique CRL, resulting in an approximation of OCSP) - surprisingly few CAs currently take such an approach [citation omitted] and therefore incur greater bandwidth costs than strictly necessary. A promising improvement is OCSP Stapling, as it reduces CA bandwidth costs as well as web page load times - yet, not all browsers support it, and some that do simply ignore the responses. A more pervasive deployment of OCSP Stapling, at both websites and browsers, could lead to an immediate improvement in user security at little additional performance cost, particularly if the Multiple OCSP Staple Extension [citation omitted] were adopted to allow intermediate certificates to be stapled. Finally, we show that a straightforward modification to CRLSets could increase their coverage by several orders of magnitude. “From these results, we conclude that certificate revocation ought not be given up on - that indeed it serves a critical yet overlooked role that, with proper support from all parties, can be achieved at a cost far outweighed by the benefits. To realize this, we believe continued measurement and validation of future browsers will be of utmost importance, and to this end have made our data and our browser test suite publicly available at http://www.sslresearch.org.” [Emphasis supplied.] From: Ryan Sleevi [mailto:[email protected]] Sent: Friday, February 3, 2017 1:11 PM To: CA/Browser Forum Public Discussion List <[email protected]> Cc: Kirk Hall <[email protected]> Subject: Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates Kirk, While I understand you have a different view of how browsers should work, I think it might be more useful and productive to this discussion to acknowledge that browsers (and to the broader extent, relying parties) have disagreed your premise - and more generally, security practitioners outside of the Antivirus Industry (in particular) recognize your approach to security as flawed. However useful this discussion, though, it might be more useful if CAs could focus on specific reasons or challenges that the ballot would impose, particularly considering the (many) benefits I outlined in my reply to Doug. Concretely, I think there's an onus on CAs to show that these (considerable and meaningful) benefits are somehow overshadowed by the cost. To date, we've yet to see any evidence or counter-point that somehow users would be _less_ secure with the proposal. On Fri, Feb 3, 2017 at 12:07 PM, Kirk Hall via Public <[email protected]<mailto:[email protected]>> wrote: Richard, I’ve always thought that if revocation checking worked in (say) 85% of OCSP or CRL queries and revealed to users that a bad cert had been revoked and a site should not be trusted, then we (CAs and browsers) were successfully protecting 85% of users who were visiting the bad site. To me, that is a huge win. If we can work to improve that figure to 98% or 99.9% over time or with new methods, even better. But warning 85% of users of a revoked cert today is way better than warning 0% of users of a revoked cert as happens today when browsers don’t even bother checking for revocation. (It’s like a highway commission saying “This guardrail won’t prevent 100% of accidents, so we won’t put up a guardrail at all” – if the guardrail stops 99% of accidents, it’s a good thing.) If browsers always tell relying parties “Revocation checking doesn’t work”, then I guess that’s what relying parties will tend to believe over time – so no use asking what relying parties believe . But if revocation checking works in the great majority of cases where it’s tried, then it is a major tool for user security that should be restored by browsers. (And let’s not raise the issue “revocation checking can be blocked in a compromised environment, MITM, etc. so it’s never even worth trying in any environment” – that an extremely weak argument for giving up all revocation checking in the normal internet environment that the vast majority of users encounter, where revocation checking is not blocked and users can receive warnings of a revoked certificate.) From: Public [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Richard Barnes via Public Sent: Friday, February 3, 2017 11:41 AM To: CA/Browser Forum Public Discussion List <[email protected]<mailto:[email protected]>> Cc: Richard Barnes <[email protected]<mailto:[email protected]>> Subject: Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates Is there anyone on the relying party side of the universe that believes revocation works? Even among browsers that send OCSP requests, none of them hard-fail if it doesn't work, because in practice, OCSP servers are so awful that HTTPS would become unusable. So OCSP is still, as AGL says, a seat belt that breaks when you crash. Seems fair to call that broken. Even if OCSP were magically to become usable, though, (or some replacement for it) this ballot would still be necessary for all the other reasons that have been discussed here. On Fri, Feb 3, 2017 at 11:34 AM, Rich Smith via Public <[email protected]<mailto:[email protected]>> wrote: Ryan, since you're using your age old FUD "revocation doesn't work" (because certain browsers have chosen not to consult revocation information) as part of the reasoning as to why this ballot is necessary, I think it's quite germane to the discussion. On 2/3/2017 11:38 AM, Ryan Sleevi via Public wrote: On Fri, Feb 3, 2017 at 9:11 AM, Rob Stradling <[email protected]<mailto:[email protected]>> wrote: Ryan, what targets (filesize/performance/reliability/reachability/etc) would CAs need to meet before it would become viable to reintroduce CRLs to the WebPKI (i.e., for Chrome to start checking CRLs and hard-failing if they're unobtainable)? Happy to have that discussion at another time, but it's not germane to the discussion at hand, as I clearly indicated in the original message. It's necessary, but not sufficient, to have that, and we're not presently proposing addressing all the other necessary conditions. Baby steps. _______________________________________________ Public mailing list [email protected]<mailto:[email protected]> https://cabforum.org/mailman/listinfo/public _______________________________________________ Public mailing list [email protected]<mailto:[email protected]> https://cabforum.org/mailman/listinfo/public _______________________________________________ Public mailing list [email protected]<mailto:[email protected]> https://cabforum.org/mailman/listinfo/public
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
