Skip to main content

Last Call Review of draft-igoe-secsh-suiteb-
review-igoe-secsh-suiteb-secdir-lc-harkins-2011-01-18-00

Request Review of draft-igoe-secsh-suiteb
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-01-18
Requested 2010-12-28
Authors Kevin Igoe
I-D last updated 2011-01-18
Completed reviews Secdir Last Call review of -?? by Dan Harkins
Assignment Reviewer Dan Harkins
State Completed
Request Last Call review on draft-igoe-secsh-suiteb by Security Area Directorate Assigned
Completed 2011-01-18
review-igoe-secsh-suiteb-secdir-lc-harkins-2011-01-18-00
  Hello,

  I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

  This draft documents how a Suite B-compliant SSH client can be built
using various other documents that describe how to do ECC-DH, ECDSA, and
AES-GCM in SSH. It establishes 2 minimum levels of security, one at
128-bits and another at 192-bits, and specifies how to use the ECC-DH,
ECDSA, and AES-GCM components to achieve those two levels.

  I found no issues with the draft itself and my only complaint is that
the Security Considerations seem a little insufficient for the task of
describing how to put Suite B in SSH. They are, in their entirety:

          The security considerations of [SSH-Arch] apply.

where [SSH-ARCH] is RFC 4251. The Security Considerations in RFC 4251
are very nice and it is proper to refer to them but, at the very least,
it would be nice to provide some text around the following questions:

  1. how much entropy is each side required to put into the ECC-DH
     exchange to achieve the appropriate minimum level of security?

  2. in the introduction the draft mentions that following the
     requirements in the draft does not imply that an implementation is
     suitable for protection of classified data. What other guidance can
     the author recommend to leap that bar? Are there any other documents
     that specify the other requirements an implementation would have to
     comply with?

  regards,

  Dan.