RE: Security Requirements for HTTP, draft -00

I don't see the distinction you claim. In either case, if you pass any data of a request to the server application before the whole request has been received and verified, then if the verification fails are any point, any processing done up to that point has to be undone. Perhaps most importantly, in both cases no sensitive output can be sent to the client.

Another way of looking at it is that, as far as I can tell, any scheme that works with TLS and allows for a failure on the last chunk of the request would work with auth-int -- the only difference is that auth-int can _only_ fail at the end.

More inline.

-----Original Message-----
From: Jamie Lokier [mailto:jamie@shareable.org]
Sent: Monday, January 28, 2008 12:55 PM
To: Paul Leach
Cc: Paul Hoffman; ietf-http-wg@w3.org
Subject: Re: Security Requirements for HTTP, draft -00

It is more expensive than TLS, because TLS integrity is checked per
chunk.

TLS allows the message integrity to be checked for each chunk as it is
arrives, so a request can be accepted, then streamed to the server
application as it arrives.  If a check fails, the request is aborted,
and the application never sees any of the failing data, so it cannot
trigger exploits.
[Paul Leach] Maybe I am just completely missing something -- first you say that the request is streamed to the server application as it arrives, then you say that if the request is aborted, the application never sees any of the failing data. Which is it? Is there some subtle distinction between "server application" and "application" that I'm missing?

Also, a failure is handled the same as a connection
failure in mid request, so well tested code paths are used.

With digest "auth-int", the message integrity cannot be checked until
it has all arrived.
[Paul Leach] Neither can it with TLS. Chunk integrity is not message integrity.

Received on Monday, 28 January 2008 22:59:11 UTC