RE: This is not "this is not a date"

There's another solution -- declare that proxies can't add "Date" when
digest is in use, just like we say that they can't change the content
coding. We could allow "Date" to be in the trailer, so that if it really
wants to add it it can. But that seems overkill -- the question really is:
why do we have to allow Date to be added by a proxy?

Let me give some background:

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.

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.

The only problem I can see is that an existing proxy that doesn't understand
Digest and add Date will break digest. But so will an existing proxy that
doesn't understand Digest and reformats Date without changing the value. I
don't see either as a showstopper.

Paul

Received on Saturday, 13 December 1997 12:14:48 UTC