Re: Digest mess

  Extracting some snippets from a couple of recent messages...

>>>>> JF == John Franks

JF> Digest without the optional entity-digest (as in Apache) is
JF> inappropriate for PUT or POST, in any case, as there is no way to know
JF> that a MIM has not tampered with the posted entity.

>>>>> BL == Ben Laurie

BL> If Digest is truly not appropriate for PUT or POST, then
BL> PUT and POST are not appropriate for HTTP (without some stronger
BL> authentication).

>>>>> DK == Dave Kristol

DK> We started Digest (does anyone remember "SimpleMD5"?) with a goal of
DK> eliminating cleartext passwords.  That design goal was achieved ages
DK> ago.  Since then we've added neat functionality to try to identify when
DK> the message has been modified or replayed.  Now, nonces can guard
DK> against replay.  I'll assert that the additions, to guard against header
DK> mucking, are misplaced:  if you want to assure message integrity, use
DK> something like SSL.  Yes, it's heavier weight, and you might like to get
DK> by with something cheaper.  But message integrity (and confidentiality)
DK> is what you get with SSL.

DK> My summary:  let's return Digest to its original purpose, avoiding
DK> cleartext passwords.  Let's not try to impose on Digest capabilities for
DK> which it was not intended.

JF> On the other hand, we could simply eliminate all optional features
JF> from digest and you and other interested parties could start work on
JF> "digest-ng."

  - Without at least a limited mechanism for message integrity, no
    scheme is useful for POST or PUT.

  - A scheme that won't work through proxies that don't understand it
    isn't deployable and won't be accepted.

  I, for one, would oppose advancing any derivative of the current
  draft without addressing these problems.

  I have already said that I think that we will need to change the
  scheme identifier token anyway because the entity digest calculation
  will need to change [both to remove certain header fields and
  possibly also to change from H(A1) to H(H(A1))].

  Perhaps it _is_ time to admit that we need a major rewrite and call
  it something else.  I hope that can be avoided, but I volunteer if
  it can't be.

Scott Lawrence           EmWeb Embedded Server       <>
Agranat Systems, Inc.        Engineering  

Received on Tuesday, 6 January 1998 16:03:19 UTC