Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange)

From: Damien Miller <[email-masked]>
Date: Mon, 15 Feb 2016 20:10:23 +1100 (AEDT)

On Mon, 15 Feb 2016, denis bider wrote:

> Being widely implemented is not sufficient for MUST.

No, but it is necessary.

> curve25519-sha256 has
> the unfortunate distinction of being widely deployed right after widespread
> recognition of the need for safe curves, but just before the upping of NSA
> recommendations.

It's a bit weird to see recognition of safe curves accepted in the same
sentence that advice from the NSA is uncritically accepted. Much of the
justification from the so-called safe curves is because most people don't
trust the NSA to set crypto standards any more.

> I intend to implement curve25519-sha256 in Bitvise SSH Server and Client
> when not used under FIPS. However, it cannot be available in FIPS mode,
> because its crypto is not covered by FIPS 140-2.

FIPS has lagged and will always lag current good practice (in which
year did it deprecate single-DES?). IMO FIPS compatibility is not a
justification to deny inclusion of an algorithm in the MUST set (though
it might be a justification for including an algorithm).

> I agree that safe curves are most likely superior to the ecdh-nistp
> curves, and provide greater safety of implementation. However, it puts
> the spec in conflict with reality if we specify a MUST algorithm that
> can't be used by a significant proportion of users.

MUST specifies what implementations have to support, not what users
can/can't use. nistp384/521 is already there for the subset of users
who are shackled to NIST-specified algorithms, but there is a very
substantial user population who want an alternative and
curve25519-sha256 has already proved itself a fine fit.

-d

---

From: denis bider <[email-masked]>
Date: Mon, 15 Feb 2016 08:45:59 +0000

Being widely implemented is not sufficient for MUST. curve25519-sha256 has the unfortunate distinction of being widely deployed right after widespread recognition of the need for safe curves, but just before the upping of NSA recommendations.

I intend to implement curve25519-sha256 in Bitvise SSH Server and Client when not used under FIPS. However, it cannot be available in FIPS mode, because its crypto is not covered by FIPS 140-2.

Then in addition, the use of a 255-bit curve, and SHA-256 as hash function, falls short of recent NSA recommendations for uniform standards of protection of classified material up to top secret.

curve448-sha512, if it were defined, would still not be usable under FIPS. However, it would at least the security recommendations: elliptic curve larger than 384 bits, with hash function SHA-384 or larger. On the other hand - if curve448-sha512 is not defined, then curve448-sha256 does not meet these standards either.

For these reasons, I would suggest curve448-sha512, if it were defined, as SHOULD; and curve25519-sha256 as MAY.

I agree that safe curves are most likely superior to the ecdh-nistp curves, and provide greater safety of implementation. However, it puts the spec in conflict with reality if we specify a MUST algorithm that can't be used by a significant proportion of users.

----- Original Message -----
From: Damien Miller 
Sent: Monday, February 15, 2016 02:00
To: Mark D. Baushke 
Cc: denis bider ; Niels Möller ; Peter Gutmann ; Simon Josefsson ; [email-masked] 
Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange)

On Sat, 13 Feb 2016, Mark D. Baushke wrote:

> Hi denis & Niels,
> 
> You have both made good points. I have adopted the updated text from
> denis and tried provide a meaning for the Note column. I have also added
> a pointer to the Simon's ssh-curves draft and included both of the
> currently published curve names in the table in this draft.
> 
> https://datatracker.ietf.org/doc/draft-baushke-ssh-dh-group-sha2/
> 
> Please let me know of additional comments.

IMO curve25519-sha256 should be a MUST, if not immediately then soon.
It's already supported under the [email-masked] alias by
a few implementations.

This paragraph:

>  The group15, group16, group17, and group18 names are the same as
>  those specified in [RFC3526] as 3072-bit MODP Group 14, 4096-bit MODP
>  Group 15, 6144-bit MODP Group 17, and 8192-bit MODP Group 18.

is incorrect: group 14 is 2048 bits, not 3072. Group 15 is 3072 bits,
not 4096. Group 16's length is not described (4096 bits). 17 and 18 are
correct.

I think the table of "Group modulus security strength estimates" should
have a reference - are these from NIST SP800-57?

-d