AES Galois Counter Mode for the Secure Shell Transport Layer Protocol
draft-igoe-secsh-aes-gcm-03

[Ballot comment]
Text agreed with the authors, waiting for revised draft -- but I'll
clear my DISCUSS so this can be approved during my leave (Tim
promised to check that the revised draft matches what we agreed).

[Ballot discuss]
I have reviewed draft-igoe-secsh-aes-gcm-02. Version -02 does mostly
resolve my main concern (returning partial plaintext), but I still
have the following concerns that I'd like to discuss before
recommending approval of the document:

1) Section 5.2 needs to be much clearer about what the plaintext
and AAD are, and how this differs from the requirements of RFC 4253.
Perhaps something like:

  The plaintext consists of the 'padding_length', 'payload', and
  'random_padding' fields. Note that unlike in [RFC4253], the
  'packet_length' field is not encrypted when using GCM mode.  See
  Section 5.2.1 for a description why the packet length is not
  encrypted when using GCM, and Section 9.2 for related security
  considerations.

I couldn't figure out what the AAD would be. Perhaps empty?  But
Section 5.2.1 suggests it might contain the packet_length field. 
If it does, why not add the implicit sequence number, too?
(so we could remove Section 9.1)

2) Section 7, last paragraph, is not correct any more. And since
there's potential for confusion here (GCM mode wouldn't really need
any padding) the padding requirements should be very clearly
specified in this document.

3) I don't think this document should register new AEAD algorithms in
the RFC 5116 registry. These are not new AEAD algorithms -- they're
exactly the same as AEAD_AES_128/256_GCM as specified in RFC 5116. If
the SSH transport protocol e.g. never uses plaintexts longer than
~2^32 bytes, that's perfectly OK, but that's a SSH transport protocol
detail, not a new AEAD algorithm.

(Otherwise, *every* use of RFC 5116 would be a new AEAD algorithm,
because e.g. nobody ever needs A_MAX of 2^61-1 octets. For example,
TLS (RFC 5288) uses AEAD_AES_128_GCM as-is -- without registering
anything new in the RFC5116 registry -- even though it never uses
plaintexts longer than ~2^14 bytes.)

In addition, idnits found couple of editorial nits:
== Missing Reference: 'RF4250' is mentioned on line 400, but not defined
== Unused Reference: 'RFC4344' is defined on line 431, but no explicit
  reference was found in the text

[Ballot discuss]
I have reviewed draft-igoe-secsh-aes-gcm-01. Overall, the document
looks good, but I have the following concerns that I'd like to discuss
before recommending approval of the document:

1) It seems you cannot actually implement this specification using the
AEAD decryption operation specified in RFC 5116 (Section 2.2) or GCM
decryption function specified in NIST SP 800-38D. These operations
take the ciphertext (plus nonce, associated data, and key) as input,
and return either the plaintext or failure.  Plaintext is not returned
if the integrity check fails.

This does not work as-is in SSH, because the "packet_length" field is
also encrypted. Or in other words: you need to return some plaintext
to the SSH transport protocol before you can verify the integrity.
Does this have any security implications in GCM mode? Does it have
implications for e.g. FIPS validation (since SSH transport protocol
can't treat the AEAD operation as a black box)?

At the very least, this unfortunate detail needs to be clearly
mentioned in the specification (encrypting "packet_length" is
already mentioned in RFC 4253, Section 6, 2nd-to-last paragraph,
but it doesn't violate module boundaries with non-AEAD algorithms).

2) I don't think this document should register new AEAD algorithms in
the RFC 5116 registry. These are not new AEAD algorithms -- they're
exactly the same as AEAD_AES_128/256_GCM as specified in RFC 5116. If
the SSH transport protocol e.g. never uses plaintexts longer than
~2^32 bytes, that's perfectly OK, but that's a SSH transport protocol
detail, not a new AEAD algorithm.

(Otherwise, *every* use of RFC 5116 would be a new AEAD algorithm,
because e.g. nobody ever needs A_MAX of 2^61-1 octets. For example,
TLS (RFC 5288) uses AEAD_AES_128_GCM as-is -- without registering
anything new in the RFC5116 registry -- even though it never uses
plaintexts longer than ~2^14 bytes.)

In addition, idnits found several editorial nits:
- Several occurances: '[RFC 4253]' should be spelled '[RFC4253]'
  to match the reference list
- Section 8: '[SSH-Arch]' should be '[RFC4251]'
- Section 9: typo '[RF4250]' (twice)
- Unused Reference: 'RFC4344' is defined on line 321, but no explicit
  reference was found in the text

IANA Last Call comments:

ACTION 1:

NOTE: The suggested values in the draft have been allocated

Upon approval of this document, the IANA will make the following
assignments in the "Authenticated Encryption with Associated Data
(AEAD) Parameters" registry at
http://www.iana.org/assignments/aead-parameters/aead-parameters.xhtml


Numeric ID | Name | Reference
-----------+----------------------------+----------
TBD | aead-aes-128-gcm-ssh | [RFC-igoe-secsh-aes-gcm-00]
TBD | aead-aes-256-gcm-ssh | [RFC-igoe-secsh-aes-gcm-00]


ACTION 2:

Upon approval of this document, the IANA will make the following
assignments in the "Encryption Algorithm Names" registry at
http://www.iana.org/assignments/example-foobar-registry

Encryption Algorithm Name | Reference | Note
-------------------------------+----------------------------+----------
aead-aes-128-gcm-ssh | [RFC-igoe-secsh-aes-gcm-00] | Section 4.1
aead-aes-256-gcm-ssh | [RFC-igoe-secsh-aes-gcm-00] | Section 4.2

ACTION 3:

Upon approval of this document, the IANA will make the following
assignments in the "MAC Algorithm Names" registry at
http://www.iana.org/assignments/example-foobar-registry

MAC Algorithm Name Reference Note
------------------------------- + ----------- + ------------
aead-aes-128-gcm-ssh | [RFC-igoe-secsh-aes-gcm-00] | Section 4.1
aead-aes-256-gcm-ssh | [RFC-igoe-secsh-aes-gcm-00] | Section 4.2

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

Document Shepherd Write-Up for draft-igoe-secsh-aes-gcm-00.txt

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

  Russ Housley is the Document Shepherd.


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

  The document is intended for publication as an Informational RFC.
  It has been reviewed by several community members.  There are
  no concerns about the depth or breadth of those reviews.


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


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


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

  This document documents the conventions for using AES-GCM with
  Secure Shell Transport Layer Protocol.  The people that want to
  make use of this mode seem to have consensus.


(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.  ID-Checklist and ID-Nits are both satisfied.  There is no
  need for any formal review from the MIB Doctors or any other such
  group.


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

  All of the references are normative.


(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
  [RFC5226].  If the document describes an Expert Review process has
  the Shepherd conferred with the Responsible Area Director so that
  the IESG can appoint the needed Expert during the IESG Evaluation?

  IANA actions are clearly identified in the IANA Considerations
  section of the document.


(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 formal language is used.


(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

    The Secure Shell (SSH) secure remote-login protocol is specified
    in RFC 4251.  SSH employs cryptographic algorithms to provide
    authentication, key agreement, confidentiality and data integrity.
    This document specifies the conventions for using AES-GCM, the
    Advanced Encryption Standard in the Galois/Counter Mode, to
    provide both confidentiality and data integrity.
 
  Working Group Summary

    This document is not the product of any IETF working group.

  Document Quality

    This document documents the conventions for using AES-GCM with
    Secure Shell Transport Layer Protocol.  The people that want to
    make use of this mode seem to have consensus.