[cabfpub] Ballot 153 - Short-Lived Certificates

Brian Smith brian at briansmith.org
Mon Nov 2 23:32:03 UTC 2015


kirk_hall at trendmicro.com <kirk_hall at trendmicro.com> wrote:

> They note that the Short-Lived Certificates have a validity period of 4
> days,
>

3 days from issuance. notAfter - notBefore may be 4 days so that a CA can
back-date the certificate by up to one day, to account for clock skew.


> and that OCSP responses must be updated at least every 4 days under BR
>

This detail is not relevant to the security analysis. Even if the CA
produces a new REVOKED response before the last GOOD response expires, the
attacker can just staple the last GOOD response.


> 4.9.10 (but are good for up to 10 days).
>

Right. This 10 day validity period for OCSP responses is the thing that
matters.


> 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 isn't a "logical leap". If somebody is actually MitMing a user and know
the certificate's private key, then they can successfully staple the last
GOOD OCSP response until that OCSP response expires. If there is no MitM
attacker or the MitM doesn't know the certificate's private key then it
doesn't matter whether the certificate is revoked or not because the user
and server aren't being attacked.



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

That is only the case in the situation where there is no MitM attacker.
But, again, when there is no MitM attacker, it doesn't matter whether the
browser notices that the certificate has been revoked or not, as far as the
security of the user/site is concerned. I believe the rest of your email is
also only considering the case where there is no MitM attacker.

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

I think this is overlooking the fact that the attacker can always staple
the last GOOD OCSP response, in order to prevent the browser from ever
trying to fetch the OCSP response at all.


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

To be clear, I also disagree with the people that think it is useful/good
to include a CDP in short-lived certificates.


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

This, and many other reasons, are why CRLs are a poor choice in general.

Plus, browsers aren't required to download CRLs even when there is no way
for it to do OCSP, and many users' browsers don't do CRLs (or even OCSP) at
all.

Let’s not go backward on the revocation security improvements the Forum has
> made over the past four years.
>

I understand that it seems counter-intuitive that a short-lived certificate
without an AIA OCSP pointer or a CRL DP extension could be more secure than
a normal (not short-lived) certificate with an AIA OCSP pointer or a CRL DP
extension. However, please read the analysis I provided in the other
thread, where I showed that the counter-intuitive result is correct.


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

 Again, the problem with OCSP isn't the "must update every 4 days"
requirement for OCSP. The problem with OCSP is that OCSP responses are
allowed to be valid for up to 10 days. I agree with your sentiment that
OCSP should be improved. I've often advocated reducing the maximum validity
period of OCSP responses to be the same as what is being proposed for
short-lived certificates (notBefore >= 1 day before issuance, notAfter <= 3
days after issuance).

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

Besides doing those things, there are two other things that would be
required:

1. Servers and clients must implement Must-Staple.
2. As noted above, the maximum validity period of OCSP responses must be
reduced to the same as the proposed maximum validity period of short-lived
certificates.

Then OCSP would work pretty good. However, there still would be a strong
demand for short-lived certificates without OCSP or CRL checking, because
short-lived certificates are a significantly more efficient encoding of the
same information as a certificate + stapled OCSP response + Must-Staple
extension or CRL DP extension or AIA OCSP pointer.

Cheers,
Brian
-- 
https://briansmith.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151102/ed901bbc/attachment-0003.html>


More information about the Public mailing list