Subject: RE: OCSP response pre-production

From: David Engberg <[email-masked]>
Date: Wed, 01 Oct 2003 18:10:33 -0400

I agree with the general idea of having an unambiguous way for a 
responder to indicate that it will not provide nonces in responses.  I 
think it may be unnecessarily restrictive to say that every client must 
automatically reject a response without a nonce, but that would not 
directly impact our software either way.

I would prefer a signalling mechanism that does not require two 
round-trip communications to establish nonce support, and that does not 
add any significant size to the body of pre-generated responses to 
indicate that they don't have nonces in them (which is evident).

Michael's initial proposal (below) could work, but has the two issues of 
requiring two round-trips for negotiation and returning the 
"unsupported" message in the unsigned portion of the body rather than in 
the signed body.  I also would prefer to remove the last sentence of the 
semantics or at least tone it down as unnecessarily focused on one 
hypothetical risk above all others (e.g. remote server key compromise).

 > SYNTAX:     Expand v1 OCSPResponseStatus syntax to
 >             include (7) noncesNotAccepted.
 >
 >
 > SEMANTICS:  Responders SHOULD respond back with the
 >             requestor's nonce but if can't then SHALL
 >             respond with an error message of the value
 >             noncesNotAccepted.
 >
 >             Requestors SHALL reject signed responses
 >             that fail to incorporate a supplied nonce.
 >
 >             Upon receipt of noncesNotRequired, requestors
 >             MAY retry the request without using a nonce.
 >             Requestors are STRONGLY ADVISED that doing
 >             so MAY subject them to additional risk.

As an alternative, pre-generated responses could include a flag or 
extension in their signed body to indicate that not only are they not 
supplying a nonce with this response, but that they don't supply nonces 
with any response, and if you trust that responder (via its public key 
cert), then you may choose to accept the non-nonce-bearing response from 
that server with this explicit flag (if that is your policy).

This avoids the risk of someone replaying a response to you in which the 
attacker chose not to supply a nonce, but you did.  It allows a client 
to distinguish between a server saying "Here's a response without a 
nonce because you I think you didn't ask for one" and "Here's a response 
without a nonce because the responder for you or your CA does not use 
nonces."

I believe the following is a valid security policy which some (most?) 
clients may choose to implement as an option:

   - Send a nonce with every request
   - Accept a response with a matching nonce from any trusted responder
   - Accept a response with a nonceUnsupported extension from any
       trusted responder
   - Reject a response with no nonce and no nonceUnsupported extension

This would allow the client to be much more usable with random public 
certs (using AIA fields and delegated responder certs) in real-world 
settings like secure email, etc.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 02 Oct 2003 11:19:04 +0200

David Engberg wrote:
> round-trip communications to establish nonce support, 

May I say we should *NOT* aim to fullfill this ?

If we don't, everything is easy.

Clients that requires freshest response send a nonce, and get back an 
error if it's not possible to give freshest response.
Client that don't require it, send no nonce.

Client that would like it, but don't require it, make a round trip, and 
cache the fact the server can't supply freshest response, so they do the 
round trip only once.

My opinion is :
- in real life implementations, it's not so common to both trust an OCSP 
responder, and not know in advance if it can supply fresh responses or 
not. Even if it's the case, there won't be so many different OCSP 
responders, and it won't take long to discover they don't provide fresh 
answers.

- The global security brought by trying to get a fresh response, but 
being ready to accept a non-fresh one, can hardly be said to be any 
different from directly accepting a non-fresh one. If the system was 
audited, I'm doubtful auditors would think it brings any real difference.

So I don't see a reason to go such lengths to support this.

---

From: David Engberg <[email-masked]>
Date: Thu, 02 Oct 2003 08:17:41 -0400

> cache the fact the server can't supply freshest response, so they do the 

I could live with a two-trip solution as an alternative as long as the 
error is contained in a signed message which can be pre-generated for 
that responder.  If the error is in the unsigned portion of the 
protocol, a client can't really tell a nonceUnsupported server from an 
attacker on the network, which means its only realistic option is to 
reject the response and quit.

An extra round-trip communication is unfortunate, but not a show-stopper 
if it conveys some other fundamental advantage that I'm missing.

> responders, and it won't take long to discover they don't provide fresh 

You may be only thinking of closed internal PKIs with one or two CAs and 
hard-coded clients.  I'm thinking of the broader case where I may want 
to accept signed emails from everyone that chains or bridges to one of 
my trusted roots.  I may accept signed emails from employees of Acme 
Novelties because their CA chains to a Verisign root, and their AIA OCSP 
responder was properly delegated by their CA (OCSP Signing).  I 
certainly have no idea whether Acme's responder keys are online 
(nonce-supporting) or off (nonceUnsupported) before my first request, 
even though I'm prepared to accept whichever security policy the CA chooses.

I think it is a valid and secure _option_ for a client to say "accept 
the revocation security policies chosen by trusted CAs and/or 
responders."  If a CA only publishes CRLs every 24 hours, its OCSP 
infrastructure should be able to signal to interested clients that they 
shouldn't waste everyone's time and CPU cycles by sending nonces just to 
get "fresh" views of the same cached CRL.

---

From: "Ambarish Malpani" <[email-masked]>
Date: Thu, 2 Oct 2003 07:15:41 -0700

I agree.

A

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jean-Marc Desperrier
> Sent: Thursday, October 02, 2003 2:19 AM
> To: [email-masked]
> Subject: Re: OCSP response pre-production
> 
> 
> 
> David Engberg wrote:

---

From: "Terry Hayes" <[email-masked]>
Date: Thu, 2 Oct 2003 10:47:30 -0700

I also like this proposal.  I believe that it is compatible with 
existing responders that use pre-produced nonces, in the sense that 
there aren't any changes required to allow them to continue operations.

Responders that only use pre-produced responses (with no nonce) would 
benefit from changing their implement to add the extension.  This would 
allow them to support the clients that implement dual-mode policy as 
described in this thread.

As Florian has pointed out, this proposal is easier to understand than 
having the server generate nonces.  In fact, I was going to write an 
email that complained about overloading the nonce field to represent 
this bit of information.  Given this proposal, I don't have to!

I also agree with Mike that we need to define an error that says that a 
nonce is required for this responder.  This error is subject to 
denial-of-service attacks (since it's unsigned), but we're already 
exposed to that in this protocol anyway.

Terry

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 2 Oct 2003 11:43:22 -0700

> From:  Terry Hayes
> . . .
> I also agree with Mike that we need to define an
> error that says that a nonce is required for this
> responder.  This error is subject to
> denial-of-service attacks (since it's unsigned),
> but we're already exposed to that in this protocol
> anyway.

Actually, Terry, errors were left unsigned largely to enable
edge servers to respond more effectively to a DOS flood than
might an interior signing server.

Mike