Re: MD5 value security consideration

At 12:52 PM 3/5/99 +0000, Graham Klyne wrote:
>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.
>

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


>#g
>
>
>------------
>Graham Klyne
>([email protected])
>