Re: POLL: Nonce-specific error code for OCSP

[Julien Pierre <jpierre@xxxxxxx>]

Michael Myers wrote:

> 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.
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?)
> error response does nothing to mitigate anti-replay.
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.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature