The Secure Shell (SSH) Transport Layer Encryption Modes
draft-ietf-secsh-newmodes-05

[Ballot comment]
From Gen-ART review by Avri Doria:

Questions:

1.  does SSH count as one of the acronyms that is so well known that
    it can be included in an abstract without expanding?  I tend to
    think so, but I bring up the question for completeness sake.

2. i assume the birthday property [BC: paradox] (3.2) is well know.  For the naive reader
  it might be good to have a reference to where this is explained.


Comments:

in 3  Last sentence:  the note is tantalizing but doesn't explain
  why it might be the case.  Since it is explained later in the document, it
  should at least have a forward xref to section 6.1.

3.1 Several SHOULDs and SHOULD NOTs without any explanation of why not
  MUST or MUST NOT.  Perhaps this is due to the note about one
  recommendation taking precedence over another recommendation, but
  it is not clear that is the case.  In seems that the
  discussion in in 6.1 is relevant, but that is rather far away from the
  requirements themselves.  Perhaps another forward xref would help.

[Ballot comment]
From Gen-ART review by Avri Doria:

Questions:

1.  does SSH count as one of the acronyms that is so well known that
    it can be included in an abstract without expanding?  I tend to
    think so, but I bring up the question for completeness sake.

2. i assume the birthday property (3.2) is well know.  For the naive reader
  it might be good to have a reference to where this is explained.


Comments:

in 3  Last sentence:  the note is tantalizing but doesn't explain
  why it might be the case.  Since it is explained later in the document, it
  should at least have a forward xref to section 6.1.

3.1 Several SHOULDs and SHOULD NOTs without any explanation of why not
  MUST or MUST NOT.  Perhaps this is due to the note about one
  recommendation taking precedence over another recommendation, but
  it is not clear that is the case.  In seems that the
  discussion in in 6.1 is relevant, but that is rather far away from the
  requirements themselves.  Perhaps another forward xref would help.

[Ballot comment]
I think that the last paragraph of the Abstract belongs in the
  Introduction.

  Section 3.1 says:
  >
  > The preferred way to do this is to rekey after receiving more than
  > 2**31 packets since the last rekey operation.
  >
  I suggest:
  >
  > The preferred implementation technique is to use the reception of
  > more than 2**31 packets since the last rekey operation as a trigger
  > to rekey.

  Two comments about section 4:
 
  * The description of counter mode seems compatible with NIST SP 800-38A.
    A single counter is used here, instead of a counter for each packet,
    but that does not seem to be a problem.  Please reference NIST
    SP 800-38A.

  * The usual reference for Triple-DES is:
      [3DES]  American National Standards Institute. ANSI X9.52-1998,
              Triple Data Encryption Algorithm Modes of Operation. 1998.

  Section 6.2 says:
  >
  > Fortunately, the common concerns with counter mode do not apply to
  > SSH because of the rekeying recommendations and because of the
  > additional protection provided by the transport protocol's MAC.
  >
  This sentence should also include the built-in initial key
  establishment capability.

  1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

Yes. 

There is a known nit in the -04 version:

The CAST-128 cipher takes a variable-length key of up to 128 bits;
the document does not specify a key size. 

Given the 128-bit-and-up requirement on key length included in section
6.1 of draft-ietf-secsh-transport, the resolution is obvious and
non-controversial: implementations should only use 128 bit keys with
cast-128 in counter mode.

This nit is expected to be fixed prior to IETF-wide last call.

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

There appears to have been adequate review. 

  1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

No.

  1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

In the security area there have been recurring philosophical debates on
the relative merits of algorithm diversity in protocols and
implementations.  While there appears to be general consensus that
protocols should be algorithm-agile, there is also a view that excessive
algorithm proliferation should be avoided.  But exactly where to draw
the line seems to be a matter of personal preference.

The Secure Shell WG on the whole does not appear to have particularly
strong opinions on the topic but has historically pursued a
high-diversity approach.  As a specific example,
draft-ietf-secsh-transport-24.txt defined thirteen codepoints for
CBC-mode algorithms.  This document defines an additional thirteen
codepoints for counter-mode variants of the same set of algorithms,
providing more-secure alternatives to all of the ciphers exhibiting the
CBC-mode problem in -transport.

  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?

Discussion of this draft has been focussed and smooth.  Consensus
appears to be solid. 

  1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.

No.

  1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

The draft, submitted on April 8, 2005, still has RFC3667/8 boilerplate,
which is now flagged by idnits.

There is one manual checklist nit:

        3.1.B: one citation appears:

  Bellare, Kohno, and Namprempre [ACM CCS 2002] prove that if an SSH
  application implements the modifications described in this document,
  then the symmetric cryptographic portion of that application will
  provably resist chosen-plaintext, chosen-ciphertext, reaction-based
  privacy and integrity/authenticity attacks.

I've sent a suggested reword to the document editor (out of band)

  1.h) Is the document split into normative and informative references?

Yes.

        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
No.

  1.ijk) Writeup:

        *    Technical Summary

Researchers have discovered that the authenticated encryption portion of
the current SSH Transport Protocol is vulnerable to several attacks.

This document describes new counter-mode based symmetric encryption
methods for the SSH Transport Protocol and gives specific
recommendations on how frequently SSH implementations should rekey.

        *    Working Group Summary

This document was non-controversial and well-received by the WG.

        *    Protocol Quality

The spec is relatively simple, and the working group is aware of
multiple implementations, has received informal reports of successful
interoperability, and has not received reports of any implementation
difficulties.

The working group chair asked the document author to fix IPR
boilerplate, to remove the reference from the abstract and to indicate
we use cast128 with 128-bit keys.

I ask for an explicit reference to problems with counter reuse in the
security considerations section.