[cabfpub] Short-Lived Certificate Ballot

Brian Smith brian at briansmith.org
Mon Nov 2 12:32:24 MST 2015


Robin Alden <robin at comodo.com> wrote:

> I think that the logic of his argument, like Adam Langley’s before him (
> https://www.imperialviolet.org/2011/03/18/revocation.html), is predicated
> on the belief that because boring old revocation[1] is not perfect it is
> therefore worthless and should be discarded.
>

This is a terrible mischaracterization of my argument. I encourage people
to read what I actually wrote, instead of relying on misleading summaries
of it.

Robin, I will point out the flaw in your reasoning.


> Whilst the short lifetime of the certificate may mean that a user who has
> already encountered the certificate and its associated OCSP response before
> the revocation event will have a cached ‘Valid’ (i.e. unrevoked) OCSP
> response for that certificate, a user who has not previously encountered
> the certificate will pick up a fresh OCSP response and will discover the
> certificate’s revocation.
>

No, this is not true. In order for the certificate to be useful for the
attacker, the attacker must have the private key for the certificate and
the attacker must be able to MitM the network connection.

Given those conditions, let's observe what happens when the user who has
not previously encountered the certificate tries to connect to the site, in
this case https://example.com.

*What happens when we use OCSP as the revocation mechanism?*

0. Beforehand, the attacker periodically polls the CA's OCSP responder,
getting the freshes OCSP response for the certificate that the CA provides.
At some point, the CA's OCSP responder will respond with a REVOKED
response. At that point, the attacker saves the newest GOOD response.

1. The user attempts to connect to https://example.com by starting the TLS
handshake with the server it thinks is example.com.

2. The attacker intercepts the connection, and completes the TLS handshake,
stapling the last GOOD response into the connection, using the (stolen)
private key of the certificate he is using for the attack.

3. The user's browser sees the stapled GOOD OCSP response and accepts the
certificate without attempting any other revocation checking.

According to the Baseline Requirements, this attack will work for 10 days
(see section 4.9.10: "OCSP responses from this service MUST have a maximum
expiration time of ten days.").

*What happens when short lived certificates are used, without any CRL DP
extension in the certificate?:*

1. The user attempts to connect to https://example.com by starting the TLS
handshake with the server it thinks is example.com.

2. The attacker intercepts the connection, and completes the TLS handshake,
stapling the last GOOD response into the connection, using the (stolen)
private key of the certificate he is using for the attack.

3. The user's browser sees that the certificate doesn't have any OCSP or
CRL URL, and so accepts the certificate as not revoked.

The attack will work for 3 days, because the proposed short-lived
certificates ballot says that the certificate must have a notAfter date no
longer than 3 days after the issuance date.

Thus, by the CABForum's own standards, OCSP permits attacks to work for 7
days longer than if short-lived certificates were in use. Thus, short-lived
certificates would be a more effective revocation mechanism.

*What happens when we add the CRL DP extension to the short-lived
certificate in Firefox, Chrome, and Opera (assuming Opera is the same as
Chrome)?:*

1. The user attempts to connect to https://example.com by starting the TLS
handshake with the server it thinks is example.com.

2. The attacker intercepts the connection, and completes the TLS handshake,
stapling the last GOOD response into the connection, using the (stolen)
private key of the certificate he is using for the attack.

3. The user's browser sees that the certificate doesn't have any OCSP URL,
and so accepts the certificate as not revoked.

This is exactly the same as if the CRL DP extension were not present.

*How, what happens in a browser (maybe Microsoft's?) that actually supports
the CRL DP extension?*

1. The user attempts to connect to https://example.com by starting the TLS
handshake with the server it thinks is example.com.

2. The attacker intercepts the connection, and completes the TLS handshake,
stapling the last GOOD response into the connection, using the (stolen)
private key of the certificate he is using for the attack.

3. The user's browser sees that the certificate doesn't have any OCSP URL,
and so attempts to download the CRL.

4. The attacker blocks the CRL download.

5. The user's browser gives up trying to check the certificate for
revocation, and accepts the certificate.

This is exactly the same as if the CRL DP extension were not present.

*What happens in the case where a short-lived certificate is used, and the
browser insists on having an OCSP response (Must-Staple or OCSP "hard fail"
mode)?*

0. Beforehand, the attacker periodically polls the CA's OCSP responder,
getting the freshes OCSP response for the certificate that the CA provides.
At some point, the CA's OCSP responder will respond with a REVOKED
response. At that point, the attacker saves the newest GOOD response.

1. The user attempts to connect to https://example.com by starting the TLS
handshake with the server it thinks is example.com.

2. The attacker intercepts the connection, and completes the TLS handshake,
stapling the last GOOD response into the connection, using the (stolen)
private key of the certificate he is using for the attack.

3. The user's browser sees the stapled GOOD OCSP response and accepts the
certificate without attempting any other revocation checking.

According to the Baseline Requirements, this attack will work for 3 days,
because the short-lived certificate must expire within 72 hours of the
issuance date, according to the proposal. OCSP does not shorten the
duration of the attack window because the baseline requirements allow the
use of an OCSP response that is up to 10 days old (see section 4.9.10:
"OCSP responses from this service MUST have a maximum expiration time of
ten days.").

*Conclusion*

Requiring the CRL DP extension and/or the AIA extension with an OCSP
responder URL to be present in the end-entity certificate does not have any
significant advantage, but it does have a significant disadvantage in that
it makes the certificates larger and thus less efficient to use in TLS.

More below.


> > There In fact, because the maximum validity period of a
>
> > short-lived certificate is shorter than the maximum lifetime
>
> > of an OCSP response, short-lived certificates are actually
>
> > a *safer* form of revocation than a stapled OCSP response.
>
> No, it isn’t.
>
> Firstly, they are not alternatives.  We are not considering the
> alternatives of a short lived certificate (exclusive) OR an OCSP response.
>

The main goal of short-lived certificates is for them to be an alternative
to OCSP and CRLs. In any case, as you can see above,



> We are considering, given the premise of the ballot which is to have short
> lived certificates, whether there should also be an associated revocation
> status (OCSP or CRL).
>
> The short lifetime of the certificate, of course, limits the damage than
> can be done with it, but that damage can be limited further by its
> association with the existing revocation mechanisms.
>

No. See the analysis above.


>  > Note that a CA isn't required to include the AIA OCSP
>
> > responder URL in a certificate if the customer promises
>
> > to always staple an OCSP response.
>
> True, and although the BRs do permit what you describe that language in
> the BRs needs revising or removing.
>
> It should only be permitted with must-staple (rfc7633). The high-traffic
> case it considers should have additional security considerations if the
> revocation pointer is to be absent.
>

No. See the analysis above.


> > A short-lived certificate is a way of enforcing that the
>
> > customer keep that promise.
>
> No, it isn’t.  Using must-staple (rfc7633) is a way of enforcing that the
> customer keep that promise.
>

Both are ways of enforcing the customer keep that promise. Short-lived
certificates do a better job because a stale short-lived certificate cannot
be used as long as a staled OCSP response. See the analaysis above.


> > Also note that it is critically important that certificate
>
> > chains get smaller due to the nature of the TCP and TLS
>
> > protocols, especially when combined with CT, which makes
>
> > them significantly larger.
>
> CT in certificate bodies is not the only fruit.  CT does not require
> certificate bloat – although presumably getting the SCT in a TLS extension
> doesn’t reduce the bytes over the wire any.
>

Right. One way or another, the server has to send the CT info in the TLS
extension, which means that CT, no matter how the info is delivered, puts
additional pressure on us to keep certificate chains small.

But I smell the old point about initcwnd.  What % of deployed servers can't
> (and/or don't?) set the initcwnd?
>

Increasing the initcwnd works often, for servers that do it. There are a
lot of scenerios where it doesn't work even in an all-TCP scenerio. In the
case of Internet of Things applications, TCP (initcwnd) isn't the only
limiting factor.

> One of the main purposes of OCSP
>
> > stapling is to help make the certificate-related parts of
>
> > the TLS handshake more efficient in this respect, and the
>
> > requirement for adding the CRL DP extension, which is
>
> > relatively large, is counterproductive to this primary
>
> > purpose.
>
> Really?  I thought the main purposes of OCSP stapling <snip>
>

Sorry, I meant "one of the main purposes of short-lived certificates", not
OCSP stapling.

> If people want this in order to support CRLSets/OneCRL/etc.
>
> > then it would be better to find an efficient out-of-band
>
> > method for advertising the CRL URLs to support those out-
>
> > of-band revocation methods.
>
> Finally we’re starting to reach something we might agree on.  When there’s
> a better way to get revocation status information out there then let’s use
> it, but let’s not throw the existing mechanisms away until there is a
> superior replacement for them.
>

This ballot proposes exactly that: short-lived certificates.

Cheers,
Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151102/438893d8/attachment-0001.html 


More information about the Public mailing list