Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer
draft-green-secsh-ecc-09

[Ballot discuss]
I have reviewed draft-green-secsh-ecc-08, and have couple of concerns
that I'd like to discuss before recommending approval of the document:

Section 3.1.2, last paragraph, is not consistent with the definition
of "mpint" type in RFC 4251, which specifies slightly different octet
string encoding for integers.

In Section 6.1, the document doesn't tell which ASCII representation
of OIDs is used. The reference [ASN1] usually uses space-separated
ASCII representation, but the example in Section 6.3 suggests that
dot-separated might be the intended one.

IANA Last Call comments:

IANA Has Questions:

- Do you want a registry of required and recommended curves (from
Sections 6 and 9)?

Action 1:

Upon approval of this document, the IANA will make the following assignments
in the "Secure Shell (SSH) Protocol Parameters" registry located at
http://www.iana.org/assignments/ssh-parameters
sub-registry "Public Key Algorithm Names"

Note:
*All values beginning with the specified string and not containing "@".

Public Key Algorithm Name Reference Note
------------------------------- ----------- ------------
ecdsa-sha2-* [RFC-green-secsh-ecc-08] Section 3.


Action 2:

Upon approval of this document, the IANA will make the following assignments
in the "Secure Shell (SSH) Protocol Parameters" registry located at
http://www.iana.org/assignments/ssh-parameters
sub-registry "Key Exchange Method Names"

Method name Reference Note
------------------------------------ ----------- -----------
ecdh-sha2-* [RFC-green-secsh-ecc-08] Section 4.
ecmqv-sha2 [RFC-green-secsh-ecc-08] Section 5.


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

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

    >> The Document Shepherd for this document is Jeffrey Hutzelman,
    >> .  I have reviewed this document, and I believe
    >> it is ready for IETF-wide review and publication as a Proposed
    >> Standard.

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

    >> This document defines use of elliptic curve cryptography for
    >> public key signatures and key exchange in the SSH protocol.
    >> It has received extensive review and discussion from the SSH
    >> community, in the form of the still-active ietf-ssh mailing
    >> list which was the home of the now-concluded SECSH Working
    >> Group.

(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, I don't believe this document requires any specific
    >> additional review beyond that which it will receive during
    >> IETF-wide last call.

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

    >> No issues.

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

    >> As previously noted, this document defines use of ECC in SSH.
    >> Both the ECC algorithms used and the SSH protocol are fairly
    >> mature, well-understood, and reasonably widely deployed, and
    >> the broad strokes of using them together are fairly obvious.
    >> Thus, the work is mostly in defining the details, particularly
    >> with regard to how the SSH protocol is extended.  As noted
    >> above, these details were discussed extensively with various
    >> SSH experts and on the ietf-ssh mailing list, which is an
    >> active forum of SSH designers and implementors, many of whom
    >> were active in the work of the SECSH working group in defining
    >> the SSHv2 protocol.  While I have not conducted a formal poll,
    >> I believe there is rough consensus among that community on the
    >> particulars of this document.

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

    >> As shepherd, I have received no indications that anyone is
    >> discontent with this document as it stands.

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

    >> Neither the automated id-nits tool nor a manual review found
    >> any errors.

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

    >> References in this document have been suitably split into
    >> normative and informative references.
    >>
    >> This document contains a normative reference to an Informational
    >> RFC, RFC2104, which defines the HMAC cryptographic algorithm.
    >>
    >> This document contains normative references to publications of
    >> other standards organizations, including ANSI, NIST, and the
    >> Standards for Efficient Cryptography Group.
    >>
    >> In several cases, multiple external references are given for
    >> specification of a cryptographic protocol or technique, one
    >> of which is normative, with the others being provided for
    >> additional information.

(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 suggested a reasonable name for the new registry?  See
    [I-D.narten-iana-considerations-rfc2434bis].  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?

    >> This document makes registrations in two SSH-related registries,
    >> registering a key exchange method, a family of key exchange
    >> methods, and a family of public key algorithms.  The IANA
    >> considerations correctly describes these registrations.

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

    >> This document contains no sections written in formal languages.

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


Technical Summary

This document describes algorithms based on Elliptic Curve
Cryptography (ECC) for use within the Secure Shell (SSH) transport
protocol.  In particular, it specifies: Elliptic Curve Diffie-Hellman
(ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key
agreement and Elliptic Curve Digital Signature Algorithm (ECDSA) for
use in the SSH Transport Layer protocol.

Working Group Summary

This document is the result an individual submission by members of
the community interested in seeing support for use of ECC algorithms
in the SSH protocol.  While there is no active working group behind
this work, it was extensively reviewed and discussed on the ietf-ssh
mailing list, which was the home of the Secure Shell Working Group
before that group concluded and still counts many of the participants
of that working group among its members.

Document Quality

While there are no existing implementations of this protocol, there
has been indication of interest from SSH implementors.

Personnel

The document shepherd for this document is Jeffrey Hutzelman
The responsible Area Director is Tim Polk.

Posted related IPR disclosure: Certicom's Statement about IPR related to draft-ietf-tls-rfc4347-bis, draft-rescorla-tls-suiteb, draft-ietf-tls-extractor, draft-green-secsh-ecc, draft-ietf-avt-dtls-srtp, draft-igoe-secsh-suiteb, draft-ietf-smime-3851bis, draft-ietf-smime-3850bis, dra...

Posted related IPR disclosure: Certicom's Statement about IPR related to draft-ietf-smime-3278bis, draft-ietf-smime-sha2, draft-ietf-smime-multisig, draft-ietf-smime-3850bis, draft-ietf-smime-3851bis, draft-igoe-secsh-suiteb, draft-ietf-avt-dtls-srtp, draft-green-secsh-ecc, draft-ie...

Posted related IPR disclosure: Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...