[cabfpub] OCSP Stapling and Short-Lived Certificates Proposal

Rick Andrews Rick_Andrews at symantec.com
Sat Mar 23 00:38:29 UTC 2013


I'm very much in agreement with Eddy on this.

Consider this: If I take the basic argument that you don't need to check revocation on a short lived cert (say, valid for 7 days) because the CA's OCSP responses are also good for 7 days, then I would claim that when SSL clients (browsers) see a long-lived SSL certificate, they can skip revocation checking if the cert is less than 7 days old. I certainly wouldn't want browsers to do that.

-Rick

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi
Sent: Friday, March 22, 2013 3:58 PM
To: ben at digicert.com
Cc: CABFPub
Subject: Re: [cabfpub] OCSP Stapling and Short-Lived Certificates Proposal

Ben's repostings have unfortunately missed quite a bit of context from my reply - in particular, the explanation of why the security considerations are identical, but the performance characteristics not.

I've reproduced the fully reply below, in response to Rich Smith's remarks previously posted.


1) What possible advantage is there to either the CA or to the end user for issuing a certificate w/out revocation information?

[RS] Every byte is critical during the critical SSL/TLS handshake - especially with the small INITCWNDs that exist today. CAs SHOULD be able to offer as small a cert as possible that provides the same security guarantees - performance matters, and if CAs wish to sell more certificates, the best way to do so is to help customers realize savings that puts the cost of SSL on par - or LESS than - unencrypted traffic.

My colleague Adam Langley has written extensively on this topic, but if you're not familiar with the concerns that site operators and client software faces, you may find http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html helpful.


2) CAs issue signed Good OCSP responses with signatures good beyond 24 hours because it is technically onerous to try to sign a new Good response for EVERY cert we have live every 24 hours.  I don't see that translating into a statement by the CA to the client software that you SHOULD CACHE that response for more than 24 hours.  If we sign a Good response today that has a signature that's good for 7 days, then revoke the cert tomorrow, we are going to replace the response given by our OCSP server tomorrow, not next week.  It's the caching of the response for what I consider to be an excessive amount of time that's the problem, not the OCSP response itself.
[RS] If we think purely in terms of what security is gained, then we must accept that an attacker has the full ability to replay that OCSP response for the duration of it's signature validity - eg: 7 days. The fact that the CA has issued a new response provides no guarantees that clients will actually be able to see or observe that response.

I realize past objections have been raised suggesting that such a replay requires a privileged position on the network - but in light of OCSP stapling, this is hardly the case - the attacker's server can continue to replay the valid message, and the vast majority of clients that now support OCSP stapling will happily accept it.

This operates *independent* of any client caching behaviour.

To actually mitigate such an attack, clients would have to explicitly ignore the CA's validity periods - effectively requiring every CA to issue new OCSP responses every 24 hours (as the period you suggested).

If you wish to see actual security benefits from the proposed client behaviour changes, you would first need to propose a ballot that requires every CA provide fresh OCSP responses every 24 hours. I'm certain such a ballot would fail - because the Web PKI is diverse enough that such a proposal is simply not workable, hence the 7/10 days time frame.


3) I still fail to see how revocation information in the cert prevents or hinders short lived certs in ANY way.  If the client sees a cert that is only good for 7 days and decides NOT to check revocation, that is the decision of the client software vendor and has nothing to do with the CA.
[RS] Performance.

We should not normatively require something in the certificate profile that provides no actual or effective security benefits. Such a solution unnecessarily hinders innovation and slows SSL adoption - something I'm sure no member here wishes to be associated with.


On Fri, Mar 22, 2013 at 2:12 PM, Ben Wilson <ben at digicert.com<mailto:ben at digicert.com>> wrote:
Eddy wrote:

On 03/22/2013 09:48 PM, From Ryan Sleevi:
Every byte is critical during the critical SSL/TLS handshake

As for me, security can't be traded for speed - no matter what - and personally I don't care a bit (nor byte). My task isn't to make the Internet faster (of course I love if it does), but whenever possible more secure. What we are discussing has been in place as a basic and in my opinion minimum mechanism to indicate a certificate's status.

If speed is an issue lets work on making revocation check both faster and more reliable by enabling hard fail.
Regards



Signer:

Eddy Nigg, COO/CTO




Eddy also wrote:

On 03/22/2013 09:47 PM, From Jeremy Rowley:
Why?  What risks do short lived certificates provide over other types of certificates.

First of all I don't believe that there can be a robust mechanism to issue certificates with such a frequency where the CA does its pre and post issuance diligence. I'd consider such issuance more risky than a controlled and supervised manner (assuming that CAs did implement some due diligence for issuing certificates in the post Diginotar aera). This is my main objection and critical in my opinion.

Second, for an attacker 3 - 7 days is a long time to achieve their goals most of the time, by repeating same attack which would go undetected due to the above mentioned missing diligence, this could go on for a while.

Third, most software (browsers and other clients) check revocation usually on a higher frequency then possible nextUpdate fields in OCSP and CRLs, specially when relying on OCSP. Removing revocation status DPs will allow an attacker to complete his attack happily even if the CA has become aware of it. Software updates wouldn't be fast enough either.

Forth, browsers don't check revocation status all at the same time, making attacks more difficult when revocation status DPs are defined (system restarts, first access, access after 24 hours depending on software trigger a revocation status check). This will make an attack less reliable and also detectable by the client (if configured correctly).
Regards



Signer:

Eddy Nigg, COO/CTO


Jeremy wrote:
I've stated the benefits of short lived certs in the past.  Here they are again for completeness:
1)      What possible advantage is there to either the CA or to the end user for issuing a certificate w/out revocation information?
[JR} We have several business cases for these types of certs.  For example, these certs are ideal for servers in less stable environments where they don't trust the reliability of the Internet.  I do not think the BRs should restrict a practice simply because some of the participants don't see the practice as  part of their business.  The question should never be about whether there is an opportunity of a particular CA, since that would require divulgence of the CA's trade secrets.  The question should only be about whether these constitute a security risk.  Restricting business practices without a valid security or trust concern only serves to stifle innovation.
2)      CAs issue signed Good OCSP responses with signatures good beyond 24 hours because it is technically onerous to try to sign a new Good response for EVERY cert we have live every 24 hours.  I don't see that translating into a statement by the CA to the client software that you SHOULD CACHE that response for more than 24 hours.  If we sign a Good response today that has a signature that's good for 7 days, then revoke the cert tomorrow, we are going to replace the response given by our OCSP server tomorrow, not next week.  It's the caching of the response for what I consider to be an excessive amount of time that's the problem, not the OCSP response itself.
[JR] Translates to the same thing.  A revocation response is only updated every seven days under the BRs.  Therefore, short lived certificates have the same reliability as a regular certificate.  Both are only revoked at the end of the 7 day cycle.  If you want to talk about shorting the period specified under the BRs, then I would accept that and similarly modify my proposal.  The BRs are a minimum.  The minimum selected was seven days.  Therefore, a short lived cert that imposes the same minimum level of revocation is equally as valid.
3)      I still fail to see how revocation information in the cert prevents or hinders short lived certs in ANY way.  If the client sees a cert that is only good for 7 days and decides NOT to check revocation, that is the decision of the client software vendor and has nothing to do with the CA.
[JR] It does. As mentioned, short lived certs are ideal for places without a reliable internet.  Traditional revocation checking always times out in these cases.  Requiring inclusion of useless information does nothing but slow the entire processes.  As mentioned, since the certificates are only good for 7 days, there isn't a good reason to include the AIA extension.
Just to reiterate my position, I am absolutely against changing the guidelines to allow issuing any end entity certificate without revocation information.  We've talked around this subject for months and no one has yet brought forth any convincing argument why it is necessary or desirable either from the point of view of the CA or the end user.
[JR] I've presented many arguments why we should permit short lived certs but haven't yet heard a compelling argument why they shouldn't be permitted. The only argument seems to be that it gives CAs who plan to use them a new market to capture.  I've given you lots of why there isn't a security risk. I've also given a lot of reasons why they should be permitted.  I don't really care if other CAs plan to issue these certs. What I care about is the use of BRs to try and prevent a CA from entering different business opportunities.
Jeremy


From: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org<mailto:public-bounces at cabforum.org>] On Behalf Of Ben Wilson
Sent: Friday, March 22, 2013 2:59 PM
To: public at cabforum.org<mailto:public at cabforum.org>
Subject: Re: [cabfpub] OCSP Stapling and Short-Lived Certificates Proposal

Also, Jeremy reminds me that he has a few tweaks to make, including adjusting the proposed validity window of a short-lived certificate (to accommodate potential clock skew on client machines).

From: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Friday, March 22, 2013 2:55 PM
To: public at cabforum.org<mailto:public at cabforum.org>
Subject: [cabfpub] OCSP Stapling and Short-Lived Certificates Proposal

Moving this pre-proposal to the public list for more discussion.

From: management-bounces at cabforum.org<mailto:management-bounces at cabforum.org> [mailto:management-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Wednesday, March 20, 2013 4:08 PM
To: CABFMAN
Subject: [cabfman] OCSP Stapling and Short-Lived Certificates

All,

Before moving this toward a ballot, attached are a few redlined pages of the Baseline Requirements to address OCSP stapling and short-lived certificates.    After you've had the chance to look at them, please review some of the reasoning below that is in support of the proposed changes.

As background, the language being modified was originally intended to address the omission of the AIA for OCSP if the CA and the customer properly configured retrieval of OCSP responses in a must-staple scenario.  However, since then our Forum discussions have revealed that the server software handles stapling best by pulling the OCSP server address from the certificate (manual configuration errors are more likely to occur if the certificates do not contain an AIA pointer to the OCSP Server).

Section 13.2.1

1.       The Baseline requirements should not imply that OCSP stapling is restricted to high-traffic sites.  Also, we think that defining "high-traffic" is problematic.

2.       A customer is not required to always staple.  It's not the sine qua non, and as mentioned above, CAs won't have as much control here as the current language seems to imply.

3.       If the customer requests the MustStaple OID because it is confident enough in its capabilities to provide stapling consistently, then we should make that available - but the mustStaple identifier should not be required or prohibited.  So this language should be a "MAY."   The existing language only partially explains what the MustStaple OID can be used for (i.e. it's a step toward preventing a downgrade attack when OCSP response are being blocked), but again, the suggested revision does not require anything unless the CA includes the OID in the certificate at the request of the customer.  We're welcome to suggestions on how to word this better.

Appendix B Section (2)C - Subordinate CA Certificate
"With the exception of stapling" should be deleted because it neglects the need for the AIA for OCSP, as discussed above.   (The language in the last paragraph is also an incorrect description of the Sub CA's AIA contents.)

Appendix B Section (3)C. - Subscriber Certificate
Again, deleting exception for AIA for OCSP stapling, but replacing it with exception for short-lived certificates ("certificates with validity periods of 168 hours or less").  It has been argued that this type of short-lived certificate presents the same risk profile as certificates supported by CRLs and OCSP responses, which are valid and cached for a week to 10 days.  Because at least some form of testing should be allowed, and the Baseline Requirements should only set a floor and not prohibit innovative solutions, short-lived certificates without revocation information should not be prohibited.

Thanks,

Ben

_______________________________________________
Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130322/9a47545c/attachment-0003.html>


More information about the Public mailing list