Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-kex-sha2-04.txt

From: [email-masked]
Date: Wed, 07 Sep 2016 08:34:19 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF.

        Title           : Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)
        Author          : Mark D.     Baushke
	Filename        : draft-ietf-curdle-ssh-kex-sha2-04.txt
	Pages           : 8
	Date            : 2016-09-07

Abstract:
   This document adds recommendations for adoption of ssh-curves from
   the [I-D.ietf-curdle-ssh-curves], adds some new Modular Exponential
   (MODP) Groups, and deprecates some previously specified Key Exchange
   Method algorithm names for the Secure Shell (SSH) protocol.  It also
   updates [RFC4253], [RFC4419], [RFC4462], and [RFC5656] by specifying
   the set key exchange algorithms that currently exist and which ones
   MUST, SHOULD, MAY, and SHOULD NOT be implemented.  New key exchange
   methods use the SHA-2 family of hashes.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-curdle-ssh-kex-sha2-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-kex-sha2-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 8 Sep 2016 12:25:24 +0300

> 	Filename        : draft-ietf-curdle-ssh-kex-sha2-04.txt

I decided to make quick look at this document after the discussion on
the list. Here is my comments for it.

First general comment. In the IPsec protocol we splitted the algorithm
description documents and their requirement levels documents to
separate documents. This mostly does this, except it will still define
some new algorithms. Which means that next time the algoritms are
updated we cannot obsolete this, as this is only document describing
how those new algorithms are used.

Because of this I would suggest splitting this document in two. I.e.
the first document would define the new key exchange methods, and
nothing else.

The second document would just define the mandatory to implement
algorithms for secure shell, and make it so that it can be obsoleted
when new recommendations come out. 

Then some other comments:

--

In section 1 this document incorrectly claims that
diffie-hellman-group1-sha1 would be using Oakley group 1 (a 768-bit
MODP group), when it actually uses first group for shell, but Oakley
group 2, i.e. the 1024-bit MODP group. See section 8.1. of RFC 4253.

--

I think the IANA considerations section is wrong. It should only list
the updates and changes to IANA considerations section, and in here it
also specifies the requirement levels for the algorithms. Are IANA
really supposed to add the Note field to the Key Exchnage Method table
and store the requirement levels in the IANA registry? We have not
usually done that.

I would recommend to change IANA considerations sections so it only
lists the actions IANA is supposed to do, i.e. say that IANA is
supposed to add following entries

   Key Exchange Method Name              Reference     Note
   ------------------------		 ---------     ----
   diffie-hellman-group14-sha256         This Draft    Section 3
   diffie-hellman-group15-sha512         This Draft    Section 3
   diffie-hellman-group16-sha512         This Draft    Section 3
   diffie-hellman-group17-sha512         This Draft    Section 3
   diffie-hellman-group18-sha512         This Draft    Section 3

to the "Key Exchange Method Names" registry of the "Secure Shell (SSH)
Protocol Parameters".

Then if the requirement levels are kept in this document, it is better
to move them to separate section and define them there, as those are
NOT IANA actions. Better option would be to move them to separate
document, which would include all requirement levels, also for other
algorithms (encryption, MAC etc). See example of that in
draft-ietf-ipsecme-rfc4307bis. 
-- 
[email-masked]