Dang, Quynh (Fed) writes: > I meant implementations conforming to the RFC 4307 which implemented > the group 2. However, users must not use the group 2 because it is > not secure at this time.
Implementation conforming to RFC4307 can decide NOT to implement group 2 or SHA1. You have to remember what SHOULD NOT means: 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. In this case the valid reasons why implementations want to implement group 2 is because not implementing it causes interoperability issues with old version. This does NOT give any guidance or recommendations for the users. We are talking mostly about the implementors here not users when we make those recommendations. > If we want users not to use bad options, then we must prohibit them > with "MUST NOT" for implementations. There are no reasons for saying > "allowed" to implement them while asking users not to use them > unless we want to say to users they are allowed to be used. If implementation prohibits them using it and users notice this cause interoperability issue, users will simply switch to some other product that works, i.e., SSL 3.0 VPN, IKEv1, or simply do not upgrade to the new version as it breaks things. > This text "On the other hand, comments and recommendations from this > document are also expected to be useful for such users." and the > document says that the groups 2 and 5 are allowed "SHOULD NOT, not > MUST NOT". All of these seem to tell users that these groups are > allowed to use. This text was changed in the latest draft, based on your comments. Now it says: 1.3. Document Audience The recommendations of this document mostly target IKEv2 implementers as implementations need to meet both high security expectations as well as high interoperability between various vendors and with different versions. Interoperability requires a smooth move to more secure cipher suites. This may differ from a user point of view that may deploy and configure IKEv2 with only the safest cipher suite. On the other hand, comments from this document are also expected to be useful for such users. I.e., now it does not even claim to give any recommendations for the users, it just says that the comments we have for the algorithms are something that might also be useful for such users. If you think this is not clear enough, we can change it to say: 1.3. Document Audience The recommendations of this document mostly target IKEv2 implementers as implementations need to meet both high security expectations as well as high interoperability between various vendors and with different versions. Interoperability requires a smooth move to more secure cipher suites. This may differ from a user point of view that may deploy and configure IKEv2 with only the safest cipher suite. This document does not give any recommendations for the use of algorithms, it only gives implementation recommendations for implementations. The use of algorithms by users is dictated by the security policy requirements for that specific user, and are outside the scope of this document. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
