Paul Wouters writes: > which seems to imply 768 MODP group is "MAY". Which is confirmed in RFC > 4109. So I think we should also update 768 MODP group to MUST NOT.
I agree on that. I thought we deprecated that already in the RFC4306 by saying: ---------------------------------------------------------------------- Appendix B: Diffie-Hellman Groups ... The strength supplied by group one may not be sufficient for the mandatory-to-implement encryption algorithm and is here for historic reasons. ... ---------------------------------------------------------------------- but it might be better to say MUST NOT explictly. > > Downgrade ENCR_3DES from MUST- to MAY > > I'm not sure how I feel about that. There are still not many > alternatives to AES, and I think having 3DES in there is good. Yes it is > slow, but I don't think it has been concluded to be weak or insecure. I think we need to downgrade it from MUST to something else anyways, as small implementations which do have hardware support for AES, might not want to add implementation for 3DES at all. You can still implement and use it, it just would not be mandatory to implement algorithm anymore. I.e. if you need to pick one algoritm I think AES is better than 3DES. If you want to implement 2 algorithms then implementing both AES and 3DES is ok. We could also make it SHOULD- instead of MAY, but I think MAY is still better. Note to others: the main problem with 3DES (i.e. the too long block length) is not relevant here as we are talking about the encryption algorithm protecting key management messages, where the number of actual bytes transmitted are going to be quite low compared to the block length restrictions from 3DES. There is mandatory requirement to rekey after 2^32 IKEv2 messages has been transmitted anyways, but in general the amount of messages transmitted is between 2 -- 10000. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
