> On Sep 29, 2015, at 12:15 PM, Tero Kivinen <[email protected]> wrote: > > Yoav Nir writes: >>> Does SHA1 go to MUST-? >>> >>> We hadn't listed SHA2 at all before. >>> We also have no GCM/CCM things specified. >>> >>> Are we obligted to list them as SHOULD+ for awhile? >> >> I think we should reflect what is common/best practice now. AES-GCM >> is now widely implemented and faster than the combination of AES-CBC >> and HMAC-SHA-something. > > Remember that we are talking about the IKEv2 SA now, not ESP, or AH. > > The main reason for AES-GCM is the speed, and that that you do not > need to implement HMAC based MAC. In the IKEv2 those arguments are not > very valid. We do not really encrypt that much data in IKEv2 SA that > speed would matter.
This makes sense. AES-GCM is defined for IKE in RFC 5282, but if you need to encrypt so much in IKE that AES-CBC + HMAC-SHA-something is not fast enough, you’re doing it wrong regardless of how weak your processor is. > Also we always need to have some PRF to extract > the keying material from the DH output. > > On the other hand I have seen some questions about the suitability of > the CMAC as PRFs to extract keying material (i.e as KDF). Not sure > whether XCBC is any better. > > https://www.ietf.org/mail-archive/web/cfrg/current/msg02693.html > > Because of this it might be that we want to keep one HMAC based PRF as > mandatory to implement anyways, thus using same HMAC for > authentication does not add any code. I have thought about that a bit. The way the KDF is defined in IKEv2 limits us to functions that play well with PRF+. I’m thinking that we should extend or update IKE to be able to work with other KDFs such as HKDF or SHAKE128 or Blake2 or just some some natural PRF based on ChaCha20. But that is not for *this* iteration of 4307 even if we started working on that tomorrow. >> I think it’s a prime candidate for MUST. CTR was always uncommon. > > The small IoT devices would most likely want to use AES-CCM based > systems, mostly because they might already have that on the hardware. > >> ChaCha20+Poly1305 is so new that it can't be MUST this iteration. >> Maybe next time. > > Yep. > >>> I think that the updates will otherwise be non-controversial. > > So my take would be: > > DH group 2 1024-bit MODP MUST- -> MAY > DH group 14 2048-bit MODP SHOULD+ -> MUST > > Not sure which elliptic curves to propose. The NIST groups 19-21 has > the problem that there has been two complient ways to implement them > and those two ways are not interoperable, thus they would be bad idea > for mandatory to implement algorithm (i.e. they do not guarantee > interoperability). Is that still an issue? I thought this was a bug some years ago that everyone had fixed, no? > Brainpool curves are not that widely implemented, > and the cfrg is now working on adding another groups. Perhaps we can > add those new groups as SHOULD+ in the next iteration and leave this > draft as MODP only for now. I don’t have a survey of implementations, but I think 19,20, and 21 and more widely implemented than groups 15-18. So if somebody gets uncomfortable with 2048 bits (see [1]) it’s better to recommend that people move to an EC curve. I’d rather this be done with something that’s well established rather than something that is in a -00 draft submitted this month, but we should find out if interop works right now. > IKEv2 Transform Type 1 Algorithms > > ENCR_DES MAY -> MUST NOT > ENCR_3DES MUST- -> MAY > ENCR_AES_CBC SHOULD+ -> MUST > ENCR_AES_CTR SHOULD -> MAY > ENCR_CHACHA20_POLY1305 MAY -> SHOULD+ > > We could also add > > ENCR_AES_CCM_8 MAY -> SHOULD > AES-GCM with a 8 octet ICV MAY -> SHOULD > > but as this is IKEv2 SA we are talking about, we can just leave them > out, and say we have AES as primary algorithm and CHACHA20_POLY1305 as > backup. > > > IKEv2 Transform Type 2 Algorithms > > PRF_HMAC_MD5 MAY -> MAY > PRF_HMAC_SHA1 MUST -> MUST- > PRF_AES128_CBC SHOULD+ -> SHOULD > PRF_HMAC_SHA2_256 MAY -> SHOULD+ > > > IKEv2 Transform Type 3 Algorithms > > AUTH_HMAC_MD5_96 MAY -> MAY > AUTH_HMAC_SHA1_96 MUST -> MUST- > AUTH_AES_XCBC_96 SHOULD+ -> SHOULD > AUTH_HMAC_SHA2_256_128 MAY -> SHOULD+ > -- > [email protected] Yoav [1] https://mailarchive.ietf.org/arch/msg/tls/Mul0etdAxsFtpdJeBX2R-enGNN8 _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
