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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Tue, 06 Jul 2021 08:15:58 -0700

Éric Vyncke 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:
----------------------------------------------------------------------

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

---

From: mbaushke ietf <[email-masked]>
Date: Thu, 8 Jul 2021 14:24:29 -0700

Hi Éric,

Note: I have been asked to not upload new revisions of the document by the Gen-ART reviewer, but I will try to address your comments in this message.

My comments are provided in-line below. Look for MDB:

> On Jul 6, 2021, at 8:15 AM, Éric Vyncke via Datatracker <[email-masked]> wrote:
> 

MDB: I have no objection to this change.

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

MDB: I am not sure what benefit that would bring.

The protocol already negotiates what algorithms will be used.

If there are no common algorithms to negotiate, then the connection will fail.

> DISCUSS after thinking twice***.

MDB:

The intent of the document is to provide a survey of all of the key exchanges mechanisms that have been written in RFCs and identify those which are to be disallowed (those transitioning to MUST NOT) or deprecated (those transitioning to SHOULD NOT) as well as to try to provide forward guidance of a new Mandatory to Implement key exchange (MUST).

It is my contention that the rest of the document addresses this paragraph.

If there is a better way to summarize what this RFC will do, please feel free to suggest it.

> numbers (e.g., group14) linked to the MODP group.

MDB:

RFC 4253 points to RFC 3526. In particular, section 3 of RFC 3526 is a 2048-bit MODP prime.

P = 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }
Q = (p-1)/2
G = 2

> which is more normative than 'guidance'.

MDB:

This RFC is providing guidance to both implementors of the SSH protocol and administrators who configure an implementation for use in their own environments.

In the case of administrators, only they really know the nature of their compute environment and are able to determine the performance of the systems which need to communicate over SSH.

> "less efficient" on which metric ? CPU utilization ? Memory utilization ?

MDB:

Many CPUs implement hardware acceleration for some cryptographic operations. The NISTP curves given in Table 8 are available for reduced use of both CPU and memory on some family of Intel chips. To the best of my knowledge, the ecdh-sha2-* family of OIDs and the ecmqv-sha2 are always slow and power hogs regardless of cryptographic chip being used.

Only the administrator of an SSH implementation will be able to run tests to see how efficient a given key exchanges may be for the hardware being used. So, that phrase was intended to provide a hint that these particular configuration may not be desirable without testing before deployment.

> What does "reserved" means in the 'RFCxxxx implement' means ? It smells like a

MDB:

RFCxxxx is intended to be the RFC number for the current draft when published.

IANA has already asked questions about the right way to implement Table 12 in the ssh-parameters-16 table of the existing IANA ssh-parameters document. I believe that Ben Kaduk will be speaking with the IESG for the right way to do this.

> The same applies for section 7 (IANA considerations).

MDB:

It is my hope that the draft will become an RFC and that the ssh-parameters-16 table will be updated to provide current guidance as the the usefulness of various key exchanges. Over time, I expect the table to be updated as cryptographic research finds ways to either break or render weak more key exchange algorithms. I hope that SSH implementations are able to be agile enough to allow administrators to disable broken key exchange algorithms as it becomes necessary.

It is my hope that the comments I have provided help in clearing up your concerns.

If you have additional concerns, please let me know.

        Be safe, stay healthy,
        -- Mark