Subject: Re: POLL: Nonce-specific error code for OCSP

From: "Florian Oelmaier" <[email-masked]>
Date: 16 Oct 2003 08:48:41 -0000

> Should we standardize an OCSP *V1* error code that enables a
> responder to indicate its inability to respond to nonced
> requests?
> 
> Please respond with either YES or NO.

NO

Rationale: 
My first idea was to say: if it is OPTIONAL for the responder to use that error code it is ok. But in fact even the OPTIONAL inclusion harms the security of the protocol, as an attacker can fool clients into believing a particular OCSP-Responder would not support nonces, when in fact it does.

My conclusion: Dont include such an error code, due to security reasons. If other reasons (yet unknown to me) overrule these concerns make the use of this error code OPTIONAL for responders to allow compatibility with existing installations and not to harm the functionality of the protocol.

-- 
Florian Oelmaier
SyTrust

---

From: Julien Pierre <[email-masked]>
Date: Thu, 16 Oct 2003 14:27:49 -0700

>My first idea was to say: if it is OPTIONAL for the responder to use that error code it is ok. But in fact even the OPTIONAL inclusion harms the security of the protocol, as an attacker can fool cli…
Agreed. The OCSP responses with error codes are not signed, so this 
would present a security hole. We should not let the server return this 
error code in an unsigned response.

IMO, it would be acceptable to have an error code only if the response 
was signed and included a validity period. Each caching responder would 
have to prefetch such a response in order to be able to serve it back to 
clients that send nonces.

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 16 Oct 2003 16:39:49 -0700

Julien,

I modified the subject line to keep the POLL thread clean for
votes.

OCSP errors are unsigned to enable handling of DOS-type attacks
at the edge rather than the core.  This feature was argued in
favor of those who might deploy this protocol using pre-produced
responses.  That said, presenting a pre-fetched (pre-signed?)
error response does nothing to mitigate anti-replay.

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Julien Pierre
> Sent: Thursday, October 16, 2003 2:28 PM
> To: [email-masked]
> Subject: Re: POLL: Nonce-specific error code for OCSP
>
>
> Florian Oelmaier wrote:
>
> >Rationale:
> >My first idea was to say: if it is OPTIONAL for the
> responder to use that error code it is ok. But in
> fact even the OPTIONAL inclusion harms the security
> of the protocol, as an attacker can fool clients into
> believing a particular OCSP-Responder would not
> support nonces, when in fact it does.
> >

---

From: Julien Pierre <[email-masked]>
Date: Thu, 16 Oct 2003 17:16:19 -0700

Michael Myers wrote:

>responses.
The nonce extension was introduced so that clients could make sure that 
they would get fresh responses from a live OCSP responder.
If we add an unsigned error code in the clear to state that the OCSP 
responder is not live and therefore can't sign nonce requests, then the 
purpose of the nonce extension can be easily defeated by a attacker who 
can replay that error code and fool the client into thinking that he is 
not talking to a live responder. I believe that is a security hole that 
defeats the purpose of nonce. This case is much different from DOS 
cases. Due to the other unsigned error codes in OCSP, DOS attacks cannot 
be avoided. But a client can handle them properly, by considering them 
the same as a failure to validate.
On the other hand with this "caching responder" error code, some invalid 
certs that were recently revoked might be considered valid because an 
attacker sent this error code, then served an older good cached response 
for the recently revoked cert. Validating invalid certs is a much more 
serious problem than DOS, in my opinion.

In the end, there are really only two real-world cases, and they come 
down to the OCSP client's policy :
1) If the client is willing to accept pre-produced responses, it should 
not send nonce in the OCSP request. End of story, all signed responses 
are good. The client is subject to replay attacks, but it is aware of 
that fact - that's how it was configured.
2) If the client insists on talking to a live responder, it should send 
nonce in the OCSP request, and check for the same nonce in the OCSP 
response. If they match, the response is accepted, otherwise, they are 
not accepted.

What prompted this discussion is that due to performance (and other) 
concerns, a lot of people are running caching responders today, and want 
their responses to be accepted by clients of type 2.
I don't think that's a good thing because nonce was specifically 
introduced to prevent replay attacks, and as a result, is incompatible 
with caching responders. The clients that send nonce in their requests 
are very few, but they probably have good reasons to do so.

>  That said, presenting a pre-fetched (pre-signed?)
Not true if that response has an expiration time. As I mentioned above, 
to be useful, this signed error response would need to have a validity 
period : ie. between times t1 and t2, this responder may send 
pre-produced responses. If this cached signed response was sent, the 
client could be reasonably sure that the server truly intended to send 
cached responses for that period. This does mean that periodically (when 
t2 comes up), the caching responders would have to refetch this error 
response from the master (live) responder. However it still allows 
caching to work by dramatically reducing the signature operations.
This new type of error response would enable a third type of OCSP client 
policy that is not possible today :

3) Clients that prefer signed OCSP responses, but are willing to accept 
cached responses if the server can convince them that it is a caching 
responder.
They would work by sending a request with nonce. They would only fall 
back to accepting no-nonce responses if they first received a signed 
response with the "caching responder" error code from the responder. And 
they would only accept the pre-produced responses if the time of their 
OCSP requests fell between t1 and t2.

There could also be a statement in the "caching responder" response as 
to the maximum age of the subsequent cached responses. This would 
partially protect against replay attacks from the beginning of time.

I think this is definitely not something to consider for OCSP v1, but it 
can be discussed for v2.

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 16 Oct 2003 20:12:01 -0700

Julien,

Perhaps this time the subject line modification will stick.  Two
discussion points embedded below.  Apologies in advance for the
abbreviation of your thoughtful comments.

Mike

> From: Julien Pierre
> . . .
> What prompted this discussion is that due to
> performance (and other) concerns, a lot of
> people are running caching responders today,
> and want their responses to be accepted by
> clients of type 2.

[mm] To my count, "a lot" is two among the
     twelve server-side implementors who
     responded to the prior poll.

>
> [well-reasoned v2-relevant discussion . . . ]
>

[mm] I agree there exists many variations
     in a v2 context and I agree that this
     WG should consider all such in the
     timeframe of that potential standard.

[mm] Meanwhile, what should we do for v1?
     The current de-facto default is that
     a nonce may be ignored. Does this WG
     support that premise?

Mike