Subject: RE: DPD & DPV requirements - to nonce or not to nonce?

From: Stephen Kent <[email-masked]>
Date: Thu, 1 Feb 2001 12:15:55 -0500

Carlin,

><snip>
>[Carlin]:
>I agree that if the client is going to trust the DPV server
>to give a correct status response, the client should also trust the
>DPV server to check the nonces in any responses that the server receives
>from queries that it relays to other servers. 
>
>But what about a DPD query?  The client gets back a list of certificates
>and a set of certificate status information that may contain OCSP responses
>with nonces in them.  But the client can't use the nonces to protect itself
>against replay, because the client didn't generate those nonces.  Some
>server downstream (upstream? which way does this stream flow?) put the
>nonces in queries that were relayed to other servers.  If the client can
>make do without replay protection, why were nonces put in the OCSP protocol
>in the first place?  Note that this isn't a deficiency of OCSP.  The same
>thing would be true of DPV, DPD or SCVP if those responses were returned
>in DPD responses.

OK, now I see the crux of this issue. Yes, for DPD, a returned OCSP 
response, even if it carries an optional nonce, does not provide the 
desired freshness guarantee for the client, who is unable to 
independently evaluate the timeliness of the response. Our current 
proposal implicitly requires the client to trust the DPD server, 
which violates our model for DPD vs. DPV.

It also raises a related, subtle issue, namely what service(s) should 
a DPD server provide when OCSP is employed. The server could be 
required to use a nonce supplied by the client in a real time query 
to an OCSP server, in an effort to provide a transitive freshness 
guarantee. But that does away with the presumed caching benefit that 
might accrue from using a DPD server. If the server caches OCSP 
queries, then the client has to trust the server, because the client 
cannot have influenced the query a priori, and/or because the query 
might be returned to multiple clients (who would not have coordinated 
their nonce choices). This latter situation looks a lot like an OCSP 
server that pre-signs responses and thus does not even make use of a 
nonce.

As described above, it seems that the problem has a lot to do with 
the option for transitive nonce use by a DPD server, and maybe with 
the need for such servers to allow a client to specify such service, 
and less with what I gleaned from Peter's message, which seemed to 
focus on techniques by which a server could more efficiently protect 
itself from replayed client queries. Yes, such techniques could be 
used by a server here to reduce its vulnerability to replayed 
queries, but that seems to be a secondary issue relative to the more 
fundamental one we face with regard to DPD and OCSP.

Maybe we should settle for CRLs here and avoid this mess :-)

Steve

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 1 Feb 2001 10:50:19 -0800

Steve, Carlin:

Towards closure, in my humble opinion it seems the best we can do here is
maintain OCSP's optional nonce mechanism and let the system security
architects of the world sort out these system level issues.

Mike

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: Thursday, February 01, 2001 9:16 AM
> To: Carlin Covey
> Cc: [email-masked]
> Subject: RE: DPD & DPV requirements - to nonce or not to nonce?
>
>
> Carlin,
>
> ><snip>
> >[Carlin]:

---

From: "Carlin Covey" <[email-masked]>
Date: Thu, 1 Feb 2001 11:54:07 -0700

Mike, Steve, Peter and Peter,

I agree that we should maintain OCSP's optional nonce mechanism.
As Peter Sylvester has pointed out, even without using the nonce
the "freshness" of the response can be determined by the ProducedAt
field to at least the resolution provided by the similar field in CRLs.

Regards, Carlin

-------------------------

- Carlin Covey
  Cylink corp.

-----Original Message-----
From: Michael Myers [mailto:[email-masked]]
Sent: Thursday, February 01, 2001 11:50 AM
To: Stephen Kent; Carlin Covey
Cc: [email-masked]
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?

Steve, Carlin:

Mike

---

From: Rich Salz <[email-masked]>
Date: Thu, 01 Feb 2001 14:14:05 -0500

> field to at least the resolution provided by the similar field in CRLs.

I fade in and out of the DPD/DPV discussion, but my ears perked up when
I saw the above...

There's much more to the nonce then freshness.  For example, if I
receive a signed document, I can use the hash of that document as the
nonce.  I now have "proof" (not in a legal, perhaps in a contractual)
sense that I did due diligence before relying on the signature.  That's
why Rich Ankney put them into the OCSP spec.
	/r$

---

From: Stephen Kent <[email-masked]>
Date: Thu, 1 Feb 2001 14:09:59 -0500

Mike,

>architects of the world sort out these system level issues.

We need to have a clear definition of what the servers do, and what 
the clients can expect. After we establish that, we can leave the 
rest of the details to implementors. So, for example, if someone 
wants to make use of the sort of scheme that Peter Williams proposed 
for efficient storage and lookup of nonces, that's beyond the scope 
of the standard. But, the issue of whether the client can demand a 
very fresh OCSP response or not is a matter for the standard as it is 
at the heart of the service being offered, the security model for the 
system that uses the server, etc.  Anyway, since Peter Sylvester 
pointed out my oversight re the OCSP responder ProducedAt field, I 
feel better about what the residual problems are.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 1 Feb 2001 14:43:45 -0500

>why Rich Ankney put them into the OCSP spec.

Proof because you used the nonce in the OCSP extension? Well, that's 
novel, but I'd rather not have "features" like this lurking in 
standards with no accompanying documentation. Peter Williams 
chastised us for not doing a better job of describing nonce 
management for OCSP, and he's got a valid point. This sort of 
overloading of the nonce, no matter now noble the intent, seems like 
a bad idea in the larger context. But, given the current lack of 
specification re nonce generation, it's certainly not prohibited.

Steve

---

From: Rich Salz <[email-masked]>
Date: Thu, 01 Feb 2001 14:57:52 -0500

> This sort of

Quite the contrary, as quoting from 4.4.1 of RFC2560
   The nonce cryptographically binds a request and a response to prevent
   replay attacks. 

How do I know you did a status check on the signer before relying on the
signer?  Tie the document to the request.  It's one reason why OCSP is
so much "better" than CRL's.  (Please -- I'm *kidding around.*)

I'd be quite surprised if this doesn't show up in the mail archives once
or twice.  I'm not sure how to make it could have been made more
explicit, and even if it would have been appropriate for 2560.

These kinds of things always show up when a newcomer reads a spec,
separately from those have been heads-down into it from the beginning.
	/r$

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 1 Feb 2001 12:13:12 -0800

Steve,

We might be in agreement.  Today, OCSP clients MAY force absolute freshness
via nonces.  My only point being that needs for system-level deployment
flexibility very likely preclude a SHALL in the OCSPv2 update to RFC 2560.
My thanks to Peter as well re: the producedAt field.  I recall that one took
a bit of dialog years back as well.

Mike

> Sent: Thursday, February 01, 2001 11:10 AM
> To: Michael Myers
> Cc: [email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Thu, 1 Feb 2001 15:16:02 -0500

Rich,

>separately from those have been heads-down into it from the beginning.

I could point you to mountains of literature on secure protocols that 
use nonces for freshness (usually equivalent to anti-replay, but 
subtly distinct here). I doubt that any of those suggest deriving a 
nonce from a document hash. That's because most of these protocols 
are independent of the application context and thus no document would 
be directly relevant. Peter's cite's of X.509 auth protocols 
certainly have this quality.  I agree that there is a nice 
side-effect of choosing a nonce in this fashion for this protocol, 
for some applications, but there is no reason to suppose that every 
(most?) OCSP request is being used with a document for NR purposes. 
Thus this is not a generally applicable notion and I stand by my 
criticism.

Re your "newcomer" comment, let's just say that a standard should be 
written so that a search of the archives is not necessary to its 
understanding.

Steve

---

From: Rich Salz <[email-masked]>
Date: Thu, 01 Feb 2001 15:33:27 -0500

> written so that a search of the archives is not necessary to its

Oh, I quite agree, and certainly meant no offense.  I was only trying to
say that it can be hard to make everything explicit that should be made
explicit.

I never tried to say that most folks use the OCSP nonce to prove
business logic, only that some do, and that was an original motivator
for its appearance in the spec.  And I apologize that we-all didn't make
that more clear.
	/r$

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 1 Feb 2001 13:39:40 -0800

FWIW, the appearance of the OCSP nonce in the spec was a direct outcome of a
list-based discussion between myself and Carlisle regarding replay attacks.
The "freshness effect" vs. pre-signed and cached OCSP responses is a useful
side effect.  It might turn out to be the more useful effect of the
practice.

Mike

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Rich Salz
> Sent: Thursday, February 01, 2001 12:33 PM
> To: Stephen Kent
> Cc: [email-masked]
> Subject: Re: DPD & DPV requirements - to nonce or not to nonce?
>
>