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: Wed, 30 Jan 2008 11:42:04 -0800
To: Jamie Lokier <jamie@shareable.org>
CC: Paul Hoffman <paul.hoffman@vpnc.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <920B8B05FB49A04699188E04302FE87D592CDBEDA8@NA-EXMSG-W602.wingroup.windeploy.ntdev.microsoft.com>

OK, I think I understand. Let me sum up by proposing alternate wording, then do some more analysis (about which no one may care much but me).

Alternate wording:

"Additionally, 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 message integrity has been violated and hence whether the request can be processed."


In the case where the server knows nothing about the semantics of the request or the capabilities of the server application, I believe that it has no choice but to hold the request until it has determined that nothing has tampered with it -- for both TLS and auth-int.

If something is known about the semantics of the request or of the server application capabilities, optimizations are possible.

For example, if the server app is a database that supports transactions, then the request could be incrementally passed to it, knowing that the transaction can be aborted if and when an integrity violation is detected. Again, this is essentially the same for TLS and auth-int, the only difference being that integrity violation can be detected earlier with TLS.

Similarly, if the request is a file upload, then it can be incrementally processed because the file can simply be deleted if an integrity violation is detected.

Another case is where the semantics of the request are the same as that of some series of smaller pipelined requests, then request processing can be optimized by (logically) transforming it into said smaller requests and performing the smaller requests as they arrive. This describes what happens when the request contains a stream of data, for example. In this case, TLS does have advantages over auth-int, because auth-int prevents such a transformation.

Your previous post mentions some other cases where TLS also has advantages.

Analysis of responses could proceed along similar lines, except that we have a much better idea of the capabilities of most user agents. Hence, we know for example that indefinite streams of output are not practical with auth-int.

I think this reconciles the opinions of both sides -- perhaps in more gory detail than anyone cared to hear, but it satisfied my desire to really understand the issue.
Received on Wednesday, 30 January 2008 19:41:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:44 UTC