Subject: [Curdle] Lars Eggert's Discuss on draft-ietf-curdle-ssh-kex-sha2-19: (with DISCUSS and COMMENT)

From: Lars Eggert via Datatracker <[email-masked]>
Date: Mon, 12 Jul 2021 06:21:02 -0700

Lars Eggert has entered the following ballot position for
draft-ietf-curdle-ssh-kex-sha2-19: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This document seems to have unresolved IANA issues, so I am holding a DISCUSS
for IANA until the issues are resolved.

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

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 15 Jul 2021 11:12:01 -0700

Hi Mark,

The resolution of our discussion today was that the IANA registry should
just have one new column for the current recommendations.

Please apply

OLD:
   IANA is requested to annotate entries in [IANA-KEX] with the
   suggested implementation guidance provided in section 4 "Summary
   Guidance for Key Exchange Method Names Implementation" in this
   document.  A summary may be found in Table 12 in section 4.  The
   entry with "MUST NOT" should be considered disallowed.  An entry with
   "SHOULD NOT" is deprecated and may be disallowed in the future.

NEW:
   IANA is requested to add a new column to [IANA-KEX] with heading "OK to
   Implement", and to annotate entries therein with the implementation
   guidance provided in section 4 "Summary Guidance for Key Exchange Method
   Names Implementation" in this document.  A summary may be found in Table 12
   in section 4.  IANA is additionally requested to include this document as
   an additional reference for the [IANA-KEX] registry.  Registry entries
   annotated with "MUST NOT" are considered disallowed.  Registry entries
   annoated with "SHOULD NOT" are deprecated and may be disallowed in the
   future.

Thanks,

Ben