Brainpool Elliptic Curves for the Internet Key Exchange (IKE) Group Description Registry
draft-harkins-brainpool-ike-groups-04

[Ballot comment]
I agree with the principles in others' Abstain positions and with Pete's notion that some of the text from Russ's position should appear in an IESG Note.  I think that if the registry is indeed already overloaded, and if the community and sponsoring AD do think it's the right thing to do at the moment, it does seem odd to suddenly draw the line here, and block this from happening with too many Abstains ... thus I'm balloting No Objection.

[Ballot comment]
I agree with the principles in others' Abstain positions and with Pete's notion that some of the text from Russ's position should appear in an IESG Note.  I think that if the registry is indeed already overloaded, and if the community and sponsoring AD do think it's the right thing to do at the moment, it does seem odd to suddenly draw the line here, and block this from happening with too many Abstains ...

[Ballot comment]
If this registry is obsolete, perhaps we should strengthen the note that appear on the registry:

  these values were reserved as per draft-ipsec-ike-ecc-groups
  which never made it to the RFC. These values might be used by some
  implementations as currently registered in the registry, but new
  implementations should not use them.

The note doesn't explicitly say, "This is obsolete. It remains here for historical purposes only and should not be used." Having this document update the note on the registry seems like a good thing to do.

Also, it seems to me that some of the text in Russ's Abstain should appear in an IESG Note in this document. There should probably be explicit text in the document that this is a "bad idea".

[Ballot comment]
What Russ said.  This is the right thing to do in this case at this time, but is the wrong thing to do in general.

IESG/Authors/WG Chairs:

IANA has reviewed draft-harkins-brainpool-ike-groups-04.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We understand that, upon approval of this document, there is one action
which we must complete.

First in the Group Description (Value 4) subregistry of the Internet Key Exchange (IKE) Attributes registry located at

www.iana.org/assignments/ipsec-registry

four new values are to be assigned as follows:

Value: [ TBD-at-time-of-registration ]
Group Description: 224-bit Brainpool ECP group
Reference: [ RFC-to-be ]
Note: Section 2.1

Value: [ TBD-at-time-of-registration ]
Group Description: 256-bit Brainpool ECP group
Reference: [ RFC-to-be ]
Note: Section 2.2

Value: [ TBD-at-time-of-registration ]
Group Description: 384-bit Brainpool ECP group
Reference: [ RFC-to-be ]
Note: Section 2.3

Value: [ TBD-at-time-of-registration ]
Group Description: 512-bit Brainpool ECP group
Reference: [ RFC-to-be ]
Note: Section 2.4

We understand this to be the only action required upon approval of this
document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

[Ballot comment]

- Intro: Would it make sense to add a bit more text e.g.
saying "these were generated by  in <20xx> and have been
widely used since then by  and papers [refs] on their
goodness have been published by , technial details of all
of that can be found in [EBP] and 5639." You do almost but not
quite say that kind of thing.

- Section 2 nitty nits;-) I'm sure anyone who'd implement
would not need these clarified, but you never know...

  - its confusing to say "x,y" are the co-ordinates of the
  generator G when x,y are used in the equation of the curve
  just above. Wouldn't it be better to use e.g.  x(P_0)
  as used in [EBP]?

  - you don't say what group you mean

  - you don't say that h or z are for (z is explained well
  enough at the end of section 2 though)

typos:

- s/varient/variant/
- s/arithmatical/arithmetic/ I think or maybe arithmetical
but the RFC editor should know;-)

- And finally: I didn't check the values are all correct vs.
[EBP] or 5639, though I did compare a few bits. I sure hope
someone has:-)

[Ballot comment]

  The use of the Internet Key Exchange (IKE) registry by protocols other
  than IKE is not a good idea.  This overloading results in new registry
  entries that cannot be used by IKE, and it leads to implementer
  confusion for IKE as well as the other protocols that use the IKE
  registry.  That said, the overloading of the IKE algorithm registry
  has been going on for too long to easily correct now.  For that
  reason, I am not blocking the addition of these entries, but I want
  to strongly discourage future overloading of any algorithm registries.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Brainpool Elliptic Curves for the IKE Group Description Registry) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Brainpool Elliptic Curves for the IKE Group Description Registry'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-02-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This memo allocates code points for four new elliptic curve domain
  parameter sets over finite prime fields into a registry that was
  established by The Internet Key Exchange (IKE) but is used by other
  protocols.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-harkins-brainpool-ike-groups/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-harkins-brainpool-ike-groups/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or
Historic)?  Why is this the proper type of RFC?  Is this type of RFC
indicated in the
title page header?

The intended type is Informational and is indicated in the title page
header. The justification for this type is as follows:
- The purpose of the specification is to add code points to the name
space "Group Description (Value 4)" in the IKEv1
registry and the update policy of the name space is only "RFC required".
- The code points are not for use with IKEv1.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the "Action"
announcements for approved documents. The approval
announcement contains the following sections:

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.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the
document is not ready for publication, please explain why the document
is being forwarded to the IESG.

I have thoroughly reviewed the document and have verified all test vectors.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational
complexity, AAA, DNS, DHCP, XML, or internationalization? If so,
describe the review that
took place.

No


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area
Director and/or the IESG should be aware of? For example, perhaps he or
she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it. In any
event, if the interested community has discussed
those issues and has indicated that it still wishes to advance the
document, detail those concerns here.

IESG must decide how to deal with the IEEE 802.11 liaison request and if
the approach of the draft to define code points
with a note that they are "not for IKEv1" properly addresses it.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the
provisions of BCP 78 and BCP 79 have already been filed. If not, explain
why.

The draft only defines code points for existing curve. Thus, no IPR
declarations are needed.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any discussion and conclusion
regarding the IPR disclosures.

See (7)


(9) How solid is the consensus of the interested community behind this
document? Does it represent the strong
concurrence of a few individuals, with others being silent, or does the
interested community as a whole understand and
agree with it?

There is not really a consensus in the WG but I think the draft reflects
the best compromise between differing opinions.
Many persons were involved in the discussions. The previous version 03
(almost identical to the current version) has
been posted to the WG mailing list without any further feedback, which
indicates that the draft properly reflects the
achieved compromise.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of
conflict in separate email messages to the Responsible Area Director.
(It should be in a separate email because this
questionnaire is publicly available.)

No.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and
the Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

No nits found.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI
type reviews.

No formal review is required.


(13) Have all references within this document been identified as either
normative or informative?

Yes


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear
state? If such normative references exist, what is the plan for their
completion?

No.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support
the Area Director in the Last Call procedure.

No


(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page
header, listed in the abstract, and discussed in the introduction? If
the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where
the relationship of this document to the other
RFCs is discussed. If this information is not in the document, explain
why the interested community considers it
unnecessary.

Since the code points are not for IKE: no.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its
consistency with the body of the document. Confirm that all protocol
extensions that the document makes are associated
with the appropriate reservations in IANA registries. Confirm that any
referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the
registry, that allocations procedures for future registrations are
defined, and a reasonable name for the new registry
has been suggested (see RFC 5226).

Since the draft only defines new code points, the IANA section is the
core of it, and I have thoroughly checked it. The
registry and name space to be updated is clearly defined and the
amendments to be made are clearly and completely
described. Furthermore, the addition of a note "not for RFC 2409"
required by the WG and the AD is present.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that
the IESG would find useful in selecting the IANA Experts for these new
registries.

The IANA registry to be updated does not require expert review (but only
"RFC required").


(19) Describe reviews and automated checks performed by to validate
sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

I have verified the test vectors using the Magma Computational Algebra
System.