Brainpool Elliptic Curves for the Internet Key Exchange (IKE) Group Description Registry
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: RFC Editor <email@example.com> Subject: Document Action: 'Brainpool Elliptic Curves for the IKE Group Description Registry' to Informational RFC (draft-harkins-brainpool-ike-groups-04.txt) The IESG has approved the following document: - 'Brainpool Elliptic Curves for the IKE Group Description Registry' (draft-harkins-brainpool-ike-groups-04.txt) as Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-harkins-brainpool-ike-groups/
Technical Summary The draft allocates code points for four new elliptic curve domain parameter sets (ECC Brainpool curves from RFC 5639) over finite prime fields into a registry that was established by the IKEv1 (https://www.iana.org/assignments/ipsec-registry) but is used by other protocols (IEEE 802.11aa, IEEE 802.11s, RFC 5931). Working Group Summary The draft was discussed quite controversially on the WG mailing list. There are persons in the WG that strongly feel that no further code points should be defined for IKEv1 because the protocol has been deprecated long ago (by RFC 4306). Other persons in the WG argued that IKEv1 is still widely used in practice and, furthermore, other code points have been assigned previously to the same name space after IKEv1 was obsoleted. No consensus could be achieved on this topic. On the other hand, the ADs received an informal liaison statement from IEEE 802.11 (https://datatracker.ietf.org/liaison/1181/) requesting code point assignments for these curves in the IKEv1 registry. IEEE standards 802.11aa and 802.11s are using this name space of the IKEv1 registry, and these specs are apparently not up for change until 2015. The matter was discussed at the SAAG meeting among the ADs and the WG members present and it was decided to publish an internet-draft that requests these code points but also requires IANA to add a note that they are not for IKEv1. In the WG discussion following its publication, concerns were uttered that the note won't be enough to stop people asking for IKEv1 products to support these new code points and to prevent implementers to use them for IKEv1. On the other hand, it was expressed that requiring the IEEE specs to point to another (new) registry is probably not possible due to their publishing cycle. Alternative solutions were discussed, e.g. to include in the registry only a link pointing to another registry where the actual values are listed. Eventually, the approach of the draft, i.e. to include a note "not for IKE" in the registry, was widely considered the best way forward. After some comments on earlier versions, an announcement of a revised draft on the ipsecme mailing list did not result in any further comments. There was agreement that the draft shall not be a WG document. Document Quality Some specific comments of Tim Polk were accommodated in a revision. Personnel The Document Shepherd is Johannes Merkle, the sponsoring AD is Sean Turner.