[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Peter,

Steve,

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.

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 explained why I did it, confused as I was by your characteristically terse comments.

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?

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?

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.

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?

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.

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