[cabfpub] Ballot 153 – Short-Lived Certificates

[kirk_hall at trendmicro.com]

I was happy to see the link to the academic study “An End-to-End Measurement of Certificate Revocation in the Web’s PKI” in Ryan’s response – this is a very impressive study of revocation checking issues by nine academic members of four highly respected universities (Northeastern, Univ. of Maryland, Duke/Akamai Tech., and Stanford).  Their findings should not be ignored or minimized.
Here is the link again:
http://www.cs.umd.edu/~dml/papers/revocations_imc15.pdf

Sections 6 and 7 of the study show the disappointing results of current browser revocation checking efforts, which need to be improved.

More important, this academic study reached the important conclusions pasted in below (emphasis in original, footnotes omitted), which we fully agree with, especially as summarized in the final paragraph: “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.”

This is a real call to action for Forum members not to eliminate current OCSP revocation checking requirements in the BRs, and to reject Ballot 153.


Here are the Summaries of findings for the last three sections of the academic paper – these are worth reading:


6.5 Summary [Client Behavior]

If clients do not fetch and respect revocation information, the revocation efforts of website administrators and CAs are wasted. To analyze client behavior, this section presented our test suite, and the results from all major desktop and mobile browsers. While we see widely disparate behavior - often even among the same browser on different – platforms - we find that no browser meets all necessary criteria for revocation checking. Moreover, we empirically demonstrate the extent to which EV certificates are validated differently. Perhaps most concerning is the fact that no mobile browsers check for revocations at all.

For desktop browsers, it is difficult to determine whether the absence of revocation checking is an explicit design decision or a set of common bugs. For mobile browsers, on the other hand, we believe the complete lack of revocation checking is an explicit decision to conserve users' bandwidth.

7.5 Summary [CRL Sets]

To summarize, we find that CRLSets have limited coverage, their coverage of revoked certificates is diminishing over time, they are updated frequently but experience outages, and they leave browsers vulnerable to unexpired revoked certificates. While the CRLSet approach has a number of benefits to users, it is clear that the developers have chosen to provide security only for a small fraction of sites in order to decrease the amount of bandwidth required to disseminate revocation information; this leaves the vast majority of popular sites uncovered.

9. 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 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 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 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.


<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151030/1d00dff0/attachment-0003.html>