> On Oct 27, 2020, at 19:44, Michael Richardson <mcr+i...@sandelman.ca> wrote:
>
>
> <#secure method=pgpmime mode=sign>
>
> Daniel Migault via Datatracker <nore...@ietf.org> 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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls