[cabfpub] OCSP Stapling and Short-Lived Certificates Proposal

[Ryan Sleevi]

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> 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] *On
> Behalf Of *Ben Wilson
> *Sent:* Friday, March 22, 2013 2:59 PM
> *To:* 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<public-bounces at cabforum.org>]
> *On Behalf Of *Ben Wilson
> *Sent:* Friday, March 22, 2013 2:55 PM
> *To:* 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 <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
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20130322/55cff763/attachment-0001.html