Subject: Re: MD5 value security consideration

From: Graham Klyne <[email-masked]>
Date: Fri, 05 Mar 1999 12:52:42 +0000

At 10:03 04/03/99 -0800, Bill Newman wrote:
>Graham Klyne wrote
>
>> I noticed this in a recent I-D, and thought it might appropriate to mention
>> something similar in the security considerations of our drafts that suggest
>> use of MD5.
>> 
>>    Implementations should take care not to assume that the value of the
>>    Content-MD5: header will always be 24 bytes or less - to avoid buffer
>>    overrun problems.  It would also be unwise to assume that the
>>    characters in an arbitrary Content-MD5: header will be chosen from
>>    the base64 character set mandated by RFC 1864.
>
>Perhaps I'm missing something, but this doesn't look like a special
>security consideration.  It seems to me that in both your I-D and
>mine, the possibility of buffer overflow or unexpected characters for
>hash values has the same security consequences as any other buffer
>overflow ...

I think you're right.  It's just that enough security holes have been
caused by implementation weaknesses in this area that it probably doesn't
harm to remind imlementers at every opportunity.

#g

------------
Graham Klyne
([email-masked])

---

From: Al Gilman <[email-masked]>
Date: Fri, 05 Mar 1999 10:03:07 -0500

>harm to remind imlementers at every opportunity.

The effect Bill seems not to be noticing is that there is more temptation
to place unfounded trust in the type properties of a header which usually
contains a genuine MD5 with restricted characters and fixed length.

This is a general concern for using strong types in header fields.  Not
limited to MD5, but not simply general across all headers.

I would agree with Bill that the proper place to address this security
concern somewhere else, with a pointer from this document and from the MIME
type registration where the field value is given as MD5.

Yet another illustration of why specs for the Net form a Net and should be
written in hypertext.

Al