Subject: RE: DPD/DPV reqmts: hash of the request

From: "Housley, Russ" <[email-masked]>
Date: Mon, 4 Mar 2002 09:25:20 -0500

In my opinion, the requirement is to bind the respponse back to the request.
Two obvious was to accomplish this binding are to include all of the fields
of the request in the response and to include a hash of the request in the
response.  Since we are working on the requirements doucment, we should
stict to requirements, not mechanisms for implementing the requirements.

Russ

-----Original Message-----
From: Petra Barzin
To: [email-masked]
Cc: [email-masked]
Sent: 3/3/02 3:48 PM
Subject: DPD/DPV reqmts: hash of the request 

Denis, 

I don't see why you differentiate between signed and authenticated 
responses. The same is true for signed responses: either the hash of 
the request or the important elements from the request must be present. 
In order to test the response against what has been requested the client

has to keep his request or at least the hash of his request. 

The advantage of a hash - instead of copying all important elements 
from the request -  is: 
(a) that the response will be smaller and 
(b) adding a new important element to the request doesn't require a 
change of the response. 

- a hash of the request MUST be included in the response.

  This may allow the client to check if his request was maliciously

  modified (if the response is signed) and helps to associate the

  response with his request when using connectionless protocols.

  [Answer 1] The requirements are different whether the requester simply
wants

  an authenticated response or a signed response. For a signed response
the

  inclusion of the important elements from the request is needed, so
that a

  response can be individually tested against what has been requested.
For an

  authenticated response, the hash of the request is sufficient. To
summarize:

  - for signed responses, the important elements from the request

    must be present.

  - for authenticated responses, either the hash of the request or the

    important elements from the request must be present.

- Petra

---

From: "Michael Myers" <[email-masked]>
Date: Mon, 4 Mar 2002 08:54:40 -0800

Russ,

This also breaks pre-produced responses, a practice that can
reduce latency.  Is this collateral effect intended?

Mike

> From: Housley, Russ
> In my opinion, the requirement is to bind the
> response back to the request.

---

From: Petra Barzin <[email-masked]>
Date: Tue, 05 Mar 2002 21:17:16 +0100

Yes, the requirement is to bind the response back to the request!
Sorry for the technical discussion at this point.
I'd see the requirement as a MUST, but I can see Michael's concern
that it prevents the use of pre-produced responses.
But I think it is very important that the sender of a DPV request
is able to match the received response to his request in order to
make sure that no man in the middle changed his validation request.

- Petra

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 5 Mar 2002 12:29:48 -0800

Petra,

In my opinion we should enable the practice by ensuring the
capability is in running code but not mandate its use in all
circumstances.  Do you find this approach acceptable?

Mike

> From: Petra Barzin [mailto:[email-masked]]
> Sent: Tuesday, March 05, 2002 12:17 PM
> To: Housley, Russ
> Cc: [email-masked] '; [email-masked] ';
> [email-masked]
> Subject: Re: DPD/DPV reqmts: hash of the request
>
>
> respponse back to the request.

---

From: Petra Barzin <[email-masked]>
Date: Wed, 06 Mar 2002 22:36:37 +0100

Mike,

do I understand you correctly, that you propose to mark the
requirement (binding the response back to the request) as
optional and leave it up to the implementation of the DPV
client and server to realize this binding?
I'm afraid this will lead to unnecessary interoperability problems
between implementations of a DPV client and server, e.g. if a
client implementation requires this binding, but it's not implemented
at the server. If we feel that the binding adds value to the protocol
- and I think it does - we should mandate its use! You can still
cache the information and re-use them, you just cannot preproduce
the whole response.

Petra

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 6 Mar 2002 14:44:41 -0800

Petra,

The proposal is that both client and server are forced to have
this functionality in their code in order to claim compliance,
but that use of the functionality is a local matter.

Peter Sylvester's proposed text had it just about right:  "The
protocol MUST provide a means permitting a client to associate a
response to a request."  The key phrase there is "provide a
means".  In my view, "provide a means" means every client and
every server is functionally capable of one-to-one binding, but
MAY be operated in a fashion that does not support the practice.

This operational flexibility would be most relevant to those
environments who find the latency reduction effects of
pre-produced responses useful to their associated community.
More rigorous environments, such as those you may be
representing, are nonetheless assured that the functionality you
need will be there no matter what implementation you choose to
use.

But given the assurance of implementation compliance, these
issues can be resolved via a simple config file change or
whatever other means is used to control the behavior.  An
obscure Windows registry tweak or whatever.  The important thing
is that the functionality be there to enable that operational
negotiation.  I think that's the best we can do given the
diverse communities we serve.

If however you are advocating for a uniform operational
practice, we should probably strike a new thread on that one.

Mike

> Sent: Wednesday, March 06, 2002 1:37 PM
> To: Michael Myers
> Cc: Housley, Russ; [email-masked]; [email-masked]