Subject: RE: POLL: Use of nonces in OCSP

From: "Ryan M. Hurst" <[email-masked]>
Date: Thu, 25 Sep 2003 17:27:41 -0700

Dave - I agree that pre-produced responses are important, but I don't
think this wording prevents that behavior; the text proposed was:

"Clients that elect to include a request nonce SHALL reject responses
that fail to include the client's nonce from the associated request."

In other words if you include a nonce in your request you should compare
it to the nonce in the response you get back; This does mean that
clients should include a nonce, so clients that do not include a nonce
(like ours) are not negatively effected by this statement.
 
"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."

In other words if a client sends you a nonce generate a fresh response
and copy the nonce from the request into it. This does have the
potential to cause problems for clients that are sending a nonce, but if
their client is sending the nonce they are saying "hey help protect me
from replay attacks".

I wouldn't have a problem with changing the SHALL to a SHOULD, but if we
were to do that we should qualify why so that people understand the
distinction.

My personal opinion is that if a responder that distributes pre-produced
responses gets a request with a nonce in it, it should proxy the request
to the master to get a fresh response and replay it.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David Engberg
Sent: Thursday, September 25, 2003 2:45 PM
To: [email-masked]
Subject: RE: POLL: Use of nonces in OCSP

No, we would not like to see the language change.  Yes, it would break 
existing deployments based on caching-only responders.

Explanation:

There is a (strong) case to be made that a large OCSP deployment based 
around caching-only responders with no private keys to protect can be 
more secure against real-world attacks than one based entirely on 
live-signing responders using nonces:

     http://www.corestreet.com/whitepapers/nonce-sense.pdf

It would be undesirable to change the specification to break existing 
implementations and deployments that chose this route.

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 25 Sep 2003 18:28:51 -0700

> Ryan M. Hurst
> Sent: Thursday, September 25, 2003 5:28 PM
>
>. . .
>
> I wouldn't have a problem with changing the SHALL to 
> a SHOULD

I will.

Mike

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 26 Sep 2003 08:54:12 -0700

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: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 26 Sep 2003 09:40:15 -0700

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: David Engberg <[email-masked]>
Date: Fri, 26 Sep 2003 12:49:00 -0400

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:
 > ...

---

From: "Florian Oelmaier" <[email-masked]>
Date: Fri, 26 Sep 2003 19:06:44 +0200

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]; 
> Ambarish Malpani; [email-masked]
> Cc: Russ Housley; Stephen Kent; Tim Polk
> Subject: RE: OCSP response pre-production
> 
> 
> David, Ryan, Florian:
> 
> 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
> 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.
> 
> 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.
> 
> 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
> security hole when I see it.  We incorporate thoughtful 
> security features into our protocols for a reason.
>

---

From: Dr Stephen Henson <[email-masked]>
Date: Fri, 26 Sep 2003 18:22:25 +0100

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: "Michael Myers" <[email-masked]>
Date: Fri, 26 Sep 2003 10:30:28 -0700

> From: David Engberg [mailto:[email-masked]]
> . . .
> 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.

OK.  That's the first one.

With apologies, may I ask a slightly pointed question to make
sure we understand each other?  Are you saying that CoreStreet's
RTC Responder would NOT incorporate a nonce if it received such
in a request?

> 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
> 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.

All reasonable concerns regarding high-assurance security
practices.  But then, use of nonces lies squarely within that
realm too.

> . . .
>
> Is there any reason not to change the responder
> language to SHOULD while maintaing the client language as
SHALL?

A client asserts a nonce for very specific security needs.  If
the specification allows for selective respect of these needs,
the core assurances of the nonce are lost since the client will
be unable to conclusively determine if it's being subject to
replay nor will it have certain knowledge of the most recent
revocation data.

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.

Mike

---

From: "Florian Oelmaier" <[email-masked]>
Date: Fri, 26 Sep 2003 19:37:19 +0200

[...]

> 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: David Engberg <[email-masked]>
Date: Fri, 26 Sep 2003 13:54:26 -0400

> RTC Responder would NOT incorporate a nonce if it received such

Correct.  The RTC Responder has no private keys to sign on its own, and 
will not relay to a master authority since it is used with an offline 
master authority.  This eliminates the risk of remote key compromise and 
allows for orders-of-magnitude better resistance to denials of service.

> practices.  But then, use of nonces lies squarely within that

Exactly.  So the ideal is a security protocol that allows implementors 
and deployers to address all risks based on their requirements, rather 
than mandating a policy for one risk that severely increases other 
risks.  I would choose to not mandate that every responder must be able 
to sign responses to be OCSP-compliant.

> the purpose of sending a nonce.

This sounds like an argument for the behavioral rules of the client 
(SHALL).  I would suggest separating this from the mandating the 
security behavior of the responder (SHOULD).

Thanks,
Dave

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 26 Sep 2003 12:34:02 -0700

At 6:22 PM +0100 9/26/03, Dr Stephen Henson wrote:
>Which seems to suggest to me that a responder isn't allowed to 
>reject requests with nonces or am I misinterpreting it?

You are misinterpreting it. How would a responder that doesn't sign 
nonces respond at all? A different wording would be, "If a request 
includes a nonce, the response MUST must either include the nonce or 
be a failure."

--Paul Hoffman, Director

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 26 Sep 2003 12:20:25 -0700

Dave,

An offline signing server is arguably a good security practice
but I'm having difficulty resolving that against the fact that
we're talking about an online protocol.

Mike

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> David Engberg
> Sent: Friday, September 26, 2003 10:54 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 Myers wrote:

---

From: Dr Stephen N Henson <[email-masked]>
Date: Fri, 26 Sep 2003 21:15:20 +0100

Paul Hoffman / IMC wrote:

> A different wording would be, "If a request 
> includes a nonce, the response MUST must either include the nonce or be 
> a failure."
> 

In which case my followup question would be how would the responder 
signal failure to the client?

None of the standard error codes seems entirely appropriate.

Then there the additional issue of how the error code can be sent in 
such a way that an attacker could give the impression that a responder 
can't sign nonces when it can.

Steve.