Re: Security Requirements for HTTP, draft -00

Paul Leach wrote:
> 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.

Yes, but all servers applications must handle that, and it will be
well tested, because it occurs during normal network failures and
client aborts - thousands per day.

> Perhaps most importantly, in both cases no sensitive output can be
> sent to the client.

That's true, but the TLS approach also prevents malicious input
reaching the server application, without needing an unbounded buffer.

> 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.

Well, that's right, but that difference is quite significant for apps
which are written to work with known clients which they trust to
provide requests in a certain form, and aren't robust against
malicious input (or aren't thoroughly audited and tested enough to
trust).  It's not so unusual to put authentication/validation in the
generic server.

-- Jamie

Received on Tuesday, 29 January 2008 16:32:34 UTC