draft-ietf-secsh-newmodes-04.txt is ready for AD Review

[Bill Sommerfeld <sommerfeld%sun.com@localhost>]

I believe that the consensus of the Secure Shell working group is that
draft-ietf-secsh-newmodes-04.txt should be published as a Proposed
Standard.
Please start Area Director review.

						- Bill

[This is a writeup checklist following the provisional WG Chair
document shepherd process described in:

	draft-ietf-proto-wgchair-doc-shepherding-05.txt]

   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.