Digest mess

Where is that "eject" button when you need one?

I think the time has come to declare Digest as dead.  Dead because
it was stuffed with featuritis in an attempt to solve multiple
authentication and security concerns instead of the only one for which
it was originally designed.  The current definition seems to have lost
all of the advantages it had over transport-level encryption, without
any of the additional security/privacy attributes of TLS/SSL, and has
become just as difficult to implement.  Now it doesn't even support
non-shared caching.

>Fundamentally, good crypto practice says that EVERYTHING should be in the
>digest. It is almost impossible to figure out every possible attack that
>someone might make by being able to modify an undigested field, so the only
>safe thing to do is digest them all.

Good crypto practice usually involves well-defined encapsulation of what
is being digested/signed, preferably at multiple levels so that the
signature can be signed as well.  There are many ways to do this effectively,
and several proposed standards already exist for doing it with MIME
multiparts.  Why not separate these features (which nobody currently
uses because no UA supports it) from the comparatively simple act
of exchanging authentication credentials?

It's no surprise that Digest doesn't do this well, since originally 
it was not intended to do it at all.

>For HTTP that proved to be infeasible. Some fields really have to be
>modified by proxies. (Those could still be included in the Proxy-Auth,
>though... I hadn't thought of that, because the proxy auth was added
>later... but anyway...) The fields that _really_ have to be modifed can't be
>in the digest.  I see no compelling reason for L-M or Expires to be changed
>by a proxy, and it's plausible that severe service degradation (forcing lots
>of cache misses) could be caused by an attacker changing them. Or that an
>attacker could feed you an old response with recent L-M. Maybe these aren't
>actually problems, but it's a lot of work to validate that they aren't, and
>we haven't demonstrated harm by including them. So, I see no reason to
>remove them from the digest.

If you don't separate message-level metadata (like Date) from what you
are digesting, then the mechanism has broken its transfer-independence
quality.  Losing that quality means that Digest has no advantages over
just using TLS (SSL, whatever).

Service degradation is not an issue -- that can be accomplished more
effectively by changing the digested part so that it no longer matches
the digest and thus force a reset of the whole process.

....Roy

Received on Monday, 15 December 1997 22:22:36 UTC