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

From: Peter Williams <[email-masked]>
Date: Mon, 22 Jan 2001 11:52:55 -0800

Steve,
 
Thank you for your memo.
 
Let me summarize a requirement of your protocol design that seems to derive
from
your comments:
 
IETF-standardized validation servers MUST respond normally, when in
conforming mode, to a request that
repeats an anti-replay, nonce value. 
 
Peter.
 
-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Monday, January 15, 2001 7:41 PM
To: Peter Williams
Cc: [email-masked]
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?

Peter, 

[Peter Williams]   

Not sure I see the need for the nonce hash tree you described, though it is
a clever approach, but it also might run afoul of the time stamp patents of
some folks. 

[Peter Williams]  

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Jan 2001 18:28:58 -0500

At 11:52 AM -0800 1/22/01, Peter Williams wrote:
>Steve,
>
>Thank you for your memo.
>
>Let me summarize a requirement of your protocol design that seems to 
>derive from
>your comments:
>

Nonces are usually viewed as mechanisms employed by a client to 
detect replays of responses. What you cite is a mechanism for a 
server to detect and reject replays from a client, which is obviously 
quite different. (Maybe it's just me, but I could not figure out what 
you were referring to in your previous, cryptic message that you cite 
below.) It is contrary to many server design notions, in that it 
requires maintaining state for each client, to detect and reject 
reused nonces.  Also, the client and server might employ a lower 
layer protocol that would deal with this problem, securely, obviating 
the need for such measures. But you do raise an interesting point.

So, in response to the question above, no, a server would not be 
required to respond to a replayed request, nor would it be required 
to detect and reject such a response.  Unless we impose constraints 
on clients in their generation of nonces, something that many 
protocols do not do, then a sender might repeat a nonce due to 
inadequate, local PRNG capability. This would subject the client to a 
replay attack, which we would like to prevent. However, do we want to 
reject the request and deny the client service? Maybe that's a good 
way to bring the error the the attention of the client.

Steve

>Not sure I see the need for the nonce hash tree you described, 
>though it is a clever approach, but it also might run afoul of the 
>time stamp patents of some folks.
>
>[Peter Williams]  
>
>Steve