Subject: [Curdle] John Scudder's No Objection on draft-ietf-curdle-ssh-kex-sha2-19: (with COMMENT)

From: John Scudder via Datatracker <[email-masked]>
Date: Wed, 14 Jul 2021 17:12:09 -0700

John Scudder has entered the following ballot position for
draft-ietf-curdle-ssh-kex-sha2-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.)