Subject: RE: DISCUSS: MUST reject in OCSPv1

From: "Ryan M. Hurst" <[email-masked]>
Date: Thu, 27 Nov 2003 15:56:05 -0800

cil

________________________________

From: [email-masked] on behalf of Marc Branchaud
Sent: Thu 11/27/2003 1:49 PM
To: [email-masked]
Subject: Re: DISCUSS: MUST reject in OCSPv1

Ryan M. Hurst wrote:
>
>> Why can't the client can decide this before making the request?
>
> [rmh] There are several cases; consider this one, bookstore.com
> (server) has a certificate from bigttp.com, client is connecting to
> bookstore.com and both the client and the server in this scenario
> support the new tls extensions allowing a server to provide a client
> a copy of its ocsp response (from bigttp.com). The server would want
> to keep a local copy of the ocsp response, he would also want to
> re-fresh this cached copy before passing it off to the client if he
> knew it was expired or about to be expired. He could when generating
> his OCSP request to bigttp.com include a nonce indicating he wants a
> fresh response (afterall this is implicit when asking for the nonce
> in the response). Since in this case all the server wants is a fresh
> response (he will be caching and replaying afterall) getting back a
> respone without a nonce is OK.

No, it's not OK.

First off, the nonce is _not_ an indication that the server wants a
fresh response.  Like the RFC says, it's an indication that the server
doesn't want to be replayed a previous response.  Even with the nonce,
there's nothing to stop the bigttp.com OCSP server from giving the
server a status value based on yesterday's CRL.
[rmh] Never said that was the explicit intent of the nonce, it is a side effect; even if bigttp.com gave a response that was based on a CRL it would still be the freshest response possible.

Second, if the server accepts a nonceless response not only is it not
guaranteeing that it gets a "fresh" response, but it's also at risk of
getting a replayed response.  Again, the nonce (or rather, its
absence/presence in the response) does nothing to guanrantee any kind of
"freshness".  By accepting nonceless responses the server could even
accept the same response it already has.  If the server's OK with that,
then there's no point in putting a nonce in the request in the first place.
[rmh] Replay is the goal in this scenario, e.g. intermediate caching so I am not sure I get your point. As to the guarantees in OCSP the only garontees in the protocol (asuming a accepted trust model) is that the status in the response given the constraints associated with it (time validity, etc.) are truthfull. My point in the scenario above (and I imagine this being a VERY common scenario) is that for the likley side effect of submiting a nonced request is that you will get the freshes informationa availible; no gaurantees but it incredibly likley.

> The alternative with the proposed text would be to make a request
> with the nonce, get denied and make another one; resulting in two
> wire retrievals instead of one like the original version of the RFC
> allowed for.

There's more than one alternative.

A more reasonable approach would for the server to not put a nonce in
the request in the first place.  This results in a single over-the-wire
transaction that meets the security parameters the server is willing to
live with.

[rmh] Sure, if you dont care about the scenario in question that would work; the front end server would likley be a pre-produced responder (and in this case that is very likley, espectialy if you wanted to scale to support internet scale revocation checking); the likley behavior if such a responder got a request with a nonce is that it would try to service it either by using its own key material to produce a fresh response or more likley forward the request to a back end server that would do just that.

>> What does the client gain by making a nonced request but accepting
>> a nonceless response?
>
> [rmh] there are several, consider the above; we must remember what
> the nonce means; directly it means I would like to try to protect
> myself from replays; ok, so what is a replay? a stale response; so it
> also means give me the freshest data you have.

No, it doesn't mean that at all.  The OCSP server is still free to
construct a response based on whatever data it sees fit.  All the nonce
does is force the server to sign a new response.  It doesn't say
anything about how "fresh" the data is in that response.

[rmh] I did not say it did, and in this case its not about guarantees.

> If the group wishes to address the use of nonces for more than replay
>  prevention, then I think the only option is to devise a new OCSPv2
> spec.
>
> [rmh] its not necesssary, the current RFC works and by changing the
> semantics you disallow a legitimate use that worked and was
> conformant.

But that use wasn't conformant.  All that RFC2560 wants to use nonces
for is to prevent replay attacks.  Any other use of nonces goes beyond
what RFC2560 says they're for.

[rmh] it absolutley is; find the text that precludes this behavior.

                M.

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 28 Nov 2003 09:47:27 -0700

If we must digress, and I think it's useful to do so, let's do
it here.

> [rmh] it absolutley is; find the text that precludes this
behavior.

To which I comment:

I dislike negative requirements.  They are untestable and are
therefore useless in customer acceptance testing.  Neither
should an OCSP server bake bread, but I didn't think it
necessary to point this out.

A potential improvement in degree of freshness is inherent in
the use of nonces.  This is, however, a secondary effect.  The
primary purpose of nonces is to address replay attacks:

"4.4.1  Nonce
The nonce cryptographically binds a request
and a response to prevent replay attacks."

Any secondary interpretation of nonce extension usage that
preserves this primary effect is arguably conformant.

Any secondary interpretation of nonce extension usage that does
not preserve this primary effect is by definition
non-conformant.

Mike