W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

RE: Security Requirements for HTTP, draft -00

From: Paul Leach <paulle@windows.microsoft.com>
Date: Tue, 5 Feb 2008 17:23:41 -0800
To: Robert Sayre <rsayre@mozilla.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <920B8B05FB49A04699188E04302FE87D592D40FADC@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com>


From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org] On Behalf Of Robert Sayre
Sent: Thursday, January 31, 2008 12:26 AM

Servers need to be able to ignore message bodies from clients that don't know the shared secret. auth-int requires that the server buffer the entire request before determining that the client knows the shared secret.
[Paul Leach] I agree that this is true, but I don't this is the best way to help people understand the problem. To see this, imagine that the client sent both an "auth" response and an "auth-int" response (disregarding whether that is currently legal). The "auth" response would prove that the client knew the shared secret before the message body is recieved, but that doesn't mean that the server should accept the message body: it still has to wait until it has determined that it hasn't been tampered with by a man-in-the-middle.

Here's another shot at proposed wording:


"Digest includes many modes of operation, but only the simplest modes enjoy any degree of interoperability.  For example, most implementations do not implement the mode that provides full message integrity.  Perhaps one reason is that implementation experience has shown that in some cases,

especially those involving large requests or responses such as streams, the message integrity mode is impractical because it requires servers to analyze the full request before determining whether the client knows the shared secret or whether message-body integrity has been violated and hence whether the request can be processed."
Received on Wednesday, 6 February 2008 01:24:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:36 GMT