Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC
draft-ietf-dnsext-ecdsa-07

[Ballot discuss]
The AppsDir review by William Mills raised one major issue, about the formatting and generation of the integers and octet strings described in Section 4. A response would be appreciated. His review can be found here:

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04281.html

[Ballot discuss]
The Gen-ART Review by Roni Even on 29-Jan-2012 raised a major concern.
  The IANA action in this document updates a registry that requires
  standard action for adding values:
  http://www.iana.org/assignments/ds-rr-types/ds-rr-types.txt

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Elliptic Curve DSA for DNSSEC) to Proposed Standard


The IESG has received a request from the DNS Extensions WG (dnsext) to
consider the following document:
- 'Elliptic Curve DSA for DNSSEC'
  as a Proposed Standard

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 2012-03-01. 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.

Note that the intended status of this document is "Proposed Standard."  The
document previously went through an IETF last call with intended status
of "Informational."  The document is to be published as "Proposed Standard"
to meet the requirements of the IANA registries to be updated.

Abstract


  This document describes how to specify Elliptic Curve DSA keys and
  signatures in DNSSEC.  It lists curves of different sizes, and uses
  the SHA-2 family of hashes for signatures.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dnsext-ecdsa/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dnsext-ecdsa/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1597/

[Ballot comment]
I presume that Section 6 needs to be updated as this document goes
through the publication process. I think you should provide instructions
to the RFC Editor on what should be done to this section.

A way to do this would be to supply an RFC Editor note that fixes the
section consistent with the actual IANA allocations, but will not show
in the document until published as an RFC.

[Ballot discuss]
The AppsDir review by William Mills raised one major issue, about the formatting and generation of the integers and octet strings described in Section 4. A response would be appreciated. His review can be found here:

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04281.html

[Ballot discuss]
The Gen-ART Review by Roni Even on 29-Jan-2012 raised a major concern.
  The IANA action in this document updates a registry that requires
  standard action for adding values:
  http://www.iana.org/assignments/ds-rr-types/ds-rr-types.txt

[Ballot comment]
Section 4 says you MUST support signing "and/or" validation with
both lengths. I think that is not quite clear enough as the
requirement differs for different players in the DNSSEC game.
Aside from basic clarity, which is the most important thing, there
is also an IPR declaration here that distinguishes between things
that are needed and things that are optional so I think expressing
it in a way that makes clear that there are no
optional-to-implement bits for anyone would be an improvement.
I'd say that it'd be better to spell it out that implementations
that create DNSSEC values to put into the DNS MUST implement
signing and verification for both lengths, and that DNSSEC clients
MUST implement verification for both lengths. (Or whatever is
the right way to say thing.)

Will the examples be re-done after IANA have allocated codes?  Be
more than nice if that were to be the case.

An informational pointer to RFC 6090 might be no harm here (and
everywhere that uses ECC).

[Ballot discuss]
s4: Indicates that ECDSA keys are single value Q.  The format of the key is x | y.  Note that normally there's a component before the x | y that indicates whether the key is compressed, uncompressed, hybrid, etc.  I understand that this spec is only about uncompressed keys but I'm curious whether adding the additional indicator before the x | y was considered.

IANA understands that, upon approval of this document, there are two
actions which need to be completed.

First, in the Digest Algorithms subregistry in the Delegation Signer
(DS) Resource Record (RR) Type Digest Algorithms registry located at:

http://www.iana.org/assignments/ds-rr-types/ds-rr-types.xml

a new entry will be added as follows:

Value: [ tbd ]
Digest Type: SHA-384
Status: OPTIONAL
Reference: [ RfC-to-be ]

Second, in the DNS Security Algorithm Numbers subregistry of the Domain
Name System Security (DNSSEC) Algorithm Numbers registry located at:

http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xml

two new entries will be added as follows:

Number [ TBD ]
Description ECDSA Curve P-256 with SHA-256
Mnemonic ECDSAP256SHA256
Zone Signing Y
Trans. Sec. *
Reference [ RFC-to-be ]

Number [ TBD ]
Description ECDSA Curve P-384 with SHA-384
Mnemonic ECDSAP384SHA384
Zone Signing Y
Trans. Sec. *
Reference [ RFC-to-be ]

IANA understands that these are the only actions that are required to be
completed upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Elliptic Curve DSA for DNSSEC) to Informational RFC


The IESG has received a request from the DNS Extensions WG (dnsext) to
consider the following document:
- 'Elliptic Curve DSA for DNSSEC'
  as an 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 2012-02-07. 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 describes how to specify Elliptic Curve DSA keys and
  signatures in DNSSEC.  It lists curves of different sizes, and uses
  the SHA-2 family of hashes for signatures.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dnsext-ecdsa/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dnsext-ecdsa/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1597/

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Olafur Gudmundsson is the document shepherd.
He has reviewed this version and it is ready for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

This document has been through a number of discussions on the
working group mailing list, including a long WGLC.
During the last call few documentation issues were raised and
addressed by the editors.
We had many reviewers of this document, the document shepherd has no
issues with the review.


  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No

  (1.d) Does the Document Shepherd have any specific concerns or
        issues 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. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

There has been an IPR filed against this document like any other ECC
related document. This IPR is similar to others filed thus this
document should be processed the same way as the other documents that
have been published with similar IPR filed against them by the same
party.
The WG did not discuss the IPR filing.
https://datatracker.ietf.org/ipr/1597/

  (1.e) 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? 

Strong Consensus, the WG understand the need for this specifcation to
  be published but not all of the members of the working group may
  understand exactly how ECC works.

  (1.f) 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
        entered into the ID Tracker.)

NO.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

ID nits have all been addressed and this version is id-nit free.
no other reviews are needed.

  (1.h) Has the document split its references into normative and
        informative? 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
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

yes.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

Yes, the document updates existing 2 registires.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

No such section.

  (1.k) 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
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.

This document describes how to specify Elliptic Curve DSA keys and
signatures in DNSSEC.  It lists curves of different sizes, and uses
the SHA-2 family of hashes for signatures.

    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

Working group has not had any issues with this document, there was
some disucussion during the drafts adoption if this was needed.
The document editors have been good about addressing any points
raised.
Consensus is solid.

    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

The document is well written, there are at least 2 implementations and
they interoperate. The document has been stable since being adopted by
the working group most of the versions have been to incorporate
textual changes of the clarificaiton kind, and the last one addressed
ID-nits.