RE: DISCUSS: MUST reject in OCSPv1

["Ryan M. Hurst" <rmh@xxxxxxxxxxxxxxxxxxxxx>]

Comments in line

-----Original Message-----
From: David Engberg [mailto:dave@xxxxxxxxxxxxxx] 
Sent: Friday, December 05, 2003 12:01 PM
To: Ryan M. Hurst
Cc: liaquat.khan@xxxxxxxxxxxx; 'Florian Oelmaier'; ietf-pkix@xxxxxxx
Subject: Re: DISCUSS: MUST reject in OCSPv1


The value of 'nonceUnsupported' is to allow a client to distinguish 
between 'a' and 'b' securely if that client cares about the difference 
between the two.  Without this mechanism, the client cannot securely 
tell the difference.

It sounds like the argument is that no client will/should ever care 
about this distinction.  This is an argument about "business case" 
rather than technology/security.
[rmh] I suppose so, I just don't see what the client would do with this
distinction; that's not to say there isn't something useful to be done
with it I just don't see it right now.

I believe that it would be valuable for many clients to make this 
distinction.  It allows a local security policy that permits 
interoperabitliy with certs (e.g. SSL certs) from all sorts of 
environments (e.g. with AIA fields).  I'd say clients would use this to 
implement a "use the security model that the server chooses" policy. 
 Not every client or user would choose this policy, but I believe some 
clients would do so if permitted.
[rmh] Is that useful? How is that any different than saying don't
require nonces from this server?


The presence of a 'nonceSupported' extension doesn't just permit replay,

it encourages it (i.e. caching). The 'nonceSupported' extension may also

indicate that that server is not vulnerable to key compromise or DoS 
attacks, and a client may choose to use that securely-transmitted 
information in its decision making.
[rmh] I see what you're trying to get across here, but there may be
other reasons a responder may not be able to include a nonce; for
example as a mater of configuration it is possible that a responder
still has a key but for performance it still only issues pre-generated
responses. 


Ryan M. Hurst wrote:

> comments in-line
>
>
------------------------------------------------------------------------
> *From:* David Engberg
> *Sent:* Fri 12/5/2003 11:17 AM
> *To:* Ryan M. Hurst
> *Cc:* liaquat.khan@xxxxxxxxxxxx; 'Florian Oelmaier'; ietf-pkix@xxxxxxx
> *Subject:* Re: DISCUSS: MUST reject in OCSPv1
>
>Unfortunately, I think the anwer to Ryan's specific question is no.  If

>you send a nonce and get back a response without that nonce under the 
>current spec, you know either:
>
>   a)  The server does not support nonces
>   b)  An attacker is replaying a recorded response from a 
>nonce-supporting server
>  
>
>[rmh] This is absolutley true, but in either of these cases if the
client is attempting to protect against replay he would reject responses
in both a and b. And in not he wanted the "replay" (eg he wants caching
wherever he can get it)
>
>I think there needs to be another flag in the response (e.g. 
>nonceUnsupported extension) to securely separate 'a' from 'b'.
>[rmh] But what prevents the nonce unsupported response from being
replayed?
>
>Ryan M. Hurst wrote:
>
>>   1.
>>       What the responder returns if it can not return a nonce
>>   2.
>>       What the client must do when it receives a response to a nonced
>>       request
>>
>...
>
>> My take on #1 is that I don't see why the client needs to know that, 
>> after all if the response to a nonced request does not contain the 
>> same nonce doesn't that mean the server was unable to produce a
nonced 
>> response?
>
>
>
>  
>