Subject: RE: DISCUSS: MUST reject in OCSPv1

From: "Ryan M. Hurst" <[email-masked]>
Date: Thu, 27 Nov 2003 13:21:44 -0800

cil

________________________________

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

Ryan M. Hurst wrote:
> I don't think its silly, the client is still protected from the replay
> if the server responds to a nonced request with a un-nonced one as the
> client can decide decide if he wanted the protection or needed it.

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

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.

> That may sound strange, but nonce has other implications that re-play
> protection; it also implies freshness since pre-produced responses can
> not have the right nonce in it.

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.

                M.

---

From: Marc Branchaud <[email-masked]>
Date: Thu, 27 Nov 2003 13:49:36 -0800

Ryan M. Hurst wrote:
> [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.

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.

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

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

		M.

---

From: "Florian Oelmaier" <[email-masked]>
Date: Fri, 28 Nov 2003 01:14:55 +0100

Your argument is "nonces are only for replay protection". Thats true.

Now lets discuss WHY a client wants to get replay protection. Seeing
that we have the three times in the response with a clear semantic, the
client is not harmed by a replay. So why should a client include a nonce
into the request?

There are different reasons for that, but the main reason is: the client
wants a "fresh" response. Following that path Ryans arguments apply as
he presented it in his previous replies. A client will include a nonce
into the request to ask for a "fresh" response. If the client does not
need a fresh response, then replaying is not a problem (then it is a
feature called "caching").

So if a responder gets a request with a nonce, it not only means "the
client wants replay protection" - it also means "the client would like
to get a fresh response". Because otherwise replay attacks would not
matter.

-- 
Florian Oelmaier
SyTrust

---

From: Marc Branchaud <[email-masked]>
Date: Thu, 27 Nov 2003 16:23:47 -0800

That's all fine.  Really!

But why would the client not care if the nonce is echoed in the response?

The client should only ask for a fresh response if it really wants one. 
To make frivolous requests for freshness would unnecessarily tax a 
server that actually cares and tries to fulfill the requests.

In the end, making the requirement anything less that "MUST reject" will 
lead to servers simply ignoring the nonce extension altogether.

		M.

---

From: "Ambarish Malpani" <[email-masked]>
Date: Fri, 28 Nov 2003 14:00:55 -0800

Hi Florian,
    The reason for including a nonce in the request is to enable a
client that doesn't have a very precise knowledge of time to still
be sure the response he got from the server was generated for this
specific request.

While I do agree with Mark and think that the "right" way would be
to require the client to require the nonce in the response, in the
interests of moving ahead, I vote to accept Mike's compromise
proposal that a client MUST require the nonce in the response
unless it is accompanied by a nonceUnsupported extension in
the response and the client is willing to accept a response w/o
a nonce. This preserves the semantics for current clients and
still allows caching servers to supply responses to clients
who will take them.

Regards,
Ambarish

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Florian Oelmaier
> Sent: Thursday, November 27, 2003 4:15 PM
> To: 'Marc Branchaud'; [email-masked]
> Subject: RE: DISCUSS: MUST reject in OCSPv1
> 
> 
>