<#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, 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.
Certainly from an IOT point of view, an algorithm that has no code is more
secure than one with code.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] mcr@xxxxxxxxxxxx http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
