Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol Version 2 (IKEv2)
draft-merkle-ikev2-ke-brainpool-06

[Ballot discuss]
Based on Stewart Bryant's response:

  That only takes an IETF LC with the down-refs call out.  Indeed I think
  that if you change the track and regenerate the LC text the tool does
  that for you.

I am going to hold a DISCUSS on this until we discuss it in the telechat.  I am not deeply attached to an outcome either way, and fully understand the authors' motivation for going with Informational—I would just like us to hold off on approving the document until we've discussed this.

[Ballot comment]
I agree strongly with Stephen Farrell's advice that you remove the IPR section—I think it contains no useful information, and arguably creates the potential for increased liability for implementors, since it may be more difficult for them to claim that they didn't know about whatever patents may, in the future, surface.  I think you would be hard-pressed to find a protocol implementor today who is not keenly aware of the risk of a submarine patent, so there is no special need to call out that risk in this document.

[Ballot comment]
I continue to think that this should be a standards track document, but am reluctantly accepting the situation that the documents it depends on were erroneously approved as informational, so that making this document standards track would involve down-references.

I agree strongly with Stephen Farrell's advice that you remove the IPR section—I think it contains no useful information, and arguably creates the potential for increased liability for implementors, since it may be more difficult for them to claim that they didn't know about whatever patents may, in the future, surface.  I think you would be hard-pressed to find a protocol implementor today who is not keenly aware of the risk of a submarine patent, so there is no special need to call out that risk in this document.

[Ballot comment]

- I don't really like how this document has a section (5) that
says "there may be patents" but yet there are no IPR declarations
for this and hence no concrete information. The authors did
explain that they put this in because they worry that the
ideas referenced seem like the kind of thing that'd be
patented but that they don't know of any such patents.
I can understand that but this seems to me to just add
to the IPR FUD around ECC and would be better deleted
I think.

- Section 5 also refers to 2.1 but I think you mean 2.2?

- Don't you need once of RFC 6090 or SEC1 to be normative since
you're using the FieldElement-to-OctetString conversion function
from one of them? I'd much prefer 6090 be normative.

[Ballot discuss]
It doesn't make sense to me that this is an informational draft—it uses normative language and defines a protocol extension.  As far as I can tell from the writeup, the reason for making it informational rather than standards track is "it's easier, and we can get the code points without it being standards track."  I do not dispute this latter point, but it seems that the document has had significant review, and really does seem to be extending a standard, so unless there is some strong reason, it ought to be standards track.  I will admit though that I am a newbie here, and perhaps the other ADs will explain to me why this makes sense.

[Ballot discuss]

I don't understand how this document can have a section (5) that
says "there may be patents" but yet there are no IPR declarations
for this. Nor, oddly, for 5639 which has a very similar section
and the same authors. RFC 5903 also has no IPR declarations.
(Section 5 also refers to 2.1 but I think you mean 2.2?)

[Ballot comment]

- Don't you need once of RFC 6090 or SEC1 to be normative since
you're using the FieldElement-to-OctetString conversion function
from one of them? I'd much prefer 6090 be normative.

[Ballot comment]
Just two nits:

Section 5., paragraph 1:

>    Although, the authors have no knowledge about any intellectual
>    property rights which cover the general usage of the ECP groups
>    defined herein, implementations based on these domain parameters may

  replace 'may' by 'could'.


Section 5., paragraph 2:

>    require use of inventions covered by patent rights.  In particular,
>    techniques for an efficient arithmetic based on the special
>    parameters of the twisted curves as explained in Section 2.1 may be
>    covered by patents.

  replace 'may' by 'could'.

IESG/Authors/WG Chairs:

IANA has reviewed draft-merkle-ikev2-ke-brainpool-03.  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 there is a single action required to be completed
upon approval of this document. 

We understand that the following four new Transform IDs have been
added to the "Transform Type 4 - Diffie-Hellman Group Transform IDs"
subregistry upon the completion of ticket 666056:

URL: www.iana.org/assignments/ikev2-parameters

Note (from the designed expert done earlier):

Note, that this draft also requires that the actions from the
draft-ietf-ipsecme-dh-checks is also done.  The
draft-ietf-ipsecme-dh-checks adds the Recipient Tests column to
"Transform Type 4 - Diffie-Hellman Group Transform IDs" registry, and
this draft-merkle-ikev2-ke-brainpool also fills that column.

IANA understands that these are the only actions requested by this
document.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Using the ECC Brainpool Curves for IKEv2 Key Exchange) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Using the ECC Brainpool Curves for IKEv2 Key Exchange'
  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-03-26. 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 document specifies the use of ECC Brainpool elliptic curve
  groups for key exchange in the Internet Key Exchange version 2
  (IKEv2) protocol.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/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?

It's an Informational RFC. This is appropriate because it's just mainly
adding new domain parameter sets to a repository for use with IKEv2.
Also, informational is appropriate because that's all that is required
by the IANA policy of the name space to be
updated.

(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:

This memo specifies the use of new elliptic curves, generated by the ECC
Brainpool, for use in version 2 of the Internet Key Exchange. Because
version 2 of the Internet Key Exchange was ambiguous about how points on
an elliptic curve are encoded in the KE payload and what the shared
secret result of an ECDH looked like, this memo also specifies that
information when using an ECC Brainpool curve.

Working Group Summary:

This memo is not a working group document but it was discussed on the
IPsec mailing list. Earlier versions of the memo discussed point
compression when encoding a point on a curve into the KE payload but due
to opposition to point compression that was removed. There wa salso
working group discussion on validation of public keys, including  ECC
public keys. The draft mentions the need to validate a received ECC
public key, per working group discussion and refers to an I-D that
specifies such validation.

Document Quality:

The elliptic curves have been used in other protocols than IKE. The
test vectors in the memo have been verified by the document shepherd.

Personnel:

Dan Harkins is the document shepherd.
The responsible area director 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.

The document shepherd read the document and reviewed it for completeness
and clarity. The document shepherd wrote a short program that verified
its test vectors.

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

No, none at all.

(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.

There are no further expert reviews needed.

(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 WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

The document shepherd has no concerns or issues with the document. The
document shepherd wished that this memo could've updated the domain
parameter set used by the original version of the Internet Key Exchange
but, alas, that was not possible.

(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 merely discusses allocation of code points for existing
elliptic curves so no IPR disclosure is necessary for this memo.

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

No, there are no IPR disclosures that reference this document.

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

As stated above, this is not the product of a working group. As such, it
is not the result of working group consensus. There is wide acceptance
that there is a need to allocate code points for these elliptic curves
and that's really all this memo does. I would say that the working group
as a whole understands and agrees with the need for this memo and the
strong concurrence of a few individuals has convinced the rest of the
working group that this approach is proper.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise 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.)

The document shepherd is unaware of any threat of an appeal or any
discontent with the document.

(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.

There are no ID nits.

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

There is no formal review 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?

Yes, the memo has a normative reference to draft-ietf-ipsecme-dh-checks.
This draft is an IPsecME working group document and is proposed for the
standards track. The plan for completion is eventual publication as an
RFC, the date for such completion is unknown at this time.

(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
WG considers it unnecessary.

No, it will not.

(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).

The IANA Considerations instruct IANA to allocate code points for curves
listed in a table. The reference properly identifies the repository for
IANA to update. The designated expert for that repository has reviewed
the memo, but has not yet rendered his expert review.

(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.

There are no new IANA registries added.

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

The test vectors have been verified.