Re: Security Requirements for HTTP, draft -00

Paul Leach wrote:
> WRT: "2.2.2.  Digest Authentication
>         ...
>    Additionally, implementation experience has shown that
>    the message integrity mode is impractical because it requires servers
>    to analyze the full request before determining whether the client
>    knows the shared secret."
> 
> Could you elaborate? The purpose of integrity protection isn't
> simply to determine if the client knows the shared secret, it is to
> insure that no MITM can modify the integrity protected data. This
> intrinsically requires that all integrity protected data be
> examined. Hence, the above statement seems to really amount to the
> claim that integrity protection is too expensive to be
> practical. However, it isn't any more expensive than TLS, and TLS is
> used pretty widely.

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.  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.  This means either the whole message must be
buffered by a generic server before passing it to the server
application, or unchecked data is streamed to the server application
with the possibility to tell the application at the end to abort work
it has done.  Buffering is arbitrarily expensive in space and time,
and streaming the data (from generic server to server application)
prior to checking it, with rollback, complicates the interface,
complicates the application, and renders the server vulnerable to
unexpected-input exploits in the application.

-- Jamie

Received on Monday, 28 January 2008 22:25:04 UTC