[cabfpub] Ballot 153 - Short-Lived Certificates

kirk_hall at trendmicro.com kirk_hall at trendmicro.com
Mon Nov 2 11:04:46 MST 2015


I'm puzzled by one argument of the proponents of Short-Lived Certificates (SLCs) with no OCSP revocation checking.

They note that the Short-Lived Certificates have a validity period of 4 days, and that OCSP responses must be updated at least every 4 days under BR 4.9.10 (but are good for up to 10 days).  Because a Short-Lived Certificate will expire in the same time as the maximum update period for OCSP responses, then then make the logical leap that SLCs with no OCSP pointers are "just as good" as SLCs with OCSP pointers because [somehow] the SLCs with no OCSP revocation information will all expire before some users will ever learn they were revoked.

It's true that visitors to websites secured by a SLC who receive a "good" OCSP response, and who then return to the website before its revoked SLC expires, probably will not any receive updated revocation information because the first OCSP response is cached.  But that's the *only* case where the two SLCs (one with an OCSP pointer, and one with no OCSP pointer) are roughly the same from a user security standpoint.  And that's probably a very small minority of users who visit a site secured by an SLC over its 4 day validity period.  The other users who visit the site after revocation over the same period would all benefit from OCSP revocation information.

Suppose a website secured by an SLC is visited by 1,000 unique users per hour (not counting any repeat visits by any user - so leaving out the effect of a cached OCSP response) - that's 96,000 visitors over the SLC's validity period.  Now suppose the SLC is revoked 6 hours after issuance due to key compromise or phishing.  If the SLC has an AIA OCSP pointer, then OCSP revocation checking will occur for the 90,000 unique users who visit the website during the 90 hours after the SLC was revoked, and those 90,000 users have a very good chance of receiving an OCSP revocation warning from the browser - that's good user security.

In contrast, if the SLC contains no AIA OCSP pointer and the 96-hour SLC is revoked after 6 hours, then *none* of those 90,000 users who visit the website after revocation have any chance of receiving an OCSP revocation warning.  That's very bad user security.

It's true that some OCSP queries are blocked or users receive no response - but that doesn't mean it's not work checking for revocation of a certificate via OCSP.  Suppose as many as 10% of OCSP queries don't receive a response - that's still 90% that do, which would protect 81,000 of the 90,000 users in the example above.  Without any revocation checking at all, those users are sitting ducks.

Some have suggested the Short-Lived Certificates will only be used for 24 hours on a website, then be changed out (although there is nothing to prevent the website owner from using the SLC for the full 96 hours of its validity period).  OK, so in that case only 18,000 unique users would visit the site with a revoked cert for the 18 hours after revocation without being warned that the certificate was revoked - that's 18,000 users who get no OCSP warning, again bad user security.

To address this problem, the proponents of Ballot 153 have suggested that including a CDP pointing to a CRL is just as good as an AIA OCSP pointer for revocation checking.  But that's not true at all - as my prior email noted, most CAs use only one issuing sub-CA, and it only publishes one CRL covering all issued certificates.  That one CRL can be valid (and will be cached by each user once received) for up to 10 days before it must be refreshed by the user.  And that one CRL covers *all* Short-Lived Certificates and all other certificates issued by that CA to all FQDNs for all customers around the world - potentially millions of websites.

So if a user visits Site A on Monday and downloads and caches the current CRL, that stale CRL will effectively block the user from ever receiving any additional revocation information about *any* other certificate, including SLCs, issued by the same CA for the next 10 days.  Again, bad user security.

After downloading the CRL on Monday, if the same user then visits Site B secured by a SLC from the same CA on Wednesday, and the site's SLC was revoked on Tuesday, the user's client will only check the [stale] cached CRL received on Monday - there will be no new revocation information listed on that stale CRL after Monday about the revocation of the Short-Lived Certificate on Site B on Tuesday.  Clearly, a CRL is no substitute for a fresh OCSP response for each certificate with a unique serial number.

This problem will only be exacerbated if the world moves to massive numbers of Short-Lived Certificates issued to massive numbers of FQDNs and websites around the world as part of the https-only push - in effect, all websites secured by SLCs from a single CA will be linked from a security standpoint, and users who access that CA's CRL will only receive fresh revocation information about *all* the CA's secured websites once every 10 days.  That's not good enough.  (Remember, most fraud, phishing, and look-alike sites do most of their harm in the first 48 hours after installing their certificate, so SLCs from major CAs with CRLs only will likely be very popular with them.)

The recent academic study "An End-to-End Measurement of Certificate Revocation in the Web's PKI," http://www.cs.umd.edu/~dml/papers/revocations_imc15.pdf, notes in the summary to Section 9 that "over 8% of fresh certificates and almost 1% of alive certificates" are revoked - that's a lot of revoked certificates out there that pose a threat to user safety.

So no, the fact that Short-Lived Certificates have a maximum validity period of 4 days, and the fact that OCSP responses must be updated at least every 4 days, does not mean that a SLC with *no* AIA OCSP  pointer is as good as a SLC *with* an AIA OCSP pointer from a user security standpoint - not true at all.  The only thing the two standards have in common are the words "4 days."

There is rough security equivalence *only* for users who have visited a site and received a "good" OCSP response, and then re-visit the same site after revocation but during the same SLC's validity period - but this has to be a very small percent of users.

All certificates should include AIA OCSP pointers, including Short-Lived Certificates, to protect users.  Some browsers may choose not to bother with revocation checking for SLCs, but others will and will protect their users.  Any CA that issues Short-Lived Certificates without AIA OCSP pointer is putting users at risk unnecessarily.

Let's not go backward on the revocation security improvements the Forum has made over the past four years.  In fact, we should start ratcheting down on the maximum validity period for current OCSP responses, from 4 days to maybe 2 days, for greater user security.  We can help solve the OCSP response infrastructure problems of both browsers and CAs by aggressively promoting stapling and working with server makers to turn on stapling by default - that's the right way to proceed.



<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: https://cabforum.org/pipermail/public/attachments/20151102/e695984e/attachment.html 


More information about the Public mailing list