Subject: [Curdle] Benjamin Kaduk's Yes on draft-ietf-curdle-ssh-kex-sha2-18: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Fri, 25 Jun 2021 12:42:38 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-curdle-ssh-kex-sha2-18: Yes

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:
----------------------------------------------------------------------

Section 3.1.2

   Curve448 provides more security strength than Curve25519 at a higher
   computational and bandwidth cost.  The corresponding key exchange
   methods use SHA2-512 (also known as SHA-512) defined in [RFC6234].
   SHA2-512 is reasonable hash in both the KDF and integrity in both gss

nit: s/is reasonable hash/is a reasonable hash/

Section 3.2.2

   security strength.  It is a reasonably simple transition from SHA-1
   to SHA-2 and given that diffie-hellman-group14-sha1 and diffie-
   hellman-group14-sha256 share a MODP group and only differ in the hash
   function used for the KDF and integrity.  Given that diffie-hellman-

nit: add another clause to the end of this sentence, for "only differ in
the hash function used for the KDF and integrity, it is a
correspondingly simple transition from implementing
diffie-hellman-group14-sha1 to implementing
diffie-hellman-group14-sha256".

Section 4

The current/new recommendation for gss-group16-sha512-* in the table
here is SHOULD, but Table 10 (correctly, in my understanding) lists it
as MAY.

The "previous recommendation" value of "MAY" for rsa1024-sha1 and
rsa2048-sha256 is probably accurate as the implicit default behavior,
but does not seem to be specifically supported by text in RFC 4432.

One note for the rest of the IESG: the table entries for
ecdh-sha2-nistp256/ecdh-sha2-nistp384/ecdh-sha2-nistp521/ list the
previous recommendation as "MUST", which is defensible, given that RFC
5656 does say "Every compliant SSH ECC implementation MUST implement
ECDH key exchange" ... it might, however, be debatable what "compliant
SSH ECC implementation" actually encompasses.

---

From: mbaushke ietf <[email-masked]>
Date: Fri, 25 Jun 2021 13:54:25 -0700

[Resending from a subscribed email address]

Look for MDB in-line.

> On Jun 25, 2021, at 12:42 PM, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
> 

MDB: I agree.

> diffie-hellman-group14-sha256".

MDB: I agree.

> here is SHOULD, but Table 10 (correctly, in my understanding) lists it

MDB: Yes. RFC 8732 give gss-group16-sha512-* SHOULD status.
So, I will mark it as a transition from SHOULD to MAY in section 4.

> but does not seem to be specifically supported by text in RFC 4432.

MDB: I assumed that writing the RFC indicates an implicit MAY.

> SSH ECC implementation" actually encompasses.

MDB: Yes. The MUST I read from RFC 5656 is that having an RFC 5656 ECDH named curve means that all of the named curves MUST be supported for both ECDH and ECDSA.

Are there any other comments from anyone else?

I can either let the AUTH48 editor handle them, or I can submit draft -19 with the changes you asked for above.

       Be safe, stay healthy,
       -- Mark

---

From: Mark Baushke <[email-masked]>
Date: Fri, 25 Jun 2021 13:49:55 -0700

> https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/

I agree.

> diffie-hellman-group14-sha256".

I agree.

> here is SHOULD, but Table 10 (correctly, in my understanding) lists it

Hmmm... Yes. RFC 8732 give gss-group16-sha512-* SHOULD status.
So, I will mark it as a transition from SHOULD to MAY in section 4.

> but does not seem to be specifically supported by text in RFC 4432.

Yeah. I presumed that writing the RFC indicates an implicit MAY.

> SSH ECC implementation" actually encompasses.

Yes. The MUST I read from RFC 5656 is that having an RFC 5656 ECDH named curve means that all of the named curves MUST be supported for both ECDH and ECDSA.

        Be safe, stay healthy
        -- Mark

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 25 Jun 2021 19:10:05 -0700

> > On Jun 25, 2021, at 12:42 PM, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
[...]
> Are there any other comments from anyone else?

Not yet :)

> I can either let the AUTH48 editor handle them, or I can submit draft -19 with the changes you asked for above.

Given that the IESG hasn't started looking at it yet (it's on the agenda
for July 15th), I'd go ahead and submit the -19 now.

Thanks,

Ben

---

From: mbaushke ietf <[email-masked]>
Date: Fri, 25 Jun 2021 19:39:00 -0700

> On Jun 25, 2021, at 7:10 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

Done.

        -- Mark