Re: Content-MD5

> Roy T. Fielding writes:

>  > >       o Title, Link, Base, Content-MD5, Content-Language, etc.
>  > > Sorry If I'm completly off base but could this be changed
>  > > into "Content-Checksum:". I'd rather not tie MD5 particular
>  > > *algorithm* to the general 'checksum' *functionality*, (just in case
>  > > MD6 pops out in few monthes for instance...) {Though I currently use
>  > > MD5 as the algorithm currently}

> So because there were a mere 70 lines document (headers dropped)
> written in 1993 (Rfc1544 (hmm, reissued with almost no changes as
> rfc1864 very recently)) *suggesting* the use of a *specific*
> algorithm, for Email should imply that world stopped and that for a
> new proposed protocol (http/1.1) you have to use the same buggy
> specific definition ? No evolution possible ? No new ideas/fixes ever
> allowed ?

Of course evolution is possible. Of course new ideas and fixes are allowed.
However, just as in the case of language tags, you're attempting to engineer an
HTTP-specific solution to a problem the IETF and IESG believes has been solved
for MIME objects already. If you think Content-MD5 is broken it must
be generally broken and any fix that's made should not be specific to HTTP.

If you disagree with Content-MD5 so much, why didn't you challenge its
specification during the last couple of months while it was up for review?

I personally have never cared for the embedding of the algorithm in the  header
name, and I pointed this out when the original proposal was made. I would have
preferred a simple <algorithm-id>,<value> format.  But nobody else objected and
it wasn't that important to me, so the proposal went through anyhow. And nobody
objected during the move to draft either, at least not that I recall.

Its going to be tough to change it at this late date, but if you think you have
a case to make for an alternative by all means present it in the form of a new
specification. That's how it needs to be done. Having two different mechanisms
for mail and HTTP simply encourages everyone who comes along with the new
protocol that uses MIME to roll yet another one of these, and we really
don't need that.

> And you make htpp/1.2 when MD6 or something else pops out ?

One of the advantage of having a separate specification for this is that
you can upgrade it without revising all of HTTP (or MIME for that matter).

In addition, an alternative has already presented itself: SHA.  A partial
attack against MD5 has been presented (den Boer and Bosselaers), and while its
nowhere near what's needed to break the algorithm it is nevertheless worrisome.
SHA also provides a longer hash value than MD5, which is always nice.

You may think that the cryptographic quality of such things isn't an issue in
this application, but this actually isn't true. One possible use of content-md5
is to checksum some external object and include that checksum within a signed
MIME object. In this case the cryptographic strength of content-md5 is a
significant issue.

SHA is, on the other hand, quite a bit slower than MD5 -- less than half as
fast, in fact.

My position at the present time is that the relative speed issues are more
important than the minor observed weakness in MD5. This is especially true
given the relative infrequency of use of content-md5 to actually provide some
form of security, so RFC1874 is acceptable to me for the time being. But that's
just my take on the situation.

				Ned

Received on Friday, 3 November 1995 17:43:06 UTC