Hi Stephan, >> "Also: the mentioned sha1 transform is also a HMAC construction and >> technically >> safe to use (for now), same as the PRF." > > I don't get how this could be ? SHA-1 for signage and hash generation is > colliding. How can it be that this doesn't apply for iked ?
It is true that there have been several successful collission attacks against SHA-1 in the last years and it is NOT safe to use plain sha-1 as a integrity verification hash nowadays, but there are exceptions. So what can an attacker do with these attacks? Given a sha-1 hash 'h' of some arbitrary bytestring 'a', an attacker utilizing the attack could in the worst case craft a second bytestring 'b' which would generate the same sha-1 hash value 'h'. For this to work, the attacker must be able to control the input to the hash function, in this case 'b'. Why is this not a problem for iked and esp? ESP and IKEv2 don't use a plain sha-1 hash for the integrity verification but a so called keyed-hash message authentication code (or HMAC) [1]. Given a message m, and our hash algorithm H we don't simply hash the message to get H(m) as the integrity check value (ICV). Instead we compute ICV = H(K XOR opad, H(K XOR ipad, m)), where K is a secret key shared between the two peers (resulting from the previous Diffie-Hellman exchange) and ipad and opad are constant values of: ipad = the byte 0x36 repeated $SHA1-BLOCKSIZE times opad = the byte 0x5C repeated $SHA1-BLOCKSIZE times. This makes things a lot more complicated for the attacker because it requires knowledge of the key K. This kind of HMAC construction is generally assumed to be resistant against chosen-prefix attacks as we have seen the for sha-1, for a more detailed analysis see for example [2]. Indeed even today there is no known attack against HMAC-MD5 in this same construction. That being said, this doesn't mean it is a good idea to use HMAC-MD5 in new applications and it is also a good idea to get rid of sha-1 hmacs wherever we can, which is why your diff is actually perfectly valid. But for today, there is no known attack and it is technically still considered safe to use. This means we actually have the time to make the migration as painless as possible for our users which would require some proper testing and possible a trial period. - Tobias [1] https://tools.ietf.org/html/rfc2104 [2] https://cseweb.ucsd.edu/~mihir/papers/hmac-new.html > > On 02/05/2020 00:03, Tobias Heider wrote: > > On Fri, May 01, 2020 at 11:35:23PM +0200, Stephan Mending wrote: > > > Hi *, > > > > > > this diff removes SHA1 as default transform for integrity algorithms. > > > > > > It's been broken long enough. Let's at least get rid of it in iked's > > > defaults. > > > > > > SHA1 is officially broken since 2011 and there have been doubts about it > > > since 2005. > > > > > > Though using SHA1 in combination with HAMC as pseudorandom function is > > > perfectly fine as of today. > > > > > > > > > OK? > > Thank you for the diff. > > > > It's not as if we haven't thought about removing this transform, but before > > doing so we need to do some testing to ensure we don't break existing > > setups. > > See this mail from yesterday: > > https://marc.info/?l=openbsd-tech&m=158828278120230&w=2 > > > > Also: the mentioned sha1 transform is also a HMAC construction and > > technically > > safe to use (for now), same as the PRF. > > > > > > > > Index: parse.y > > > =================================================================== > > > RCS file: /cvs/src/sbin/iked/parse.y,v > > > retrieving revision 1.99 > > > diff -u -p -r1.99 parse.y > > > --- parse.y 30 Apr 2020 21:11:13 -0000 1.99 > > > +++ parse.y 1 May 2020 21:19:41 -0000 > > > @@ -144,7 +144,6 @@ struct iked_transform ikev2_default_ike_ > > > { IKEV2_XFORMTYPE_PRF, IKEV2_XFORMPRF_HMAC_SHA2_256 }, > > > { IKEV2_XFORMTYPE_PRF, IKEV2_XFORMPRF_HMAC_SHA1 }, > > > { IKEV2_XFORMTYPE_INTEGR, IKEV2_XFORMAUTH_HMAC_SHA2_256_128 }, > > > - { IKEV2_XFORMTYPE_INTEGR, IKEV2_XFORMAUTH_HMAC_SHA1_96 }, > > > { IKEV2_XFORMTYPE_DH, IKEV2_XFORMDH_CURVE25519 }, > > > { IKEV2_XFORMTYPE_DH, IKEV2_XFORMDH_ECP_521 }, > > > { IKEV2_XFORMTYPE_DH, IKEV2_XFORMDH_ECP_384 }, > > > @@ -164,7 +163,6 @@ struct iked_transform ikev2_default_esp_ > > > { IKEV2_XFORMTYPE_ENCR, IKEV2_XFORMENCR_AES_CBC, 192 }, > > > { IKEV2_XFORMTYPE_ENCR, IKEV2_XFORMENCR_AES_CBC, 128 }, > > > { IKEV2_XFORMTYPE_INTEGR, IKEV2_XFORMAUTH_HMAC_SHA2_256_128 }, > > > - { IKEV2_XFORMTYPE_INTEGR, IKEV2_XFORMAUTH_HMAC_SHA1_96 }, > > > { IKEV2_XFORMTYPE_ESN, IKEV2_XFORMESN_ESN }, > > > { IKEV2_XFORMTYPE_ESN, IKEV2_XFORMESN_NONE }, > > > { 0 } > > > > > > ndex: parse.y > > > =================================================================== > > > RCS file: /cvs/src/sbin/iked/parse.y,v > > > retrieving revision 1.99 > > > diff -u -p -r1.99 parse.y > > > --- parse.y 30 Apr 2020 21:11:13 -0000 1.99 > > > +++ parse.y 1 May 2020 21:19:41 -0000 > > > @@ -144,7 +144,6 @@ struct iked_transform ikev2_default_ike_ > > > { IKEV2_XFORMTYPE_PRF, IKEV2_XFORMPRF_HMAC_SHA2_256 }, > > > { IKEV2_XFORMTYPE_PRF, IKEV2_XFORMPRF_HMAC_SHA1 }, > > > { IKEV2_XFORMTYPE_INTEGR, IKEV2_XFORMAUTH_HMAC_SHA2_256_128 }, > > > - { IKEV2_XFORMTYPE_INTEGR, IKEV2_XFORMAUTH_HMAC_SHA1_96 }, > > > { IKEV2_XFORMTYPE_DH, IKEV2_XFORMDH_CURVE25519 }, > > > { IKEV2_XFORMTYPE_DH, IKEV2_XFORMDH_ECP_521 }, > > > { IKEV2_XFORMTYPE_DH, IKEV2_XFORMDH_ECP_384 }, > > > @@ -164,7 +163,6 @@ struct iked_transform ikev2_default_esp_ > > > { IKEV2_XFORMTYPE_ENCR, IKEV2_XFORMENCR_AES_CBC, 192 }, > > > { IKEV2_XFORMTYPE_ENCR, IKEV2_XFORMENCR_AES_CBC, 128 }, > > > { IKEV2_XFORMTYPE_INTEGR, IKEV2_XFORMAUTH_HMAC_SHA2_256_128 }, > > > - { IKEV2_XFORMTYPE_INTEGR, IKEV2_XFORMAUTH_HMAC_SHA1_96 }, > > > { IKEV2_XFORMTYPE_ESN, IKEV2_XFORMESN_ESN }, > > > { IKEV2_XFORMTYPE_ESN, IKEV2_XFORMESN_NONE }, > > > { 0 } >
