Re: [TLS] [Last-Call] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Sean Turner <[e-mail]>]

> On Oct 27, 2020, at 19:44, Michael Richardson <[e-mail]> wrote:
> 
> 
> <#secure method=pgpmime mode=sign>
> 
> Daniel Migault via Datatracker <[e-mail]> wrote:
>> RFC6194 may be mentioned as a reference for
>> not deprecating HMAC-SHA-1 as well as an
>> additional reference to [NISTSP800-131A-R2].
> 
>> Reading the text the situation of HMAC with
>> MD5 is unclear. Since we specify that SHA-1
>> is not deprecated for HMAC we may specify
>> the status for HMAC with MD5. Given RFC6151 I
>> hope the reason is that MD5 and HMAC-MD5 has
>> already been deprecated but I have not found
>> this. Maybe that would worth mentioning it
>> is deprecated already.
> 
> My understanding is that despite the flaws in MD5, HMAC-MD5 is still
> resistant to second pre-image attacks.
> RFC6151 is pretty clear about the state of things,

Well it was the state of things in 2011. But, I am pretty sure we have heard something by now (or this thread will prompt a response from somebody who knows more).

> but let me tell you about
> the hassle of explaining this to end users.
> The two rounds that the HMAC construct uses mean that only way to get past it
> is with a brute force attack.
> 
> I rememeber back in 1995ish, when Hugo insisted with do HMAC.
> We hated it because it made hardware.  He clearly knew something!
> 
> I agree that this document should probably quote more of RFC6151 when it
> comes to HMAC-MD5.
> 
> My best advice for why we deprecate HMAC-MD5 (and HMAC-SHA1) is because end
> users are confused and/or alarmed if the strings "MD5" or "SHA1" occur in
> their logs.


This was the reason I wrote RFC 7093 (Additional Methods for Generating Key Identifiers Values), which ended up going through the ISE stream. I wanted to avoid having to explain that key identifiers were generated with SHA-1 but that was okay. Better to just avoid the darn algorithm.

spt