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

From: Peter Williams <[email-masked]>
Date: Wed, 24 Jan 2001 13:42:15 -0800

Steve, 

Thankyou for your dissmisive comments.

Thankyou also for your disclosure of what you know about 
the use of hash-trees in patents. Your introduction of 
timestamping IP into a thread on (timed) nonces was 
suprising, per se.

I deduce from the your many memos discussing (somewhat vaguely 
expressed) requirements that you personally see no real 
vulnerability in a validation server responding to 
replayed client requests. Perhaps you view it as a function
of the underlying transport to be guarding against availability
threats? 

As a model for the design of authenication elements of a DPV
service, which IETF protocol's use of signed, nonce and 
anti-replay handling do you view as examplary and a practice 
to be followed? I will summarize its design for the list. 

With this information, we can begin
to comprehend which security service DPV users will be invoking
when applying the digital signature mechanism. Understanding
the authentication requirements is a useful contribution
at this stage, given the current lack of perceived clarity 
on how intelligent the DPV client is supposed to be.

Peter.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 24 Jan 2001 21:28:47 -0500

Peter,

>Thankyou for your dissmisive comments.

You earned them as a result of many messages over the last several 
years; I finally decided to vent.

Peter, you're a very smart guy and I value your contributions. But 
your intelligence does not contribute to helping PKIX do its work 
when you cloak it in language that is almost impenetrable.

>timestamping IP into a thread on (timed) nonces was

I explained why I did it, confused as I was by your 
characteristically terse comments.

>of the underlying transport to be guarding against availability

Vaguely expressed requirements? As opposed to the crisp set we had on 
the table when I posted my draft requirements?  Maybe you sent a 
lengthy message contributing to the clarification, but I missed it.

Of course it's preferable to design the protocol to allow for use of 
a countermeasure that allow's a server to guard against replays, but 
we have many options, depending on the context. In a public DPV 
server context one might imagine using IPsec or TLS to authenticates 
the client, for billing purposes, and those protocols address the 
replay problem. So, the question is whether we want to mandate an 
anti-replay facility in DPV and DPD, separate from what might be 
provided at a lower layer. And, if so, do we further mandate server 
behavior re rejecting replays. The former sounds reasonable, the 
latter is less clear. For example, in a corporate environment any 
added burden imposed by a countermeasure for server anti-replay may 
not be deemed worthwhile.  Also, while I do sincerely applaud your 
mechanism for keeping track of nonces via a hash tree, it would not 
be appropriate in a standard, since it is an optimization of what is 
purely a local implementation issue, right?

>to be followed? I will summarize its design for the list.

Thanks for the offer, bit it may be premature. First, we have not 
agreed on the form of the service we need to provide here, 
specifically whether we need to provide protection for server 
anti-replay vs. client anti-replay. Second, I don't think I have held 
out any specific IETF protocol as a model for this context. I guess I 
could look at what we did for TSP, which the WG and the IESG 
approved. I don't recall your commenting on that mechanism as being 
deficient re server anti-replay. If you didn't consider it a 
requirement for that protocol, why is it a requirement here?

>on how intelligent the DPV client is supposed to be.

As a user of this service I doubt that I care whether I am invoking a 
server anti-replay service.  Also, anti-replay in a connectionless 
communication environment is usually viewed as an integrity service, 
not an authentication  service.

Steve