Subject: RE: OCSP response pre-production

From: "Ryan M. Hurst" <[email-masked]>
Date: Fri, 26 Sep 2003 10:00:39 -0700

I concur with this, er "me too" :)

Ryan

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[email-masked]] 
Sent: Friday, September 26, 2003 9:40 AM
To: Michael Myers; Ryan M. Hurst; David Engberg; [email-masked];
Ambarish Malpani; [email-masked]
Cc: Russ Housley; Stephen Kent; Tim Polk
Subject: RE: OCSP response pre-production

I hate to send "me too" responses, but everything Mike says in his 
extended discussion is exactly right. My summary would be:

- If you can't sign, you must reject requests with nonces.

- Caching servers can ask a different server to sign. They can 
respond to all requests that don't ahve nonces, and they (probably 
selectively) send back the requests that have nonces to a server 
willing to sign them.

- If you control the OCSP clients and you don't want to sign the 
responses, inhibit the clients from sending requests with nonces.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Fri, 26 Sep 2003 10:10:07 -0700

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:[email-masked]] 
Sent: Friday, September 26, 2003 10:07 AM
To: 'Michael Myers'; Ryan M. Hurst; 'David Engberg'; 'Ambarish Malpani';
[email-masked]
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

> From: Michael Myers [mailto:[email-masked]] 
> Sent: Friday, September 26, 2003 5:54 PM
> To: Ryan M. Hurst; David Engberg; [email-masked]; 
> 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
> 
> 
> 
>

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Fri, 26 Sep 2003 10:05:56 -0700

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:[email-masked]] 
Sent: Friday, September 26, 2003 9:49 AM
To: Michael Myers
Cc: Ryan M. Hurst; [email-masked]; Ambarish Malpani;
[email-masked]; 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
> security hole when I see it.  We incorporate thoughtful security
> features into our protocols for a reason.
>

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Fri, 26 Sep 2003 10:27:57 -0700

That's a good point, how about:

"Correspondingly, if a responder has only supports pre-produced
responses it may reject request that include a nonce, otherwise upon
receipt of a request containing a nonce, a responder SHALL include the
value of such nonce in the production of the associated response."

Ryan

-----Original Message-----
From: Dr Stephen Henson [mailto:[email-masked]] 
Sent: Friday, September 26, 2003 10:22 AM
To: Paul Hoffman / IMC
Cc: Michael Myers; Ryan M. Hurst; David Engberg; [email-masked];
Ambarish Malpani; [email-masked]; Russ Housley; Stephen Kent; Tim
Polk
Subject: Re: OCSP response pre-production

Firstly as I mentioned before I've no problem with nonces and the 
proposed wording.

However I'm a bit confused by this:

> - If you can't sign, you must reject requests with nonces.

and the proposed wording:

Michael Myers wrote:
> 
>     "Correspondingly, upon receipt of a request
>      containing a nonce, a responder SHALL include
>      the value of such nonce in the production of
>      the associated response."
> 

Which seems to suggest to me that a responder isn't allowed to reject 
requests with nonces or am I misinterpreting it?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Fri, 26 Sep 2003 12:41:20 -0700

Florian - the client can protect itself from replays if it cares to by
simply not trusting a response without a nonce; there is no need to
generate a server side nonce since the client can't do anything with it
anyhow.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Florian Oelmaier
Sent: Friday, September 26, 2003 10:37 AM
To: 'Michael Myers'; 'David Engberg'
Cc: Ryan M. Hurst; 'Ambarish Malpani'; [email-masked]; 'Russ
Housley'; 'Stephen Kent'; 'Tim Polk'
Subject: RE: OCSP response pre-production

[...]

> Thus "Maybe the nonce is incorporated, maybe not" is 
> equivalent to NOT sending a nonce in the first place.  Which 
> rather defeats the purpose of sending a nonce.

Thats true. But this can be "cured"! If an OCSP-Responders that is able
to use nonces, detects a request without nonce, he simply includes a
self-generated nonce into his response. Thus an attacker is not able to
obtain a response without nonce from this particular responder. Thus he
cannot fool the client with a replay attack.

The client behaviour you describe is exactly the reason why our
responder (in its default configuration) will currently ALWAYS include a
nonce into the response (even at the cost of generating one by itself).

This way nonces are of value when used with a responder being able to
use them while simultaneous allowing response pre-production.

-- 
Florian Oelmaier
SyTrust

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Mon, 29 Sep 2003 16:40:20 -0700

As I see it there are several problems here:

First the RFC isn't clear on what the client is asking when it includes
a nonce, my take has always been that a request with a nonce is a
request that the client would like to have generated dynamically for it;
it seams from the other responses on the thread that this is was the
common interpretation. I think Mikes proposed text resolves this issue.

Next if a server can't generate a response dynamically (or forward it to
someone who can) what is he to return? I see several options here:
1. Expand section "4.4.1  Nonce" to include nonceNotSupported, this
could be returned by the server indicating to the client that it does
not support dynamic responses.

NOTE: I am not sure why the client needs to know this, but extra
information always helps in diagnostics so I am not apposed to this.

2. If a server can't support a nonce it returns internalError
NOTE: notAuthorized is also an option; authorization is a function of
policy and in this case the policy does not support the generation of
dynamic responses.

And finally what is a server supposed to return if it receives a request
without a nonce? I see several options these include:
1. Answer him! Nonce's only protect the client; if the client doesn't
want a nonce don't give him one.
2. Return internalError or notAuthorized as per above, this allows
servers in environments who want

The server to enforce client policy to refuse to answer questions that
he thinks may be questionable.

In the end I the decision to use a response is the clients, the decision
to send one is the server and the return can give a little detail or
allot.

Ryan

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 30 Sep 2003 15:18:04 +1000

Clients may prefer a nonce-based (not clock-based) freshness guarantee when available.  Clients may also be willing to accept cache-only responders (with their clock-based freshness) when necessary, as they can offer advantages for large-scale systems.

Clients may want both these options, but they do not want to allow an attacker to choose when the "downgrade to cache-only" occurs.

A solution:
1) Responders that can include the request nonce in the response MUST indicate this capability.  Including the nonce extension in the response (even if the request didn't have one) seems like a reasonable way to indicate this.
2) If a request includes a nonce a client MUST reject the response if it also contains a nonce but that nonce has a different value.
3) Client MUST NOT reject responses with nonces just because the request didn't include a nonce.

Note: Dynamic responders can still cache responses with nonces to respond to subsequent nonceless requests.
Note: Cache-only systems can pre-produce responses without nonces to respond to any request.

I suspect current clients already do 2) & 3).  Perhaps only Florian's responder currently does 1), but this is not a huge problem.  Clients that support "downgrade to cache-only iff that is all that is available" can be configured for this on a per-responder basis if necessary.

(So I don't like Denis's "New text proposal")

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Monday, 29 September 2003 8:07 PM
To: Deacon, Alex
Cc: [email-masked]
Subject: Re: OCSP response pre-production (was RE: POLL: Use of nonces
in OCSP)

...
New text proposal:

     "Upon receipt of a request containing a nonce,
      a responder SHALL include the value of such nonce
      in the production of the associated response,
      if it is not using cached pre-produced responses.
      If the responder is using cached pre-produced responses,
      then it MAY send back a response with or without a nonce."

      "Clients that elect to include a request nonce
      MAY reject responses that fail to include
      the client's nonce from the associated request.
      Alternatively they MAY ignore the nonce field and accept
      the response, if they have a local trusted clock and are
      satisfied with the time difference between their local
      trusted clock and the producedAt field from ResponseData".

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 30 Sep 2003 13:03:23 +1000

Item B) should be:

B) Client wants to get a custom-made response, but will also accept a pre-produced/cached response IF AND ONLY IF THE SYSTEM IS INCAPABLE OF PROVIDING A CUSTOM-MADE RESPONSE.

I think the options a responder might want to signal are instead:

1. Here is an answer..  it is cached as they are the only type I produce
2. Here is an answer..  it is cached, though I could have produced a custom-made response if you wanted it
3. Here is a custom-made answer
4. ERROR..  I cannot produce custom-made answers
5. ERROR..  I insist that clients use nonces for extra protection

1 & 2 could be distinguished by the absence and presence of the nonce extension in the response respectively (the value of the response nonce is irrelevant).

-----Original Message-----
From: Florian Oelmaier [mailto:[email-masked]]
Sent: Tuesday, 30 September 2003 9:58 AM
To: 'Michael Myers'; [email-masked]
Subject: RE: OCSP response pre-production

> We have discovered a hole.  To give it a name let's call it 
> Nonce Capability Discovery.  This hole will not be filled by 
> artful requirements language alone.  We need proposed technical
> components: a few bits of ASN.1 and associated semantics.

So we need some additional signalling between client and responder. I
tried to list all the items a client would like to signal to the
responder and the other way round.

The client has 3 options that he would like to signal to the responder:
A) Client will accept a pre-produced/cached response. 
B) Client wants to get a custom-made response, but will also accept a
pre-produced/cached response.
C) Client wants to get a custom-made response and will not accept
pre-produced/cached responses.

A responder has 5 options that he would like to signal to the client:
1) Responder wants others to be able to cache (replay) this response
2) The response is a cached copy from another soure or was pre-produced
3) This is a custom-made response to a particular request (this
obviously includes 4)
4) This particular response should not be used in any type of caching
(replaying) 
5) Error: This Responder cannot produce custom-made responses

What about the following proposal (numbers corresponding to the signals
above):

A) Client does not include nonce into request.
B) Client includes nonce into request.
C) Client includes nonce into request and marks it CRITICAL.

1) Responder does not include nonce into response.
2) Responder does not include nonce into response.
3) Responder copies the nonce of the request into the response
4) If the request did not contain a nonce, the responder generates a
nonce for the response
5) We add a new error code 7: "Nonce extension cannot be processed"

Advantage: We only need to change minor things in the RfC:
- allow for CRITICAL on extensions
- add a new error code
- add some clarifications / text.

Disadvantage of this proposal: 
- we miss the opportunity to signal the "source of validation" - CRL vs.
fresh/live data.
- We cannot distinguish 1) and 2).

-- 
Florian Oelmaier
SyTrust

---

From: "Florian Oelmaier" <[email-masked]>
Date: 30 Sep 2003 10:17:56 -0000

I have no problem with your proposal, but allow me to add one further differentiation to your point 3:

------ 

1. Here is an answer..  it is cached as they are the only type I produce
2. Here is an answer..  it is cached, though I could have produced a custom-made response if you wanted it
3. Here is a custom-made answer tailored to the request
4. Here is a custom-made answer without having requested it
5. ERROR..  I cannot produce custom-made answers
6. ERROR..  I insist that clients use nonces for extra protection

------ 

-- 
Florian Oelmaier
SyTrust

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 30 Sep 2003 14:00:15 +0200 (MEST)

At least, in X509 this is not (no longer) a difference
between an exension being critical or not, i.e, saying that
you have to treat it differently depending on whether the
criticallity bit is set or not as soon as you know to
treat it at all.

Since extensions are borrowed from X509 I am not sure that it
is a good idea to define different semantics depending on
the criticality bit.