RE: OCSP response pre-production

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

I do not believe clients "SHOULD include a nonce" I believe they "MAY
include a nonce if they wish to protect the client from a replay attack,
the inclusion of a nonce precludes intermediate caching and pre-produced
responses".

Ryan

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

Hello Michael,

thanks for your mail and the background story. I see your point and
knowing the history of it makes it more easy to understand the current
discussion. 

I am very fond of a clarification of the text of RfC2560 regarding
nonces. I recognize your expertise gathered during the design of OCSP.
So maybe I am not in the right position to do this, but please allow me
to present another option for a clarification regarding nonce:
 

My guidelines drafting the clarification:

- clarify nonce handling
- improve security of the protocol

- allow for the same amount of possibilities as in the published RfC
- make only recommendations, do not add a new "absolute requirement"
- good compromise between "nonces" and "caching"
 

I am not an english native speaker - so please dont judge it by
eloquence or grammar. Here it comes:



"Clients SHOULD include a request nonce to allow responders to establish
protection against replay attacks. If the client included a nonce, it
SHALL reject responses containing a mismatching nonce. If the client
included a nonce, it MAY accept  responses containing no nonce at all
based on its (security) requirements."

"As a response without nonce could be used for a replay attack against
clients accepting such responses, responders that want to ensure a
maximum level of protection against replay attacks SHOULD include a
nonce into all responses. If the request did not contain a nonce, a new
nonce SHOULD be generated by the responder and included into the
response."




Please see the attached file for a comparison between the two proposals
in terms of interoperability and possibilities. I think my proposal will
bring the same level of security in real world situations without
denying other possibilities and without being able to break any
installations or implementations out there.

Best regards,

-- 
Florian Oelmaier
SyTrust

> -----Original Message-----
> From: Michael Myers [mailto:mmyers@xxxxxxxxx] 
> Sent: Friday, September 26, 2003 5:54 PM
> To: Ryan M. Hurst; David Engberg; oelmaier@xxxxxxxxxxx; 
> Ambarish Malpani; ietf-pkix@xxxxxxx
> Cc: Russ Housley; Stephen Kent; Tim Polk
> Subject: RE: OCSP response pre-production
> 
> 
> David, Ryan, Florian:
> 
> Apologies for the length of this but I didn't want this 
> predictable debate to occur on the POLL: thread.
> 
> The whole point of this clarification and the poll is to 
> recognize the fact that a client sends a nonce for two very good
> reasons: protection against replay and to ensure freshness. 
> Both are relevant to high-assurance security practices.  
> There was vigorous debate on this topic during OCSP's 
> genesis, a good deal of it between myself and Carlisle Adams, 
> from which came the nonce extension and it's optional use.
> 
> It was commonly understood back then that nonces break 
> caching. Some may recall that I was an advocate for pre-produced
> responses for precisely the reasons it's now surfacing.   We
> debated the point and arrived at a constructive conclusion.  
> It went through WG, IETF and IESG last calls. No one objected 
> and it became RFC 2560.
> 
> As the poll clearly indicates, this common understanding was 
> correctly interpreted by, so far, every OCSP implementor.  
> The proposed text simply codifies that understanding in a way 
> that makes it abundantly clear what SHALL be done.
> 
> We have a responsibility and a duty, especially within the 
> Security Area, to design secure protocols.  To have a 
> client's nonce sometimes respected and sometimes not, as 
> would be the case in changing the server-side requirement to 
> SHOULD from SHALL, defeats that purpose.
> 
> I'll say it again:  nonces are optional to begin with.  If 
> your system architecture relies on caching, then don't use 
> nonces. Now, I understand that one may not have full control 
> over client-side configuration and thus be unable to cause a 
> given population of clients to not use nonces.  But that does 
> not mean we should purposefully punch a hole in the security 
> of the protocol's specification in order to accomodate a 
> particular business case.
> 
> 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.
> 
> Mike
> 
> 
> 
>