Re: Content-MD5

At 9:21 AM 11/6/95, Laurent Demailly wrote (quoting Dave Kristol):
> > I have headers
> >      Content-MD5: xyz
> >      Content-SHA: qrs
> > The recipient computes the digests of the message and finds that the MD5
> > digest matches xyz, but the SHA digest does not match qrs.  Now what?
> > I imagine we assume the integrity to be compromised.
> > With a single Content-Digest header, there's no ambiguity.
>
>Ahem, the mecanism I suggested does not state you have only one
>algorithm key pair, you can have one or more (maybe that's not a good
>thing, and can be changed,... but..)

No, you want to be able to have more than one digest.  From RFC 1810,
"Report on MD5 Performance," (last para. of "Security Considerations"):

>It is important to the use of authentication in high-performance
>systems that an alternative mechanism be available in IPv6 from the
>outset.  This may require the specification of multiple "required"
>authentication algorithms - one that's slower but believed strong,
>and one that's faster but may inspire somewhat less confidence.

If we pretend for a moment that we really do care about speed issues, and
if we agree with Harald's assertion that Content-MD5 is not intended to
provide security at all, then RFC1810 suggests that we will want some
digest _other_ than MD5 (perhaps the 16-way block chaining solution
proposed in 1810).

However, it is conceivable that someone, somewhere will want a digest that
does provide some strength (perhaps while encapsulating HTTP, which could
make header forgery more difficult).  In that case, they would care very
much about the strength of the digest, and less about speed.  Perhaps,
then, Content-MD5 is a good thing, were its strength not at issue, but
Schneier[1] suspects its strength _is_ at issue; so Content-SHA might be a
better choice for this purpose.

These considerations suggest duplication could be advantageous: one digest
for speed, one for potential security issues.  If those are the axes, then
neither side should be arguing for MD5 as HTTP's digest of choice.
Content-MD5 would only be the best choice if we wanted to fulfill both
moderate security needs and speed optomization in one digest, which we
don't; or if nothing faster than MD5 can be found.  Can anyone say what the
IPv6 people have decided after RFC1810?  Later RFC's suggest they are still
looking.

This still says nothing about whether Content-MD5: xxx (or whatever) should
be preferred to Content-Digest: MD5=xxx.  I prefer the former.  If UA's
normally wanted to send both a digest for speed and one for security, then
Content-Digest would make more sense.  However, that seems to be the less
likely possibility.  It is more likely that every UA will want to send the
speedy digest, and a few here and there will want to send the secure digest
as well.

M. Hedlund <hedlund@best.com>

[1] Bruce Schneier, _Applied Cryptography, Second Edition_ (New York: John
Wiley & Sons, Inc., 1996), 441 (Section 18.5).

Received on Monday, 6 November 1995 17:29:14 UTC