- From: John Franks <john@math.nwu.edu>
- Date: Thu, 18 Dec 1997 22:27:51 -0600 (CST)
- To: Scott Lawrence <lawrence@agranat.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, jg@w3.org, paulle@microsoft.com
On Thu, 18 Dec 1997, Scott Lawrence wrote: > > > 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). > I think the reason for including dates and expires in a digest 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 automatically check for discrepancies. John Franks john@math.nwu.edu
Received on Monday, 5 January 1998 09:51:59 UTC