Many thanks for all of the comments. I feel that AUTH_HMAC_SHA1_96 should be formally deprecated not necessarily for its security* relative to the deprecated AUTH_HMAC_SHA1_160, but for purposes of consistency, clarity and in support of a broad migration away from SHA-1 dependencies.
I’m a relative newcomer to IETF and it may be that the administrative and process overheads are excessive for these goals and I am happy to take guidance on this point. Best regards, Daniel *- For the record I assess the relative security as 48-bits vs. ~60-66-bits of non-repudiation security; 2^-96 vs. 2^-160 bits of security against opportunistic modification; (key length)/96 matched message/tag pairs vs. (key length)/160 message/tag pair data requirement to conduct a key recovery inversion. I make no claim as to whether these make a material difference to the security against any given attacker model and use case. From: Hugo Krawczyk <h...@ee.technion.ac.il> Sent: Thursday, August 8, 2024 4:58 PM To: Scott Fluhrer (sfluhrer) <sfluhrer=40cisco....@dmarc.ietf.org> Cc: Benjamin Kaduk <ka...@mit.edu>; Michael Richardson <mcr+i...@sandelman.ca>; Daniel Shiu <daniel.s...@arqit.uk>; ipsec@ietf.org Subject: Re: [IPsec] Re: AUTH_HMAC_SHA1_96 not formally deprecated I agree with the comments in this thread regarding the security of a 96-bit MAC assuming the MAC function is also a PRF (which we assume HMAC to be). This is what Scott is pointing out. An old paper of Prennel and van Orschot also makes the case for truncation as adding security (Uri mentions that). The reason people are allergic to shortened tags is because of the risk of collisions in the context of collision-resistant hash functions. MAC functions do not have to be collision-resistant (this is why HMAC-SHA1 still seems to survive in spite of collision attacks on SHA1). However, people have abused MAC values as commitment values, e.g., for channel binding, where collision resistance is required, which led to actual attacks. This was the wrong use of MAC values but overall, if shortening is not considered to have strong reasons, may it is better not to (I refer to this as robustness against future mistakes or changes in functionality). A different but related example is the use of outputs from KDF also for channel binding (e.g., producing exporter_master_secret in TLS 1.3) where collision resistance is needed (as pointed out is rfc8446). So while 128-bit keys may be appropriate in some settings, binders of that size are not. Bottom line: Truncated values to 96 bits lead to secure MAC but may not be sufficient when these values are (ab)used for other purposes. Hugo On Tue, Aug 6, 2024 at 3:01 PM Scott Fluhrer (sfluhrer) <sfluhrer=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>> wrote: > -----Original Message----- > From: Benjamin Kaduk <ka...@mit.edu<mailto:ka...@mit.edu>> > Sent: Tuesday, August 6, 2024 1:17 PM > To: Michael Richardson <mcr+i...@sandelman.ca<mailto:mcr%2bi...@sandelman.ca>> > Cc: Daniel Shiu <daniel.s...@arqit.uk<mailto:daniel.s...@arqit.uk>>; > ipsec@ietf.org<mailto:ipsec@ietf.org> > Subject: [IPsec] Re: AUTH_HMAC_SHA1_96 not formally deprecated > > On Tue, Aug 06, 2024 at 12:31:21PM -0400, Michael Richardson wrote: > > > > Daniel Shiu <daniel.s...@arqit.uk<mailto:daniel.s...@arqit.uk>> wrote: > > > While working on cryptographic inventory tools, I noticed that the IKE > > > authentication methos AUTH_HMAC_SHA1_96 (SHA1-based HMAC > truncated to > > > 96-bits) is permitted in IKEv2 per RFC 8247 (status MUST- > > according t > > > > Note, it's *HMAC* SHA1. > > > > > Have I missed the deprecation elsewhere, or is further action merited. > > > > HMAC consists of two passes of SHA1, and includes padding in such a > > way that means that pre-image attacks where the attack text is longer > > than the original does not work. > > > > So, I am not falling overmyself to deprecate HMAC-SHA1. > > I'm happy to leave things as they are until a revision to 8247 is done. > > Note that MUST- means that it is already on it's "way down" > > The truncation to 96 bits is probably worth a bit of worry in this era (though > not an extreme amount of worry). Note that Kerberos for a long time only > had AES-CBC-HMAC-SHA1-96 as its strongest enctype but published RFC 8009 > back in 2016 to rectify that (with both a longer authentication tag and the > more modern hash for HMAC), and as I understand it the new enctype has > gotten pretty good uptake. > At the time, the truncated tag was far more of a concern than the SHA-1 > usage (in HMAC). I don’t see how a truncated tag would be much of a concern (either back then or now). To exploit it, what an attacker would have to do is generate his ciphertext and then apply a guess of what the tag would be. Then, he would submit his ciphertext/guessed tag to the decryptor, and hope that the decryptor generated the same tag. Now, with a 96 bit tag, his guess would be correct with probability 2^{-96} (with HMAC not giving him any way to increase this probability). That is, to get a single forgery through with probability 2^{-20}, he'd need to present to the valid decryptor 2^{76), that is, 75,557,863,725,914,323,419,136 packets with different guesses at the tag. I believe that this is approximately the number of packets flowing over the entire global internet in an hour - all directed towards our device under attack. Needless to say, there is no device that would process this much data in any reasonable amount of time. So, what's the difference between this, and a ciphertext encrypted with a 96 bit key? Well, in the 96 bit key case, the attacker can test various keys on his own devices, and can easily (given a large budget) build a huge computing base that can test an enormous number of keys at once. In the 96 bit tag case, the attacker cannot test an enormous number of tags at once - instead, he needs to submit each guess at a tag to the valid decrypter, who will accept queries only as fast as he cares to, and a well-funded adversary cannot speed it up. [Sorry for the rant - I think this point is missed far too often, and it bugs me] _______________________________________________ IPsec mailing list -- ipsec@ietf.org<mailto:ipsec@ietf.org> To unsubscribe send an email to ipsec-le...@ietf.org<mailto:ipsec-le...@ietf.org> CAUTION: External Sender. This email originated from outside of Arqit. Do not click links or open attachments unless you recognize the sender and know the content is safe. CONFIDENTIALITY NOTICE: This e-mail message and any attachments are only for the use of the intended recipient and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, any disclosure, distribution or other use of this e-mail message or attachments is prohibited. If you have received this e-mail message in error, please delete and notify the sender immediately. Thank you.
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
