Re: Digest mess
- On Thu, 18 Dec 1997, Scott Lawrence wrote:
>I think the reason for including dates and expires in a digest
> In http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q4/0481.html
> John Franks says:
> JF> ... adding a field to the Authentication-Info
> JF> header could solve the problem by duplicating the headers which
> JF> a proxy might change. I have in mind something like
> JF> dheaders = "date:content_len:L-M-date:expires"
> JF> John Mallery points out that it would be good to have the response
> JF> status code digested as well. If it is included here that becomes
> JF> possible (which it wasn't before since proxies change it from
> JF> say 304 to 200). This header would also eliminate problems of
> JF> proxies canonicalizing headers.
> This would work in terms of preserving the computability of the
> digest value. The problem I see with it is that it doesn't really
> do anything for the security but prevent a denial of service attack
> (which is unstoppable if the attacker can modify any part of the
> message anyway).
is to prevent replay attacks. There are many cases where not
only is the information important but the date it was sent is
important (think of a stock quote, for example). The motivation
for including the response status value in the digest is to
have the response from a PUT essentially certify that the
PUT succeeded. For this to be meaningful it also needs a date.
There are ways to achieve the same thing, like putting duplicates
of the headers in the message body, but if there is no standard
way to do that then clients can't automatical
- I believe there is rough consensus for moving forward with
digest limited to its role as a replacement for 'basic' that
doesn't provide for message integrity. John Franks will work
with Jim Gettys on replacement text. We need not discuss
the matter further until there's a revised draft to consider.
Let's move on.
Larry (as WG chair)