Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)
draft-ietf-curdle-ssh-kex-sha2-20

[S1.1] [nit]

* s/is is/it is/

* s/it would be desirable it be listed last/
    it would be desirable for it to be listed last/  or maybe
    it would be desirable that it be listed last/?

[S3] [question]

* "Any method not explicitly listed MAY be implemented."

  This surprised me.  Are there no recommendations on minimum security
  strength below which MUST NOT applies?

  Perhaps something like "and not prohibited by other documents" or
  something (since, for example, anything with MD5 is not explicitly
  listed here :-).

Hi, Mark! Below are a few suggestions and comments.

1. Section 1.2

   It is desirable for the security strength of the key exchange be
   chosen to be comparable with the security strength of the other
   elements of the SSH handshake.  Attackers can target the weakest
   element of the SSH handshake.

I think you mean “It is desirable that”, right?

2. Section 3

   This RFC also collects key exchange method names in various existing
   RFCs [RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656],
   [RFC8268], [RFC8731], [RFC8732], and [RFC8308], and provides a
   suggested suitability for implementation of MUST, SHOULD, MAY, SHOULD
   NOT, and MUST NOT.  Any method not explicitly listed MAY be
   implemented.

It’s a little surprising that there’s no general guidance in the last sentence about minimal properties a method should have to qualify for MAY, vs. SHOULD NOT or MUST NOT. 

3. Section 3.2.2

      Given that diffie-
   hellman-group14-sha1 is being removed from MTI status

Please expand MTI on first use. (You do expand it, but later in the document.)

I support Lars's DISCUSS.

¯\_(ツ)_/¯

Thanks for the important updates.

I support Lars's discuss.

Some comments and nits --

* Section 1 : 

   ** "MAY" moving to "MUST" or "SHOULD" or "SHOULD NOT"
   or "MUST NOT") of various key exchange mechanisms.

   I didn't find this correct for the all the MAY in the table 12. some MAY also remains MAY.

* Section 1.1 : 
   ** s/but is is/but it is
   ** Should this be modified to use normative language? 
      OLD:
         It is suggested that the minimum secure hashing function that should
   be used for key exchange methods is SHA2-256.
      NEW:
         It is RECOMMENDED that SHA2-256 SHOULD be used as the minimum secure hashing for the key exchange methods.

* Section 3: Can we stick to one way of referencing the same document? either "this memo" or "this document"? we have three paragraphs referencing the same in three different ways.

Thank you for the work put into this document.

Special thanks for Daniel Migault' shepherd write-up about the WG process / consensus (I only regret that the write-up was not refreshed as it is dated January 2018). 

Please find below some non-blocking COMMENT points (but replies would be appreciated). I am still hesitating on a block DISCUSS (see section 1) though and could revisit my ballot position.

I hope that this helps to improve the document,

Regards,

-éric


== COMMENTS ==

-- Section 1.0 --
"The purpose of this RFC is to recommend" why not simply "This RFC recommends" ? 

Should "most SSH implementations" be qualified by a date?

"  This document updates [RFC4250] [RFC4253] [RFC4432] [RFC4462] by
   changing the requirement level ("MUST" moving to "SHOULD" or "MAY" or
   "SHOULD NOT", and "MAY" moving to "MUST" or "SHOULD" or "SHOULD NOT"
   or "MUST NOT") of various key exchange mechanisms."

I was about to raise a blocking DISCUSS on the above text because it is really unclear what the updates are. ***I may reconsider my current position to a DISCUSS after thinking twice***.

-- Section 1.2.2 --
I am not a cryptographer... so I would welcome some references to the group numbers (e.g., group14) linked to the MODP group.

-- Section 3.1.1 --
The table uses a 'Guidance' column which is weird in a standard track document, which is more normative than 'guidance'.

-- Section 3.1.3 --
"less efficient" on which metric ? CPU utilization ? Memory utilization ? Security ?

-- Section 4 --
What does "reserved" means in the 'RFCxxxx implement' means ? It smells like a IANA registry entry.

Table 12 has an unusual title "IANA guidance for key exchange method name implementations", do we expect IANA to give guidance about crypto resistance? The same applies for section 7 (IANA considerations).

Found terminology that should be reviewed for inclusivity:
 * Term "man"; alternatives might be "individual", "people", "person".
 * Term "traditional"; alternatives might be "classic", "classical",
   "common", "conventional", "customary", "fixed", "habitual", "historic",
   "long-established", "popular", "prescribed", "regular", "rooted",
   "time-honored", "universal", "widely used", "widespread".
See https://www.rfc-editor.org/part2/#inclusive_language for background and
more guidance.

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1. , paragraph 10, nit:
> ere have been attacks against SHA-1 and it is no longer strong enough for SS
>                                    ^^^^
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

Section 1.1. , paragraph 5, nit:
> ally very difficult to perform, but is is desirable that any key exchanging u
>                                     ^^^^^
Possible typo: you repeated a word.

Section 1.1. , paragraph 6, nit:
> patibility, it would be desirable it be listed last in the preference list o
>                                      ^^
After "it", use the third-person verb form "is".

Section 1.2.2. , paragraph 3, nit:
> rithm specified in [RFC4432]. RSA 1024 bit keys have approximately 80 bits of
>                                   ^^^^^^^^
When "1024-bit" is used as a modifier, it is usually spelled with a hyphen.

Section 1.2.2. , paragraph 3, nit:
> 80 bits of security strength. RSA 2048 bit keys have approximately 112 bits o
>                                   ^^^^^^^^
When "2048-bit" is used as a modifier, it is usually spelled with a hyphen.

Section 1.2.2. , paragraph 3, nit:
> rength needed for 3des-cbc, an RSA 2048 bit key matches the security strength
>                                    ^^^^^^^^
When "2048-bit" is used as a modifier, it is usually spelled with a hyphen.

Section 3.1.1. , paragraph 3, nit:
> s (nistp256, nistp384, nistp521) as well as other curves to be defined for t
>                                  ^^^^^^^^^^
Probable usage error. Use "and" after "both".

Section 3.2.2. , paragraph 2, nit:
> algorithm is used both in the KDF as well as for the integrity of the respons
>                                   ^^^^^^^^^^
Probable usage error. Use "and" after "both".

Section 3.2.2. , paragraph 2, nit:
> ing partially-broken algorithms laying around is not a good thing to do. The
>                                 ^^^^^^^^^^^^^
Did you mean "lying around"?

Section 4. , paragraph 3, nit:
> ing some of these groups as found in an this draft: Darren Tucker for OpenSS
>                                      ^^
Did you mean "and" or "any"?

Section 4. , paragraph 3, nit:
> ange methods that are considered weak so they are not in still actively in op
>                                      ^^^
Use a comma before "so" if it connects two independent clauses (unless they are
closely connected and short).

These URLs in the document can probably be converted to HTTPS:
 * http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-16

Two nits:

(1.1) this is optional, but

s/man in the middle/on-path attacker

Or other suitable synonym

(3.1.1) and (3.1.2) I cannot parse the sentences with the phrase "is a reasonable hash...", e.g.

SHA2-256 is a reasonable hash in both the KDF and integrity in both gss and non-gss uses of curve25519 key exchange methods.

Can you reword?

This for this document and spending the time to clean out old key exchange methods that are no longer sufficiently secure.