RE: Digest mess

> ----------
> From: 	Scott Lawrence[SMTP:lawrence@agranat.com]
> Sent: 	Tuesday, December 16, 1997 6:46 AM
> 
<snip>

>   However, some entity digest capability is absolutely required
>   because it is the message we are authenticating - it does no good to
>   send credentials if the entity is not tied to them.
> 
Absolutely correct.

> PL> Fundamentally, good crypto practice says that EVERYTHING should be in
> the
> PL> digest. It is almost impossible to figure out every possible attack
> that
> PL> someone might make by being able to modify an undigested field, so the
> only
> PL> safe thing to do is digest them all.
> 
>   But we also face the backward compatibility problem - we know
>   for sure that the current scheme is broken in the face of proxies.
> 
Which proxies?  I've asked a couple of time whether there are any proxies
that will add Date if it doesn't exist -- no answer yet.

> RF> Service degradation is not an issue -- that can be accomplished more
> RF> effectively by changing the digested part so that it no longer matches
> RF> the digest and thus force a reset of the whole process.
> 
>   I agree that service degradation and cache efficiency should not be
>   our concern here - what is desperatly needed is a lightweight
>   mechanism for authentication, and if that means that caches can't
>   cache, well so be it.
> 
Fine.

>   I posted a proposal last Friday
> 
>     http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q4/0390.html
> 
>   to simplify the entity digest calculation by removing all the
>   metadata headers; should I rewrite this in the form of an Internet
>   Draft, or can we just debate it and possible other solutions here?
> 
Let's debate it here. Just as with Date, I've seen no reason to remove LM
and Expires, becuase no one has said that their proxy mucks with them.

Received on Tuesday, 16 December 1997 11:16:48 UTC