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. 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 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). 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. 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] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
