TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)
draft-ietf-tls-ecc-new-mac-07

IANA Last Call comments:

Upon approval of this document, the IANA will make the following
assignments in the "Transport Layer Security (TLS) Parameters"
registry at
http://www.iana.org/assignments/tls-parameters
sub-registry "TLS Cipher Suite Registry"

Value Description Reference
------------ -------------------------------------- ---------
{TBD,TBD} TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 [RFC-tls-rsa-aes-gcm-03]
{TBD,TBD} TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 [RFC-tls-rsa-aes-gcm-03]
{TBD,TBD} TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 [RFC-tls-rsa-aes-gcm-03]
{TBD,TBD} TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 [RFC-tls-rsa-aes-gcm-03]
{TBD,TBD} TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 [RFC-tls-rsa-aes-gcm-03]
{TBD,TBD} TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 [RFC-tls-rsa-aes-gcm-03]
{TBD,TBD} TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 [RFC-tls-rsa-aes-gcm-03]
{TBD,TBD} TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 [RFC-tls-rsa-aes-gcm-03]
{TBD,TBD} TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 [RFC-tls-rsa-aes-gcm-03]
{TBD,TBD} TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 [RFC-tls-rsa-aes-gcm-03]
{TBD,TBD} TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 [RFC-tls-rsa-aes-gcm-03]
{TBD,TBD} TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 [RFC-tls-rsa-aes-gcm-03]
{TBD,TBD} TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [RFC-tls-rsa-aes-gcm-03]
{TBD,TBD} TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 [RFC-tls-rsa-aes-gcm-03]
{TBD,TBD} TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 [RFC-tls-rsa-aes-gcm-03]
{TBD,TBD} TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 [RFC-tls-rsa-aes-gcm-03]


We understand the above to be the only IANA Action for this
document.

(1.a) Who is the Document Shepherd for this document?

Joseph Salowey, Working Group Chair

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?

Yes

(1.b) Has the document had adequate review both from key WG members and
from key non-WG members?

Yes.

Does the Document Shepherd have any concerns about the depth or breadth
of the reviews that have been performed?

No.

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

No.

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

Active members have reviewed and approved of the document, others have
shown some positive interest.


(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 http://www.ietf.org/ID-Checklist.html 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?

Yes.


(1.h) Has the document split its references into normative and
informative?

Yes.


Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?

No.


If such normative references exist, what is the strategy for their
completion? Are there normative references that are downward
references, as described in [RFC3967]?

No.

If so, list these downward references to support the Area Director in
the Last Call procedure for them [RFC3967].


(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of the
document?

Yes.

If the document specifies protocol extensions, are reservations
requested in appropriate IANA registries? Are the IANA registries
clearly identified?

Yes.


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 [RFC2434]. 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?


N/A.



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

N/A.


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

The IESG Contact Persons are Tim Polk and Pasi Eronen. A URL of this
draft is:

http://tools.ietf.org/html/draft-ietf-tls-ecc-new-mac-07

Technical Summary

This document describes new ECC cipher suites for
TLS which specify stronger digest algorithms. Eight
use HMAC with SHA-256 or SHA-384 and eight use AES in
Galois Counter Mode (GCM).


Working Group Summary

This document is a product of the Transport Layer
Security (TLS) Working Group. The document represents
the consensus of the TLS working group.


Document Quality

There has been significant review of the document by
members of the TLS working group on the document and
changes were made to improve the document based on
these reviews.


Personnel

The Document Shepherd for this document is Joseph Salowey,
and the responsible Area Director is Tim Polk.