W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

Re: Content-MD5

From: Ned Freed <ned@sigurd.innosoft.com>
Date: Fri, 03 Nov 1995 20:20:59 -0700 (PDT)
To: Rich Salz <rsalz@osf.org>
Cc: dl@hplyot.obspm.fr, http-wg-request%cuckoo.hpl.hp.com@hplb.hpl.hp.com, dsr@w3.org, fielding@avron.ICS.UCI.EDU, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> >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.

> I do think it is broken.  I exchanged a half-dozen messages with the
> authors.

Why didn't you bring it up on the IETF list or with the IESG? Sending cosmetic
changes to the authors is fine, but sending substantive issues to the authors
is really a pointless waste of time, since the authors are constrained not to
do anything substantive to a document without IETF approval. The most they
could do would be to make the argument for you to the IESG, but it is not
incumbent on them to do so and I for one think its a bit unreasonable to
expect them to.

> The history of this particular RFC is a little funny; it went
> through a long revision time because it was worded badly.  Content-MD5
> has been around for years, the fact that the RFC is just now coming out
> is funny timing.  The phrase "years of compliant behavior" was quoted
> to me by Mr. Gardiner.

I'm not sure what you mean. The original Content-MD5 RFC, RFC1544, is actually
pretty old -- it came out back in November, 1993. Implementations appeared soon
after that and I know of no reports of operational problems. The move to draft
occurred last month, which is a longer wait than the six month required minumum
but not that unusual. This isn't a product of a working group, but not all
standards-track RFCs are.

> Just as HTTP as extension headers, so does IETF email.  Just as HTTP
> is free to accept Content-MD5, the email-wg is free to accept any improved
> header that we come up with here.

This is only partially true. The IETF has a fairly firm policy of not
duplicating work whenever it can be avoided. As such, given the existance of a
standardized, workable scheme that can already be used to perform this
function, it is going to be difficult to obtain approval for another, duplicate
mechanism. I for one would object to it in my capacity as a member of the
applications area directorate.

I don't think a case can be made for having two different mechanisms for email
and HTTP because of some intrinsic difference between the two, so any new
mechanism is basically going to have to replace the old one in order to be
acceptable. And this in turn is going to require that someone come up with a
better argument that the piddly "I don't like its presentation" stuff that
people, myself most definitely included, have given in the past.

> > 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.

> Yes.  Has either "side" made a strong commitment to convergence?

Not as far as I can tell. However, this one of the reasons why we have an area
directorate, an IESG, and an IAB -- these groups are supposed to check up on
things and make sure that different working groups don't go off in widely
differing directions. These groups collectively have the power to override
working group decisions if need be in order to insure convergence where
convergence is appropriate.

> > 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.

> I disagree.  MD5 is routinely used in production RPC systems all the time.
> I expect that for some time most hashes (and signings) will be done off-line
> where speed is not an issue, and also verified while the document is being
> displayed where, again, speed is not an issue.

Hmm. Well, what, exactly, do you disagree with? You say that MD5 is used all
the time in production RPC systems. (I'm well aware of this usage as well as
dozens of other applications of MD5 -- its one of the most widely used digest
algorithms around.) This seems to imply that you are in favor of using MD5. But
then you go on to talk about how performance isn't really relevant. Yet
performance is one of the things that MD5 has going for it -- its a lot faster
than SHA and comparable in performance to HAVAL, which as far as I know is the
only other reasonable choice for a digest algorithm right now.

So which is it? Are you in favor of using MD5 or not? Or is this purely a
"packaging issue" for you rather than an algorithm issue?


P.S. Performance most certainly is an issue in some cases. It may not be for
some MIME-based applications, but as a matter of fact there is considerable
discord in the community because of the use of MD5 in IP security. MD5 is seen
by many as being much too slow, even though its performance is actually pretty
reasonable compared to other digest algorithms. The problem is that the changes
needed to make MD5 perform better have not received anywhere near the public
scrutiny that MD5 has, and thus aren't sufficient to base standards-track
security work on yet. See RFC1810 for details on performance and RFC1828 for
alternatives to regular MD5. But if you're arguing that performance is not
an issue, then there is no need to make provisions in MIME to allow for
faster and simpler digests.
Received on Friday, 3 November 1995 21:04:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:15 UTC