Subject: [Curdle] Which curves are MUST and SHOULD ?

From: "Salz, Rich" <[email-masked]>
Date: Tue, 1 Dec 2020 16:38:16 +0000

>    PS: Note I have NOT uploaded the -13 edition of the document pending
    feedback/consensus on the ecdh-sha2-nistp{256,384,512} being SHOULD
    instead of MUST. I would be more likely to want curve25519-sha256 to be
    a MUST rather than SHOULD than the nistp curves be a MUST... mostly due
    to personal bias.

Pulling this topic into a separate thread.

If you have opinions on NIST and X25519, please speak up now.

---

From: Loganaden Velvindron <[email-masked]>
Date: Tue, 1 Dec 2020 20:51:35 +0400

>     a MUST rather than SHOULD than the nistp curves be a MUST... mostly due

I think that x25519 is widely deployed as part of newer SSH implementations.
[URL: https://ianix.com/pub/curve25519-deployment.html#x25519-ssh ]
Therefore it should be a MUST.

> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle

---

From: Simo Sorce <[email-masked]>
Date: Tue, 01 Dec 2020 13:57:20 -0500

> If you have opinions on NIST and X25519, please speak up now.

I do not personally have any bias toward NIST vs x25519 curves, but in
practice the x25519 curve should be a MUST because it is the most
widely deployed, while the NIST curves should be a SHOULD because of
wide adoption in FIPS environments.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

---

From: Daniel Migault <[email-masked]>
Date: Tue, 1 Dec 2020 21:37:43 -0500

I think the reason for SHOULD is to let time for implementations to
integrate it, but since that is already the case I agree we can have it to
MUST. This also aligns with recommended modern TLS profile from mozilla.
Yours,
Daniel

-- 
Daniel Migault
Ericsson

---

From: "Mark D. Baushke" <[email-masked]>
Date: Tue, 1 Dec 2020 21:02:38 -0800

Hi Folks,

Daniel Migault <[email-masked]> writes:

> integrate it,

Yes.

> but since that is already the case I agree we can have it to MUST.

Actually, I am aware of only ten implementations that have support for
curve25519-sha256 ... if you know of more, please let me know.

> This also aligns with recommended modern TLS profile from mozilla.

Is there an Informative Reference I should add to this draft to
reference the TLS profile?

Looking at this URL:

  https://ssh-comparison.quendi.de/comparison/kex.html

(which I suspect does NOT include all SSH implementations some of which
are commercial).

I will note that the count of SSH implementations in support Key
Exchange algorithms and is not entirely relevant to this IETF Draft
given the intent of the draft is to increase the implementations that
support the SHOULD algorithms.

My primary intent for this draft is to deprecate 'weak' key exchanges
and to try to promote at least one new Mandatory to Implement algorithm
as well as provide guidance from this community as to which key
exchanges are desirable for implementors to converge on using. It is my
hope that the 'best' key exchanges for each of FFC and ECC and IFC
algorithms. I fully expect this RFC to be replaced in a few years as
techniques to attach the key exchanges in this draft are found to be
weak or vulnerable.

 Count         Key exchange

    45         diffie-hellman-group1-sha1
    44         diffie-hellman-group14-sha1
    38         diffie-hellman-group-exchange-sha1
    35         diffie-hellman-group-exchange-sha256
    30         ecdh-sha2-nistp256
    25         ecdh-sha2-nistp521
    25         ecdh-sha2-nistp384
    14         [email-masked]
    10         diffie-hellman-group14-sha256
    10         curve25519-sha256
     9         diffie-hellman-group16-sha512
     7         diffie-hellman-group18-sha512
     5         rsa2048-sha256
     5         rsa1024-sha1
     4         gss-gex-sha1-*
     4         ext-info-c
     4         diffie-hellman-group15-sha512
     3         gss-group14-sha1-*
     3         gss-group1-sha1-*
     3         ecdh-sha2-1.3.132.0.10 (this is the ansip256k1 curve)
     3         diffie-hellman-group17-sha512
     3         diffie-hellman-group16-sha256
     3         diffie-hellman-group15-sha256
     3         curve448-sha512
     2         [email-masked]
     2         [email-masked]
     2         [email-masked]
     2         [email-masked]
     2         [email-masked]
     2         [email-masked]
     1         [email-masked]
     1         gss-nistp521-sha512-*
     1         gss-nistp384-sha256-*
     1         gss-nistp256-sha256-*
     1         gss-group18-sha512-*
     1         gss-group17-sha512-*
     1         gss-group16-sha512-*
     1         gss-group15-sha512-*
     1         gss-group14-sha256-*
     1         gss-gex-sha256-*
     1         gss-curve448-sha512-*
     1         gss-curve25519-sha256-*
     1         gss-13.3.132.0.10-sha256-*
     1         ext-info-s
     1         [email-masked]
     1         [email-masked]
     1         [email-masked]
     1         [email-masked]
     0         ecmqv-sha2

Of course, this draft will NOT be listing the 'private' @domain.name
exchanges.

	Be safe, stay healthy,
	-- Mark

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 5 Dec 2020 11:47:24 -0800

> reference the TLS profile?

I assume it refers to
https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility but
am not sure whether we think that is a stable enough URL to mention in the
RFC.

> techniques to attach the key exchanges in this draft are found to be

I think that the question of which key-exchange to mandate here is
entangled with the question of whether we want to be a leading or lagging
indicator of implementation support.  This draft targets the standards
track, where it (IMO) seems appropriate for us to be a leading indicator
(we would presumably wait some for implementations to catch up before any
attempt to move to full Internet Standard status).  If we were aiming for a
BCP then the debate would be harder (IMO).

-Ben

---

From: "Mark D. Baushke" <[email-masked]>
Date: Thu, 10 Dec 2020 09:34:21 -0800

Hi Folks,

Any other suggestions for change?

  MUST       diffie-hellman-group14-sha256

  SHOULD     curve25519-sha256
  SHOULD     gss-curve25519-sha256-*

  SHOULD     diffie-hellman-group16-sha512
  SHOULD     gss-group14-sha256-*
  SHOULD     gss-group16-sha512-*

  SHOULD     ecdh-sha2-nistp256
  SHOULD     gss-nistp256-sha256-*

  SHOULD     ext-info-c
  SHOULD     ext-info-s

  MAY        diffie-hellman-group14-sha1

  SHOULD NOT diffie-hellman-group-exchange-sha1
  SHOULD NOT diffie-hellman-group1-sha1

  SHOULD NOT gss-gex-sha1-*
  SHOULD NOT gss-group1-sha1-*

  MUST NOT   rsa1024-sha1

I am NOT certain about the nistp384 and nistp521. They are not
consistent between the ecdh-sha2-nistp* and gss-nistp* forms.
They most likely are best at SHOULD for all four of them.

Additional information is included below.

Benjamin Kaduk <[email-masked]> writes:

> https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility

I agree, this document is not stable enough to use as an Informative
reference for an RFC.

> BCP then the debate would be harder (IMO).

This draft has been in flight for a fairly long time (it was held up
waiting for some of the other RFCs in the Curdle WG which have been
added).

I would prefer that this document be a leading rather than a lagging
indicator, but that would mean it would potentially need a series of
successor documents and I am not entirely sure which WG would be
suitable.

There are no other BCPs for all the elements in SSH protocol:

 * Key Exchange Methods

 * Encryption Algorithms

 * MAC Algorithms

 * Public Key Algorithms

	Be safe, stay healthy,
	-- Mark

Current pending changes from -12 of the document:

   Updates: 4250
goes to
   Updates: 4250 4253 4432 4462

Section 3.2.3 name changed from
  "ECC diffie-hellman using ecdh-*, ecmqv, and gss"
to
  "ECC diffie-hellman using ecdh-*, ecmqv-sha2, and gss-nistp*"

Section 1 adds references to
"[RFC4253] [RFC4432] [RFC4462]" after "[RFC4250]"

Section 1.1, the second paragraph is expanded and rewritten as:

   At present, the attacks against SHA-1 are collision attacks that
   usually rely on human help rather than a pre-image attack.  SHA-1
   resistance against 2nd pre-image is still at 160 bits, but SSH does
   not depend on that, but rather on chosen prefix resistance.

   Transcript Collision attacks are documented in [TRANS-COLL].  This
   paper shows that the man in the middle does not tamper with the
   Diffie-Hellman values and does not know the connection keys.
   However, it manages to tamper with both Ic and Is, and can therefore
   downgrade the negotiated ciphersuite to a weak cryptographic
   algorithm that the attacker knows how to break.

   These attacks are still computationally very difficult to perform,
   but is is desirable that any Key Exchanging using SHA-1 be phased out
   as soon as possible.

   These attacks are potentially slightly easier when the server
   provides the Diffie-Hellman parameters such as using the [RFC4419]
   generated set of diffie-hellman parameters with SHA-1 hashing.  If
   there is a need for using SHA-1 in a Key Exchange for compatibility,
   it would be desirable it be listed last in the preference list of key
   exchanges.

Fixed a typo in 3.4 "eschange" -> "exchange"

diffie-hellman-group14-sha1 moves from "SHOULD" to "MAY"

Added an Informational Reference

   [TRANS-COLL]
              Bhargavan, K. and G. Leurent, "Transcript Collision
              Attacks: Breaking Authentication in TLS, IKE, and SSH",
              Network and Distributed System Security Symposium - NDSS
              2016, Feb 2016, San Diego, United
              States. 10.14722/ndss.2016.23418 . hal-01244855,
              <https://hal.inria.fr/hal-01244855/document>.

	Be safe, stay healthy,
	-- Mark

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 11 Dec 2020 00:38:48 +0000

>SHOULD NOT diffie-hellman-group-exchange-sha1

Just wondering why the hardcoded group is MAY but the negotiated, and probably
more secure, group is SHOULD NOT?  Is it because lots of legacy stuff will
only do the hardcoded group?

Peter.

---

From: Ron Frederick <[email-masked]>
Date: Thu, 10 Dec 2020 19:37:22 -0800

> only do the hardcoded group?

I imagine the reasoning behind most of these being SHOULD NOT is due to the use of SHA-1. As for making an exception for group14-sha1, I think the intent there was that it was one of the most commonly implemented algorithms due to it being one of two REQUIRED algorithms in RFC 4253. This proposal drops it from being REQUIRED, but still allows it for interoperability with older implementations that didn’t add support for anything stronger.

I agree that diffie-hellman-group-exchange-sha1 could in theory be more secure than diffie-hellman-group14-sha1, but I think it makes more sense to encourage implementations to support diffie-hellman-group-exchange-sha256. It’s nearly as widely implemented as the SHA-1 version of group exchange, and much stronger.

> They most likely are best at SHOULD for all four of them.

SHOULD for all of these works for me.

Regarding the nistp curves vs. curve25519, I also have a personal bias toward curve25519, but I worry about it being much less widely implemented than the nistp curves. I’m not sure we’ve seen wide enough implementation to justify move curve25519-sha256 to be a “MUST”. Even if we include the older naming of “[email-masked]”, it’s still only about half as widely implemented as the ECDH/ECDSA nistp algorithms.

Unfortunately, this still leaves us with a question about how we get at least one MUST in the algorithm list.
-- 
Ron Frederick
[email-masked]

---

From: "Mark D. Baushke" <[email-masked]>
Date: Thu, 10 Dec 2020 23:33:54 -0800

Peter Gutmann <[email-masked]> writes:

> Just wondering why the hardcoded group is MAY but the negotiated, and
> probably more secure, group is SHOULD NOT?

Mostly because diffie-hellman-group14-sha1 is a REQUIRED to implement
algorithm per RFC 4253.

This suggests that all implementations of SSH provide the implementation
as they were mandatory-to-implement in the original standard. So, by
suggesting MAY rather than SHOULD NOT, there is wiggle room for a time
to cross over from current implementtaions to future implementations
with at least one common KeX.

> Is it because lots of legacy stuff will only do the hardcoded group?

RFC 4419 and RFC 8270 provided the diffie-hellman-group-exchange-sha1
and diffie-hellman-group-exchange-sha256 but never specified them as
REQUIRED for an SSH implementation. At best, they are a MAY implement or
possibly they are implicitly a SHOULD given the 38 implementations
described on https://ssh-comparison.quendi.de/comparison/kex.html

It is shown in [TRANS-COLL] that sending thr eg,p diffie-hellman
parameters to a client that does not know what to expect for those
values with only a SHA1 hash allows for a substituion to potentially be
made for the p value. This implies the group-exchange mechanism may be
weaker when SHA1 is used.

I think I also read elsewhere that in a 6K or higher MODP group, there
was a higher possibility of created SHA1 collisions. However, I am
unable to find that reference at present.

The guidance of this draft suggests that any *-sha1 SHOULD NOT be
implemented and that the formerly REQUIRED and group14 SHA1 hashed
parameters MAY be implemented only as a transitional step.

If we were changing this draft into to a BCP, then group1-sha1 would be
certainly be a MUST NOT (due to the group1 of 1024-bits of MODP being so
weak) and group14-sha1 would be a SHOULD NOT or a MUST NOT (the former
to allow for legacy key exchanges and the latter based on a desire to
eliminate SHA1 entirely).

If there is consensus, I would be happy to make ALL *-sha1* KeX
algorithms get changed to MUST NOT as well as note that consistent with
RFC 8270, no group exchange MODP group should be less than 2048 bits...
that is instead of just being the recommended size it be the mandatory
minimum size.

That said, I have heard that there is some hardware in the field that is
barely able to do group1-sha1 and do not implement group14-sha1 even
though it is REQUIRED because it would take the very low power CPUs too
long to do a key exchange at all.

I'd like to hear from anyone who has an opinion if this RFC should be
closer to a BCP than just a deprecation of some KeX algorithms.

	Be safe, stay healthy,
	-- Mark

PS: The following is a summary from the current published -12 draft, my
work-in-progress -13 draft assuming it is NOT attempting to be a BCP and
what I suspect should be used if it were to be a leading BCP.

 Key Exchange Method Name             | draft -12  | draft -13  | BCP
 
 curve25519-sha256                    | SHOULD     | SHOULD     | SHOULD
 curve448-sha512                      | MAY        | MAY        | MAY
 diffie-hellman-group-exchange-sha1   | SHOULD NOT | SHOULD NOT | MUST NOT
 diffie-hellman-group-exchange-sha256 | MAY        | MAY        | MAY
 diffie-hellman-group1-sha1           | SHOULD NOT | SHOULD NOT | MUST NOT
 diffie-hellman-group14-sha1          | SHOULD     | MAY        | MUST NOT
 diffie-hellman-group14-sha256        | MUST       | MUST       | MUST
 diffie-hellman-group15-sha512        | MAY        | MAY        | MAY
 diffie-hellman-group16-sha512        | SHOULD     | SHOULD     | SHOULD
 diffie-hellman-group17-sha512        | MAY        | MAY        | MAY
 diffie-hellman-group18-sha512        | MAY        | MAY        | MAY
 ecdh-sha2-*                          | MAY        | MAY        | MAY
 ecdh-sha2-nistp256                   | SHOULD     | SHOULD     | SHOULD
 ecdh-sha2-nistp384                   | SHOULD     | SHOULD     | SHOULD
 ecdh-sha2-nistp521                   | SHOULD     | SHOULD     | SHOULD
 ecmqv-sha2                           | MAY        | MAY        | MAY
 ext-info-c                           | SHOULD     | SHOULD     | MUST
 ext-info-s                           | SHOULD     | SHOULD     | MUST
 gss-*                                | MAY        | MAY        | MAY
 gss-curve25519-sha256-*              | SHOULD     | SHOULD     | SHOULD
 gss-curve448-sha512-*                | MAY        | MAY        | MAY
 gss-gex-sha1-*                       | SHOULD NOT | SHOULD NOT | MUST NOT
 gss-group1-sha1-*                    | SHOULD NOT | SHOULD NOT | MUST NOT
 gss-group14-sha256-*                 | SHOULD     | SHOULD     | MUST
 gss-group15-sha512-*                 | MAY        | MAY        | MAY
 gss-group16-sha512-*                 | SHOULD     | SHOULD     | SHOULD
 gss-group17-sha512-*                 | MAY        | MAY        | MAY
 gss-group18-sha512-*                 | MAY        | MAY        | MAY
 gss-nistp256-sha256-*                | SHOULD     | SHOULD     | SHOULD
 gss-nistp384-sha384-*                | SHOULD     | SHOULD     | SHOULD
 gss-nistp521-sha512-*                | MAY        | SHOULD     | SHOULD
 rsa1024-sha1                         | MUST NOT   | MUST NOT   | MUST NOT
 rsa2048-sha256                       | MAY        | MAY        | MAY

---

From: denis bider <[email-masked]>
Date: Fri, 11 Dec 2020 01:52:49 -0600

The "group exchange" algorithm only negotiates group size, the actual group
parameters are not negotiated but simply dictated by the server. Servers
frequently generate groups which clients can't necessarily use,
specifically groups that fail FIPS tests. Therefore, the group exchange
algorithms are a major compatibility issue, in addition to that this one
also uses SHA-1.

On Thu, Dec 10, 2020 at 6:39 PM Peter Gutmann <[email-masked]>
wrote:

> probably

---

From: Ron Frederick <[email-masked]>
Date: Mon, 14 Dec 2020 19:44:40 -0800

> that is instead of just being the recommended size it be the mandatory

I’m not comfortable with algorithms going from REQUIRED to SHOULD NOT without some kind of transitional period. My suggestion would be to ease into this with SHOULD NOT for now. If you want to discuss BCP in this draft, perhaps that can be a separate section.

If you do try to cover BCP in this draft, I think it’s worth thinking about how implementations should handle interoperability with older or slower devices which don’t support modern ciphers. Running SSH with a weaker cipher may still be preferable to connecting to such a device in the clear with something like “telnet”, and some devices may only support SSH with weaker ciphers and not even provide a plaintext option. Perhaps the recommendation should be to simply disable these weaker ciphers by default but leave them available to be enabled on a case-by-case basis for when there aren’t any better options and admins can choose if they’re willing to make this trade-off.
-- 
Ron Frederick
[email-masked]

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 15 Dec 2020 16:09:13 +0000

>    I’m not comfortable with algorithms going from REQUIRED to SHOULD NOT without some kind of transitional period. My suggestion would be to ease into this with SHOULD NOT for now. If you want to d…

We've done it before, MD5, short RSA/DH keys, etc.

We shouldn't pretend that crypto-breaking advances haven't happened.

Admins can make trade-offs anyway.

---

From: Ron Frederick <[email-masked]>
Date: Tue, 15 Dec 2020 08:59:59 -0800

> Admins can make trade-offs anyway.

Sorry, I meant not going to “MUST NOT” here. I’m good with “SHOULD NOT”, or perhaps even something stronger but qualified with the fact that ineroperability with older/slower devices should be considered.
 -- 
Ron Frederick
[email-masked]

---

From: "Mark D. Baushke" <[email-masked]>
Date: Thu, 17 Dec 2020 11:35:24 -0800

> > Admins can make trade-offs anyway.

I am under the impression that the audience here is the maintainers of
SSHv2 software rather than the administrators that manage the sites
using it.

A "MUST NOT" recommendation would suggest that the code in support of
the particular entry could be deleted.

A "SHOULD NOT" recommendation would suggest that the code in support of
either be deleted or not available by default.

I do know of old hardware that implements only diffie-hellman-group1-sha1
(an embedded SunOS 5.8 running OpenSSH 3.4p1).

If you want an implementer to keep it around, then MAY is probably the
better alternative.

> Sorry, I meant not going to “MUST NOT” here. I’m good with “SHOULD
> NOT”, or perhaps even something stronger but qualified with the fact
> that ineroperability with older/slower devices should be considered.

Okay. so you would rather see the 1024-bit FFC prime used by
diffie-hellman-group1-sha1 with SHA1 moving from "MUST" to "SHOULD NOT"
rather than "MUST NOT".

What do other folks want for this one?

	Be safe, stay healthy,
	-- Mark