RE: OCSP response pre-production

["Ryan M. Hurst" <rmh@xxxxxxxxxxxxxxxxxxxxx>]

David I don't believe the proposal requires a server to support the
mixed mode behavior, I think it simply clarifies that this is how that
environment would be served.

Ryan

-----Original Message-----
From: David Engberg [mailto:dave@xxxxxxxxxxxxxx] 
Sent: Friday, September 26, 2003 9:49 AM
To: Michael Myers
Cc: Ryan M. Hurst; oelmaier@xxxxxxxxxxx; Ambarish Malpani;
ietf-pkix@xxxxxxx; Russ Housley; Stephen Kent; Tim Polk
Subject: Re: OCSP response pre-production


Michael -

I should have clarified in my poll response that an extant signing 
server (CoreStreet's RTC Responder, part of the RTC VA) is broken by the

change unless the responder SHALL is changed to SHOULD.  With this 
modification, the clients are allowed to enforce your stated nonce 
requirements without breaking any servers.

I do not believe that Ryan's solution fits the needs of a large scale, 
high security deployment.  By forcing OCSP deployments to leave a 
key-bearing master server online, you are exposing your infrastructure 
to the risks of remote compromise (e.g. 
http://www.cert.org/advisories/CA-2002-29.html) and denial-of-service. 
Both of these attacks are more common and catastrophic in the real world

than any sort of man-in-the-middle replay of short-lived responses.

The proposed mixed-mode compromise would be similar to requiring the 
root DNS servers to perform RSA signatures whenever requested by a 
client.  An attacker on a 56kbps dial-up line could send enough requests

to saturate even a top-of-the-line $25k HSM.  One buffer overflow would 
allow an attacker to create responses that reinstate any revoked 
credential.

Is there any reason not to change the responder language to SHOULD while

maintaing the client language as SHALL?

Thanks,
David


Michael Myers wrote:
 > ...
> Ryan had a useful solution to this.  Non-signing caching servers
> relay nonced requests to whatever master server they're
> associated with that can sign.  A fresh response, including the
> nonce, comes back and is then forwarded to the requesting
> client.
> 
> Sure, this impacts system-level performance.  But the answer to
> the performance problem is straightforward:  get bigger, faster
> boxes and bigger, faster signing engines.  I suspect there's an
> ample number of crypto vendors out there who would be willing to
> pitch their wares against the latter need.
> 
> It's also worth noting that among a heterogeneous population of
> clients, perhaps only a small portion of them would nonce.  On
> the other hand, maybe most will.  I don't know.    I do know a
> security hole when I see it.  We incorporate thoughtful security
> features into our protocols for a reason.
> 
> So, nonces break caching.  We knew that from day one. But, as
> far as I can tell from the poll to date, NO extant signing
> servers or clients are broken by the proposed text.