[cabfpub] Changes to improve OCSP interoperability, security, and usability

[Rob Stradling]

Hi Brian.  Comments inline...

On 23/10/13 04:45, Brian Smith wrote:
<snip>
> 1. The nextUpdate field must be present in all OCSP responses. Some
> CAs are omitting the nextUpdate field and this seems to cause
> interoperability issues and perhaps performance issues. Basically, the
> server has to guess when clients will consider the OCSP response to be
> stale if nextUpdate is omitted, and some servers seem to guess badly.
> Note that RFC 5019 Section 4 already requires that nextUpdate be
> provided in OCSP responses [1]: "If the nextUpdate field is absent,
> the client MUST reject the response." Because some CAs are
> non-conformant here, browsers must also be non-conformant. RFC 5019
> conformance has been one of the biggest things that people have
> requested from Firefox. We should make RFC 5019 conformance a
> requirement in the baseline requirements. Currently, the baseline
> requirements say "OCSP responses MUST conform to RFC2560 and/or
> RFC5019." The "and/or" should be replaced with "and." The baseline
> requirements further say that "OCSP responses from this service MUST
> have a maximum expiration time of ten days." The only way a CA can
> conform to this requirement is by including an explicit nextUpdate.

Funnily enough I was looking at this issue just yesterday, having 
noticed that GlobalSign's OCSP Responses omit "nextUpdate".

RFC2560 says...
   "- nextUpdate: The time at or before which newer information will be
                  available about the status of the certificate"
...and...
   "If nextUpdate is not set, the responder is indicating that newer
    revocation information is available all the time."

I interpret this to mean that when "nextUpdate" is omitted, the OCSP 
Response expires instantly (and "instantly" is obviously well within the 
"maximum expiration time of ten days"!)

> Thus, nextUpdate is already required in the baseline requirements, but
> it isn't clear. We should make it more clear.

RFC2560 allows "nextUpdate" to be omitted, and the BRs allow CAs to 
adhere to RFC2560 only.  Therefore, "nextUpdate" is _not_ already 
required by the BRs.

But what actually matters is client behaviour, and as you point out, 
RFC5019 says "If the nextUpdate field is absent, the client MUST reject 
the response".
(@RyanHurst: Do you plan to implement your own RFC? ;-) )

I fully agree that this section of the BRs needs some edits and 
clarification.

> 2. RE: "OCSP responses from this service MUST have a maximum
> expiration time of ten days." This requirement is too lax for OCSP
> stapling. A successful attacker is guaranteed to control the network
> between the client and the web server, and he can choose to staple
> whichever valid (non-expired) OCSP response he wants.

By "control the network", I think you're suggesting that the attacker 
can intercept and change bits on-the-wire, without detection by the 
client.  I don't think that's true here.  Wouldn't substituting a 
different Stapled OCSP Response cause the client to terminate the 
handshake with a bad_record_mac error?

If the attacker has hacked into the webserver (or if the webserver 
operator is the attacker!), then the attacker can choose which OCSP 
Response to staple.  Or they can disable OCSP Stapling altogether.

> However, a
> successful attacker isn't necessarily guaranteed to control the
> network between the client and the OCSP responder. In the case where
> the attacker doesn't control the client <-> OCSP responder path, but
> where he does control the client <-> web server path, OCSP stapling
> makes the attacker more powerful.

In the client <-> OCSP responder path, HTTP tends to be used, so an 
active attacker _can_ substitute a different OCSP Response without 
detection.

So, if I'm right about bad_record_mac above, doesn't that mean that OCSP 
stapling makes an attacker controlling the client <-> webserver path 
_less_ powerful?

> To mitigate this, we should make the
> valid expiration time of OCSP responses shorter. I recommend that we
> change the above text to "OCSP responses from this service MUST have a
> nextUpdate field which is no more than 48 hours from the thisUpdate
> field." 48 hours is a very long time to allow any attack to succeed,
> but ten days is definitely an eternity, especially considering this
> negative security aspect of OCSP stapling.

I agree that 10 days is far too long!

> 3. Recently, the baseline requirements were changed to mandate that an
> OCSP responder must not return "Good" for an unknown certificate. Many
> CAs changed their OCSP responders to return "Unknown" for unknown
> certificates, and that is great. However, there was an unintended
> negative consequence. Apparently, some CAs also now return "Unknown"
> as soon as a certificate expires. Some clients, e.g. Firefox, allow
> users to override "expired certificate" errors but not "OCSP responder
> says 'Unknown'" errors. If the OCSP responder returns "Unknown"
> automatically as soon as a certificate expires, then users won't be
> able to override the "expired" error like they could before. Returning
> "Unknown" for an expired certificate is totally reasonable. However, I
> think it seems reasonable to be a little bit more relaxed about that
> so that browsers don't get forced into allowing "Unknown" to be
> overridden all the time. I would like "Unknown" to be(come) equivalent
> to "mis-issued" so avoiding user overrides of "Unknown" errors seems
> like a good idea to me. Note that some of our academic friends have
> showed us some evidence that the vast majority of expired certificates
> get replaced within 14 days, so having OCSP responders return "Good"
> for expired certificates for a day or a few days seems pretty
> reasonable. Suggestions?

We use the unsigned "unauthorized" response for expired certs, as 
permitted by RFC5019:
   'Requests from clients for
    certificates whose record has been removed will result in an
    OCSPResponseStatus of "unauthorized".'

<snip>
> 6. For must-staple in particular, it may be worthwhile to consider
> adding a backup OCSP AIA URI to certificates, that is used in case the
> normal OCSP responder is not working. Then we could change servers'
> OCSP stapling implementations to try each of the URIs in order. This
> would likely improve the availability of sites that use must-staple in
> the event that a CA's CDN experiences downtime.

Are you suggesting that a backup OCSP AIA URI should be required or 
optional-but-recommended ?

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online