Subject: [Curdle] State of draft-ietf-curdle-ssh-kex-sha2?

From: denis bider <[email-masked]>
Date: Sat, 11 Jul 2020 12:15:10 -0500

Hey everyone,

I notice the following draft has not moved forward:

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

This seems to be an important draft which would standardize the current use
of key exchange algorithms in SSH. However, it looks like no changes have
been made in 2.5 years?

Did I miss some event where this draft morphed into something else so that
I'm not seeing the right information about progress?

Otherwise, what seems to be the current obstacle with making progress on
this?

denis

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 11 Jul 2020 18:39:58 +0000

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

  *   This seems to be an important draft which would standardize the current use of key exchange algorithms in SSH. However, it looks like no changes have been made in 2.5 years?

Looks like there was some AD feedback that was never addressed; see https://mailarchive.ietf.org/arch/msg/curdle/kf-iCb-o3yyxKLvH_pnGsxq7FVo/
(roughly a year ago).  I guess the chairs (myself included) let this fall through the cracks.

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 11 Jul 2020 18:40:51 +0000

See also https://mailarchive.ietf.org/arch/msg/curdle/Bmt_100BMUuVyUhNyNzVPVyGvlY/

From: Rich Salz <[email-masked]>
Date: Saturday, July 11, 2020 at 2:40 PM

  *   https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dcurdle-2Dssh-2Dkex-2Dsha2_&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=kjk-1wS-Ba-rq_gcvu8q7wovDKLrzWDAVRonYiTwXlE&s=jf8FE6xiVFlcTnjy75cR7kGwVzruFFQrlh3g3LWJo7Q&e=>

Looks like there was some AD feedback that was never addressed; see https://mailarchive.ietf.org/arch/msg/curdle/kf-iCb-o3yyxKLvH_pnGsxq7FVo/<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_curdle_kf-2DiCb-2Do3yyxKLvH-5FpnGsxq7FVo_&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=kjk-1wS-Ba-rq_gcvu8q7wovDKLrzWDAVRonYiTwXlE&s=fM_bC5zY2gVxjSNwflusaIOqfzgI6yUlPiGeN3R_e0w&e=>
(roughly a year ago).  I guess the chairs (myself included) let this fall through the cracks.

---

From: denis bider <[email-masked]>
Date: Sat, 11 Jul 2020 22:13:02 -0500

I do believe the other documents have been published now? So maybe it's
time for this draft?

On Sat, Jul 11, 2020 at 1:40 PM Salz, Rich <[email-masked]> wrote:

> See also
> https://mailarchive.ietf.org/arch/msg/curdle/Bmt_100BMUuVyUhNyNzVPVyGvlY/
>
>
>
> *From: *Rich Salz <[email-masked]>
> *Date: *Saturday, July 11, 2020 at 2:40 PM
>
>
>
>    - https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/
>    <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dcurdle-2Dssh-2Dkex-2Dsha2_&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=kjk-1wS-Ba-rq_gcvu8q7wovDKLrzWDAVRonYiTwXlE&s=jf8FE6xiVFlcTnjy75cR7kGwVzruFFQrlh3g3LWJo7Q&e=>
>
>
>
>    - This seems to be an important draft which would standardize the
>    current use of key exchange algorithms in SSH. However, it looks like no
>    changes have been made in 2.5 years?
>
>
>
> Looks like there was some AD feedback that was never addressed; see
> https://mailarchive.ietf.org/arch/msg/curdle/kf-iCb-o3yyxKLvH_pnGsxq7FVo/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_curdle_kf-2DiCb-2Do3yyxKLvH-5FpnGsxq7FVo_&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=kjk-1wS-Ba-rq_gcvu8q7wovDKLrzWDAVRonYiTwXlE&s=fM_bC5zY2gVxjSNwflusaIOqfzgI6yUlPiGeN3R_e0w&e=>
>

---

From: "Mark D. Baushke" <[email-masked]>
Date: Sun, 12 Jul 2020 02:36:41 -0700

Hi denis,

denis bider <[email-masked]> writes:

> This seems to be an important draft which would standardize the
> current use of key exchange algorithms in SSH. However, it looks like
> no changes have been made in 2.5 years?

Correct.

> Did I miss some event where this draft morphed into something else so
> that I'm not seeing the right information about progress?

I have not progressed the draft, mostly due to private email received
over two years ago...

A number of people told me to not move it forward until after all of the
RFCs for draft-ietf-curdle-ssh-curves (now RFC 8731) and
draft-ietf-curdle-gss-keyex-sha2 (now RFC 8732) were adopted. Also, many
people were unhappy with the characterizations of the existing
algorithms and my scoring of MUST, SHOULD, and MAY

In addition, there was a general dislike for the references of the NSA
documents provided or the CNSA document reference.

> Otherwise, what seems to be the current obstacle with making progress
> on this?

I think that work on the document is desirable. Does anyone wish to be a
co-author with me?

I would like to see more opinions on the list about which algorithms are
to be 'SHOULD NOT' and which are to be 'MUST' ... in general, I would
like to see this document as a KEX refernce that may be updated every
few years as we learn more about which KEX algorithms are best to use.

My opinion for Section 5 as I write this email today is:

      Key Exchange Method Name             Reference  Implement
      ------------------------------------ ---------- ----------
      curve25519-sha256                    RFC8731    SHOULD
      curve448-sha512                      RFC8731    MAY
      diffie-hellman-group-exchange-sha1   RFC4419    SHOULD NOT
      diffie-hellman-group-exchange-sha256 RFC4419    MAY
      diffie-hellman-group1-sha1           RFC4253    SHOULD NOT
      diffie-hellman-group14-sha1          RFC4253    SHOULD NOT
      diffie-hellman-group14-sha256        RFC8268    SHOULD
      diffie-hellman-group15-sha256        RFC8268    MAY
      diffie-hellman-group16-sha512        RFC8268    MUST
      diffie-hellman-group17-sha512        RFC8268    MAY
      diffie-hellman-group18-sha512        RFC8268    MAY
      ecdh-sha2-*                          RFC5656    MAY
      ecdh-sha2-nistp256                   RFC5656    SHOULD
      ecdh-sha2-nistp384                   RFC5656    SHOULD
      ecmqv-sha2                           RFC5656    MAY
      ext-info-c                           RFC8308    SHOULD
      ext-info-s                           RFC8308    SHOULD
      gss-*                                RFC4462    MAY
      gss-curve25519-sha256-*              RFC8732    SHOULD
      gss-curve448-sha512-*                RFC8732    MAY
      gss-gex-sha1-*                       RFC4462    SHOULD NOT
      gss-group1-sha1-*                    RFC4462    SHOULD NOT
      gss-group14-sha256-*                 RFC8732    SHOULD
      gss-group15-sha512-*                 RFC8732    MAY
      gss-group16-sha512-*                 RFC8732    SHOULD
      gss-group17-sha512-*                 RFC8732    MAY
      gss-group18-sha512-*                 RFC8732    MAY
      gss-nistp256-sha256-*                RFC8732    SHOULD
      gss-nistp384-sha384-*                RFC8732    MAY
      gss-nistp521-sha512-*                RFC8732    MAY
      rsa1024-sha1                         RFC4432    MUST NOT
      rsa2048-sha256                       RFC4432    MAY

The above list of KEX algorithms comes from the IANA ssh-parameters list
URL:
https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-16

Please let me know if I have missed any of the KEX algorithms in the
list.

Of these, I am not sure if rsa2048-sha256 has support for a 'MAY' or if
its lack of use would drive it to a 'SHOULD NOT' in the table.

To be honest, I am really not sure which KEX algorithms should be listed
as Mandatory To Implement (MTI) for key exchanges going forward.

Which diffie-hellman FFC group should be listed as MTI? group14-sha256
or group16-sha512? (I tentatively selected this one). Is that wise?
Should any FFC Diffie-Hellman group size be MTI?

I would like to hear if others on this list believe that
curve25519-sha256 should be a MUST or a SHOULD.

I also do not know if the expired draft-ietf-curdle-ssh-kex-sha2
document should bother to give opinions on any of the KEX options other
than those being deprecated or thrust into MTI. Opinions please?

It seems clear to me that removing the *-sha1* KEX algorithms is a good
idea. I would love to move diffie-hellman-group14-sha1, but I honestly
suspect that some hardware is deployed for which it is the only KEX
algorithm that may still need to be supported... which is the only
reason it is a 'SHOULD' on my list instead of a 'SHOULD NOT' ...

        Be safe, stay healthy,
        -- Mark

---

From: denis bider <[email-masked]>
Date: Sun, 12 Jul 2020 07:05:10 -0500

Hey Mark!

It looks like I found the key thing I missed: Google did not show me RFC
8268 when I searched for "diffie-hellman-group14-sha256". It finds it now
when I search for "rfc diffie-hellman-group14-sha256".

I could have found it in the IANA registry but I trusted the lack of Google
results in my first search. Alas.

That resolves the key concern for me: that names like
"diffie-hellman-group14-sha256"
are authoritatively defined. I was looking for this reference for the SSH
QUIC draft.

With regard to MUST / MAY / SHOULD / etc assignments, I agree with all of
these:

> curve25519-sha256                     SHOULD
> curve448-sha512                       MAY
> diffie-hellman-group-exchange-sha1    SHOULD NOT
> diffie-hellman-group-exchange-sha256  MAY
> diffie-hellman-group1-sha1            SHOULD NOT
> diffie-hellman-group14-sha1           SHOULD NOT
> diffie-hellman-group14-sha256         SHOULD
> diffie-hellman-group15-sha256         MAY

I do not agree with this one:

> diffie-hellman-group16-sha512   MUST

I find this too computationally expensive to justify "MUST" for servers.
Last time I checked, this costs about 100 ms in server CPU time, more on
weaker CPUs, and makes it trivial to DoS a resource-constrained server - no
DDoS needed.

I agree with all of these:

> diffie-hellman-group17-sha512  MAY
> diffie-hellman-group18-sha512  MAY
> ecdh-sha2-*                    MAY
> ecdh-sha2-nistp256             SHOULD
> ecdh-sha2-nistp384             SHOULD
> ecmqv-sha2                     MAY
> ext-info-c                     SHOULD
> ext-info-s                     SHOULD
> gss-*                          MAY

I conditionally agree on these:

> gss-curve25519-sha256-*  SHOULD
> gss-curve448-sha512-*    MAY
> gss-gex-sha1-*           SHOULD NOT
> gss-group1-sha1-*        SHOULD NOT
> gss-group14-sha256-*     SHOULD
> gss-group15-sha512-*     MAY
> gss-group16-sha512-*     SHOULD
> gss-group17-sha512-*     MAY
> gss-group18-sha512-*     MAY
> gss-nistp256-sha256-*    SHOULD
> gss-nistp384-sha384-*    MAY
> gss-nistp521-sha512-*    MAY

The condition is that the reader understands that "SHOULD" for these
methods applies only if you implement any GSS-API key exchange methods at
all. In other words, the whole category of GSS-API needs to be "MAY", but
within the category the above SHOULDs are appropriate as long as the
decision is made to implement any of the GSS-API key exchange methods in
the first place.

I agree with these:

> rsa1024-sha1             MUST NOT
> rsa2048-sha256           MAY

In summary - my main complaint is that "diffie-hellman-group16-sha512" is
too expensive to be a MUST. If that leaves no key exchange method that is a
"MUST", I'm fine with it.

If there needs to be a method that's a "MUST", I vote for either
"curve25519-sha256" or "diffie-hellman-group14-sha256" as meeting security
requirements while being the most widely compatible.

Now that I've found RFC 8268, I'm also fine if we can't get consensus on
this draft, though it would be a nice to have.

denis

---

From: Ron Frederick <[email-masked]>
Date: Sun, 12 Jul 2020 09:17:05 -0700

On Jul 12, 2020, at 5:05 AM, denis bider <[email-masked]> wrote:
> It looks like I found the key thing I missed: Google did not show me RFC 8268 when I searched for "diffie-hellman-group14-sha256". It finds it now when I search for "rfc diffie-hellman-group14-sha256".
> 
> I could have found it in the IANA registry but I trusted the lack of Google results in my first search. Alas.
> 
> That resolves the key concern for me: that names like "diffie-hellman-group14-sha256" are authoritatively defined. I was looking for this reference for the SSH QUIC draft.
> 
> With regard to MUST / MAY / SHOULD / etc assignments, I agree with all of these:
> 
> > curve25519-sha256                     SHOULD
> > curve448-sha512                       MAY
> I find this too computationally expensive to justify "MUST" for servers. Last time I checked, this costs about 100 ms in server CPU time, more on weaker CPUs, and makes it trivial to DoS a resource-constrained server - no DDoS needed.

I’m good with group16-sha512 remaining a “MAY” along with group17-sha512 and group18-sha512, What about group15-sha256, though? Should that perhaps be a “SHOULD”, and also group14-sha256 changed to a “MUST”? I think we want at least one DH algorithm to be listed as a “MUST”.

> The condition is that the reader understands that "SHOULD" for these methods applies only if you implement any GSS-API key exchange methods at all. In other words, the whole category of GSS-API needs to be "MAY", but within the category the above SHOULDs are appropriate as long as the decision is made to implement any of the GSS-API key exchange methods in the first place.

With that condition in mind, I think all of these should match their non-GSS equivalents in terms of MAY/SHOULD/MUST. So, if changes are made to group14/15/16, they should be reflected here as well.

> I agree with these:
> 
> > rsa1024-sha1             MUST NOT
> > rsa2048-sha256           MAY
> 
> In summary - my main complaint is that "diffie-hellman-group16-sha512" is too expensive to be a MUST. If that leaves no key exchange method that is a "MUST", I'm fine with it.
> 
> If there needs to be a method that's a "MUST", I vote for either "curve25519-sha256" or "diffie-hellman-group14-sha256" as meeting security requirements while being the most widely compatible.

I like having curve25519-sha256 as a strongly encouraged SHOULD, but I think it might be better to stick with group14-sha256 as the MUST.
-- 
Ron Frederick
[email-masked]

---

From: denis bider <[email-masked]>
Date: Sun, 12 Jul 2020 12:04:11 -0500

I think Ron's suggestions are all reasonable.

On Sun, Jul 12, 2020 at 11:17 AM Ron Frederick <[email-masked]> wrote:

> That resolves the key concern for me: that names like "diffie-hellman-group14-sha256"
> I’m good with group16-sha512 remaining a “MAY” along with group17-sha512
> and group18-sha512, What about group15-sha256, though? Should that perhaps
> be a “SHOULD”, and also group14-sha256 changed to a “MUST”? I think we want
> at least one DH algorithm to be listed as a “MUST”.
>
>
>
> With that condition in mind, I think all of these should match their
> non-GSS equivalents in terms of MAY/SHOULD/MUST. So, if changes are made to
> group14/15/16, they should be reflected here as well.
>
>
> I agree with these:
>
> > rsa1024-sha1             MUST NOT
> > rsa2048-sha256           MAY
>
> "curve25519-sha256" or "diffie-hellman-group14-sha256" as meeting
> security requirements while being the most widely compatible.
>
>
> I like having curve25519-sha256 as a strongly encouraged SHOULD, but I
> think it might be better to stick with group14-sha256 as the MUST.
> --
> Ron Frederick
> [email-masked]
>
>
>
>

---

From: Loganaden Velvindron <[email-masked]>
Date: Mon, 13 Jul 2020 00:23:56 +0400

>       Key Exchange Method Name             Reference  Implement
Personally, I think that it should be a MUST or at least a strong
SHOULD (SHOULD + ?)

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

---

From: "Mark D. Baushke" <[email-masked]>
Date: Mon, 13 Jul 2020 11:52:01 -0700

Hi Folks,

I have updated a new revision of draft-ietf-curdle-ssh-kex-sha2-11 for
your review which gives a survey of the Key Exchange Algorithms for
Secure Shell.

The current revision does NOT have any 'MUST' implement algorithms, but
does provide 'SHOULD NOT' for most of the algorithms using sha1.

As I understand it, the following are candidates for MUST:

  * diffie-hellman-group14-sha256
    [It is not clear to me how much longer 2048-bits will be considered
     strong enough.]

  * curve25519-sha256

  * ecdh-sha2-nistp256
    [Some folks are not happy with the current ECDH curves.]

I would look for discussion on the list about which Key Exchange
Algorithms are Mandatory to Implement going forward.

Fwiw: I will be attending the IETF 108 virtual conference, I believe
there will not be an IETF Curdle meeting.

	Be safe, stay healthy,
	-- Mark

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 13 Jul 2020 19:10:21 +0000

Thanks for the new draft, Mark!

Correct, CURDLE is not meeting.

---

From: Ron Frederick <[email-masked]>
Date: Mon, 13 Jul 2020 13:28:04 -0700

> Algorithms are Mandatory to Implement going forward.

Given the concerns about the NIST EC curves, I’d lean toward the current NIST ecdh-sha2-nist* curves being only SHOULD and not MUST.

I’m torn about curve25519 in this regard. I think it’s a good option, but I don’t know if we want to go as far as saying all compliant implementations must support it. For historical reasons, I’d lean toward doing that only with DH algorithms with an appropriate amount of strength, since it should be easier for existing implementations that support only DH today to move to those stronger key sizes & hashes.
-- 
Ron Frederick
[email-masked]

---

From: "Mark D. Baushke" <[email-masked]>
Date: Mon, 13 Jul 2020 13:53:47 -0700

Hi Mouse,

Mouse <[email-masked]> writes:

> Surely it wouldn't be that big a deal to generate a prime of, say, 4k
> bits, or whatever size gives people suitably warm fuzzies, to replace
> the current group-14 prime?

It is not hard to generate FFC DH parameter sets.

The issue is that many folks are paranoid that someone will create a DH
Backdoor

    How to Backdoor Diffie-Hellman
    https://eprint.iacr.org/2016/644
    See also URL:
    https://github.com/mimoo/Diffie-Hellman_Backdoor

The RFC4419 code in fact provides for a method to help SSH by giving us
as many different ephemeral parameter sets as a server may wish to
generate.

> I'd be happy to do the crucnhing for it, and I can't be the only
> person with RNG hardware and enough spare cycles to invest in whatever
> level of primality assurance keeps people happy.

We already have a number of alternatives for larger sizes we could use
taken from RFC 3526 (group15, group16, group17, group18) which are based
on the ration of a cirlce's circumference to its diamete ("pi").

I suppose we could also adopt RFC 7919 based on natural logarithm ("e").

Someone could also generate a new set of safe primes based on some other
transcendental number (square root of "2" or some other number).

My question is if we should literally require all SSH implementations to
have a Mandatory To Implement (MTI) DH parameter set now which may need
to be deprecated in a 'short' (for some value of the word short) period
of time.

Personally, I like FFC DH. I would not mind seeing

  Diffie-Hellman-group16-sha512 (a 4096-bit prime) 

as an MTI for SSH.

However, denis bider <[email-masked]> wrote:

> I find this too computationally expensive to justify "MUST" for
> servers. Last time I checked, this costs about 100 ms in server CPU
> time, more on weaker CPUs, and makes it trivial to DoS a
> resource-constrained server - no DDoS needed.

	Be safe, stay healthy,
	-- Mark

---

From: "Mark D. Baushke" <[email-masked]>
Date: Mon, 13 Jul 2020 14:58:05 -0700

[CC- Mouse <[email-masked]>] Moue's mail bounces my direct
email.

Mouse <[email-masked]> writes:

> > Someone could also generate a new set of safe primes based on some
> > other transcendental number (square root of "2" or some other
> > number).
> 
> The square root of 2 is not transcendental; it's irrational, yes, but
> it's algebraeic.

True enough, somehow the "2 raised to the power of" phrase got
accidentally deleted from my post. In otherwords, I meant the
Gelfond-Schneider constant or Hilbert number.

> > My question is if we should literally require all SSH implementations
> > to have a Mandatory To Implement (MTI) DH parameter set now which may
> > need to be deprecated in a 'short' (for some value of the word short)
> > period of time.
> 
> The only reason I see to have any MUSTs (rather than SHOULDs) is
> interoperability.

Yes.

	Be safe, stay healthy,
	-- Mark

---

From: denis bider <[email-masked]>
Date: Tue, 14 Jul 2020 16:16:03 -0500

(Replying to Curdle - the message I forward below was posted only on the
ole' [email-masked])

I'm pretty sure all the feedback so far suggests that
"diffie-hellman-group14-sha256" is the only key exchange method that has
consensus as a MUST right now.

With regard to group15 - if memory serves, the OpenSSH guys were
complaining about too much granularity in that regard, they preferred
group16+.

group16 and larger have my protest as a MUST because too expensive.

DH group exchange methods are not interoperable: implementations that
generate their own groups fail to interoperate with FIPS implementations
half of the time.

ECDH has protestations from some niche implementers. Curve25519 apparently
isn't coming soon to SSH clients that run on clothing tags.

That leaves "diffie-hellman-group14-sha256", which is sensible for MUST,
even though in no way ambitious.

(Note the lowercase "diffie-hellman-group14-...". I've seen someone
capitalize it in this thread. Per RFC 4251, SSH algorithm names are case
sensitive.)

In the SSH/QUIC draft, I opted for the following language:

"The requirement to implement any particular QUIC protocol version or TLS
cipher suite expires on the 5-year anniversary of the publishing of this
memo. At that point, implementers SHOULD consult any new standards
documents if available, or survey the practical use of SSH/QUIC for
implementation guidance."

Perhaps we could put in something like that, given that the only candidate
for MUST is the lowest common denominator that still meets current security
requirements.

denis

-------- Forwarded Message --------
Subject: Re: [Curdle] State of draft-ietf-curdle-ssh-kex-sha2?
Date: Tue, 14 Jul 2020 04:10:18 +0000
From: Peter Gutmann <[email-masked]>
To: Mouse <[email-masked]>, [email-masked]
<[email-masked]>

As an implementor, it is highly unlikely I will support anything elliptic
curve in the foreseeable future.

I support it but it's disabled by default because I can't think of a
commonly-
used cryptosystem more riddled with side-channels than (EC)DSA, and most of
them end up leaking the private key (that's ECDSA, not 25519 which is too
novel/nonstandard to be usable with anything I work with). In fact a recent
paper on yet another set of side-channel attacks (either "Minerva: The Curse
of ECDSA Nonces" or "Big Numbers - Big Troubles") mentions that this is
merely
the latest set of side-channels that need patching, and more are expected in
the future. And that's after several years of patching ECDSA side-channels
already.

At least with RSA you can just blind and be mostly done with it, you don't
have to deal with a mechanism where there's a linear relation between the
signing nonce and the private key, with everything around that tied up in
side-channels.

Peter.