> On Oct 27, 2020, at 19:44, Michael Richardson <mcr+ietf@xxxxxxxxxxxx> wrote: > > > <#secure method=pgpmime mode=sign> > > Daniel Migault via Datatracker <noreply@xxxxxxxx> 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
