Subject: [Curdle] draft-ietf-curdle-ssh-kex-sha2 and diffie-hellman-group1-sha1 (1024-bit DH)

From: Tero Kivinen <[email-masked]>
Date: Mon, 17 Jul 2017 13:06:15 +0300

I think it is bad idea to go from MUST to implement algorithm to MUST
NOT implement in one step. Especially as this will make all current
ssh implementations non-conforming as they do still implement
diffie-hellman-group1-sha1 even when it might be disabled by default.

We are defining here a MUST implement and MUST not implement, not MUST
use and MUST NOT use recommendations.

In IPsec we moved from MUST to SHOULD NOT just because that reason,
i.e., we didn't want to make all implementations non-conforming, and
forbid backwards compatibility with old implementations which might
only support previous MUST implement algorithm.

Also I guess there is quite a lot of ssh implementations in routers
and other devices which might not get updates very quickly, and they
might only support diffie-hellman-group1-sha1, and with this change,
new implementations cannot talk to them, as new implementations MUST
NOT implement diffie-hellman-group1-sha1.

I would suggest changing it to SHOULD NOT and say that in future it
might be changed to MUST NOT.
-- 
[email-masked]

---

From: Russ Housley <[email-masked]>
Date: Mon, 17 Jul 2017 07:39:32 -0400

I agree with Tero.  However, I like the use of SHOULD+ and MUST- to signal to project and product planners what is coming.  

Russ

> On Jul 17, 2017, at 6:06 AM, Tero Kivinen <[email-masked]> wrote:
>

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 17 Jul 2017 15:25:33 +0300

Russ Housley writes:
> I agree with Tero.  However, I like the use of SHOULD+ and MUST- to
> signal to project and product planners what is coming.   

Actually it is much better to explain that kind of things in the
actual text. For example:

3.5.  diffie-hellman-group14-sha1

   This method uses [RFC3526] group14 (a 2048-bit MODP group) which has
   no concerns.  This generated key exchange group uses SHA-1 which has
   security concerns [RFC6194].  However, this group is still strong
   enough and is widely deployed.  This method is being moved from MUST
   to SHOULD- to aid in transition to stronger SHA-2 based hashes. This
   method will transition to MUST NOT when SHA-2 alternatives are more
   generally available.

Gives much better information what to expect than SHOULD- in table.
SHOULD+, SHOULD- were useful when we only had table of requirement
levels. Now when we have the text about each algorithm explain the
reasoning, those + and - characters are getting more and more
meaningless.

For example the SHOULD- is defined in section 2 to mean that this
algorithm will be deprecated to MAY in future version, but in practice
we quite often go from SHOULD- to SHOULD NOT (or even MUST NOT, as the
text above suggests).

Anyways this is separate issue than wheter we should make
implementations having code for diffie-hellman-group1-sha1
non-conforming by publishing that implementations MUST NOT implement
diffie-hellman-group1-sha1...
-- 
[email-masked]

---

From: "Mark D. Baushke" <[email-masked]>
Date: Mon, 17 Jul 2017 08:27:28 -0700

Hi Tero,

> diffie-hellman-group1-sha1 even when it might be disabled by default.

I see your point.

> use and MUST NOT use recommendations.

For reference, there are five key exchanges that
draft-ietf-curdle-ssh-kex-sha2-08 marks as "MUST NOT"

          Key Exchange Method Name           Reference  Implement
          ---------------------------------- ---------- ---------
          diffie-hellman-group1-sha1         RFC4253    MUST NOT
          diffie-hellman-group-exchange-sha1 RFC4419    MUST NOT
          gss-gex-sha1-*                     RFC4462    MUST NOT
          gss-group1-sha1-*                  RFC4462    MUST NOT
          rsa1024-sha1                       RFC4432    MUST NOT

Of these, only diffie-hellman-group1-sha1 is moving from MUST to MUST
NOT. Due to 1024-bit Diffie-Hellman being considered by many as having
too little security (the same would be true of gss-group1-sha1-*).

What transition period is desirable for taking group1 "MUST" to "SHOULD
NOT" to "MUST NOT" ? Is it possible to codify both "SHOULD NOT" and 
"MUST NOT" time frames into one RFC?

While we are on the topic of this draft, let me point out that the
SHOULD- are on the way to SHOULD NOT and the SHOULD+ may be heading to
MUST. Do folks agree with these choices? They are really more of a guide
to best practices than they are to implementors who have already
implemented the older Key exchanges.

There are three which are marked as "SHOULD-" 

          Key Exchange Method Name           Reference  Implement
          ---------------------------------- ---------- ---------
          diffie-hellman-group14-sha1        RFC4253    SHOULD-
          ecdh-sha2-nistp256                 RFC5656    SHOULD-
          gss-group14-sha1-*                 RFC4462    SHOULD-

There are four that are marked as "SHOULD+" 

          Key Exchange Method Name           Reference  Implement
          ---------------------------------- ---------- ---------
          curve25519-sha256                  ssh-curves SHOULD+
          diffie-hellman-group16-sha512      new-modp   SHOULD+
          ecdh-sha2-nistp384                 RFC5656    SHOULD+
          gss-group16-sha512-*               gss-keyex  SHOULD+

The draft defines SHOULD+ and SHOULD- as:

    SHOULD+   This term means the same as SHOULD. However, it is likely
              that an algorithm marked as SHOULD+ will be promoted at
              some future time to be a MUST.
    SHOULD-   This term means the same as SHOULD. However, an algorithm
              marked as SHOULD- may be deprecated to a MAY in a future
              version of this document.

I have received one piece of private feedback that the IESG may not
want SHOULD- and SHOULD+ in this document.

	-- Mark

---

From: "Mark D. Baushke" <[email-masked]>
Date: Mon, 17 Jul 2017 08:45:33 -0700

> > signal to project and product planners what is coming.   

Thank you for the feedback.

> reasoning, those + and - characters are getting more and more

If I add "SHOULD NOT-" to the list and move diffie-hellman-group1-sha1
to it with this text:

      This method uses [RFC7296] Oakley Group 2 (a 1024-bit MODP group)
      and SHA-1 [RFC3174]. Due to recent security concerns with SHA-1
      [RFC6194] and with MODP groups with less than 2048 bits
      [NIST-SP-800-131Ar1], this method is considered insecure. This
      method is being moved from MUST to SHOULD NOT- instead of MUST NOT
      only to allow a transition time to get rid of it. It should be
      removed from server implementations as quickly as possible.

> we quite often go from SHOULD- to SHOULD NOT (or even MUST NOT, as the

Does this change make more sense?

    SHOULD+      This term means the same as SHOULD. However, it is
                 likely that an algorithm marked as SHOULD+ will be
                 promoted at some future time to be a MUST.

    SHOULD-      This term means the same as SHOULD. However, an
                 algorithm marked as SHOULD- will be deprecated to a
		 MAY in a future version of this document.

    SHOULD NOT-  This term means the same as SHOULD NOT. However, an
                 algorithm marked as SHOULD NOT- will be deprecated to
		 a MUST NOT in a future version of this document.

> diffie-hellman-group1-sha1...

Okay. I can make this change later today.

I will probably also add the SHOULD NOT- unless there is strong
objection.

	-- Mark

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 17 Jul 2017 19:32:49 +0300

>           Key Exchange Method Name           Reference  Implement

I think diffie-hellman-group1-sha1 is the only one where there is any
real issues, and only because it used to be mandatory. But of course
there might be others who want to keep some of the others in their
codebase too... 

> "MUST NOT" time frames into one RFC?

In IPsec we decided that unless algoritm is really broken (i.e., there
has been demonstration how it can be broken in public) we keep it
SHOULD NOT. 786-bit Diffie-Hellman got MUST NOT because it was
considered broken. The another 1024-bit Diffie-Hellman group which was
generated so that we cannot be sure it is not backdoored, and which is
not used at all, also got marked as MUST NOT, but the same group
1024-bit group we are talking here was left as SHOULD NOT.

I am not familiar enough about the embedded ssh2 implementations to
know what they really support, and when we can go forward. In most
cases where we have been trying to guess when things are going away,
we have been wrong, so I wouldn't even try to do that, and it is
better to see what happens, and come back later when we see that those
algorithms are no longer used ever...
-- 
[email-masked]

---

From: denis bider <[email-masked]>
Date: Mon, 17 Jul 2017 15:07:04 -0600

I think Tero's assessments make sense.

I can provide anecdotal feedback that we still receive questions from users
about "how do I make this connection work?" where the problem is that the
other party supports only diffie-hellman-group1-sha1, and nothing else, so
the algorithm needs to be enabled.

Users SHOULD upgrade, of course, but in practice, many systems appear to be
upgraded at 10-year intervals. I expect we will continue to see occasional
demand for diffie-hellman-group1-sha1 for at least some 5 years. Although
it is off by default, we will be compelled to support it, simply because
despite its shortcomings, it is better than plaintext (by far).

denis

On Mon, Jul 17, 2017 at 10:32 AM, Tero Kivinen <[email-masked]> wrote:

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

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 18 Jul 2017 03:58:19 +0000

denis bider <[email-masked]> writes:

>other party supports only diffie-hellman-group1-sha1, and nothing else, so the
>algorithm needs to be enabled.
>
>demand for diffie-hellman-group1-sha1 for at least some 5 years. 

+1 on all of that, matches my experience exactly, and not just diffie-hellman-
group-exchange-sha1 but diffie-hellman-group14-sha1 as well.  There's even a
large router manufacturer whose name rhymes with Frisco whose *security
appliances* only support diffie-hellman-group1-sha1 on some of their devices
(yeah, that's so bad that I'm not going to grant them anonymity :-).

Oh, and another router vendor who until a few years ago was using an ssh.com
implementation from 1999.

And who knows what else is out there, I've got so many bug-workarounds enabled
by now that I don't see half the problems any more.

Peter.

---

From: Damien Miller <[email-masked]>
Date: Thu, 20 Jul 2017 10:59:39 +1000 (AEST)

>           Key Exchange Method Name           Reference  Implement

Anecdata: OpenSSH has disabled diffie-hellman-group1-sha1 by default
for approximately two years in the client and for considerably longer in
the server.

Opinion: there's still enough old junk out there that optional support for
diffie-hellman-group1-sha1 is probably necessary for a while longer.
IMO this is probably worth an explicit note in the draft.

-d

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 20 Jul 2017 02:51:29 +0000

Damien Miller <[email-masked]> writes:

>diffie-hellman-group1-sha1 is probably necessary for a while longer. IMO this
>is probably worth an explicit note in the draft.

That's the catch-22 with something like this, on the one hand you want to make
it MUST NOT so you've got something to hit vendors over the head with when
they keep using RSA512 with MD5, on the other hand if they've got existing
equipment they're just going to demand that you change your code to work with
it.

As an aside, it would be nice if OpenSSH had some single enable-legacy-mode
switch to re-enable all the MUST algorithms that are currently disabled,
having to send people to https://www.openssh.com/legacy.html so they can
figure out by trial and error which incantation they need to use each time
they can't interop with current versions of OpenSSH is a pain.  Or at least
change the error message to tell people what to do to make it work.

Peter.

---

From: Damien Miller <[email-masked]>
Date: Thu, 20 Jul 2017 13:50:33 +1000 (AEST)

> change the error message to tell people what to do to make it work.

When I wrote legacy.html I tried to SEO it so it was the first search
result for the error message in question (it seems to have worked -- for
now).

The error message does include the set of algorithms that the user would
need to add, but I don't want to include cookbook instructions in the
error message because users will too-often just do what the cookbook says
without understanding the tradeoff they are making.

-d

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 20 Jul 2017 04:15:34 +0000

Damien Miller <[email-masked]> writes:

>When I wrote legacy.html I tried to SEO it so it was the first search result
>for the error message in question (it seems to have worked -- for now).

That assumes OpenSSH is the client.  When I run into it it's always the
server, so there's no error message or other information available.

Peter.

---

From: Damien Miller <[email-masked]>
Date: Fri, 21 Jul 2017 10:54:09 +1000 (AEST)

> server, so there's no error message or other information available.

Isn't it the client's job to generate a useful error then?

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 21 Jul 2017 03:21:45 +0000

>Isn't it the client's job to generate a useful error then?

What error message could the client display?  All it knows is that the remote
server claims to be OpenSSH, and it shut down the connection after getting the
client hello.  At which point you're back to trial-and-error with the server
admin to try and get them to figure out a config that works.

And then the next server.

And then the next server.

And then the next one.

Peter.

---

From: Damien Miller <[email-masked]>
Date: Fri, 21 Jul 2017 14:14:27 +1000 (AEST)

> admin to try and get them to figure out a config that works.

The server doesn't shut down the connection before sending its own KEXINIT
that includes the set of supported algorithms.

-d

---

From: "Mark D. Baushke" <[email-masked]>
Date: Sun, 23 Jul 2017 20:26:03 -0700

Hi Folks,

In the wake of the IETF 99 Curdle meeting, I am in the process of
updating the draft-ietf-curdle-ssh-kex-sha2 draft. The following are the
summary of changes:

 - remove use of SHOULD+ and SHOULD-

 - enumerate all of the Key exchange methods. The table will still have
   only the non-default "MAY" values, but all entries will exist with a
   brief indication stating that they MAY be implemented instead of
   the stronger SHOULD or MUST or SHOULD NOT or MUST NOT.

 - I am listing diffie-hellman-group1-sha1 as a SHOULD NOT (because it
   was a MUST preiously), but I am also listing gss-group1-sha1-* as a
   SHOULD NOT for consistency. Is this okay? Or, should I list the gss
   group as a MUST NOT?

 - I am thinking that gss-group14-sha1-* is better as a MAY than a
   SHOULD.

Everything else is MAY, here is the suggested new guidance:

         Key Exchange Method Name           Reference  Implement
         ---------------------------------- ---------- ----------
         curve25519-sha256                  ssh-curves SHOULD
         diffie-hellman-group-exchange-sha1 RFC4419    SHOULD NOT
         diffie-hellman-group1-sha1         RFC4253    SHOULD NOT
         diffie-hellman-group14-sha1        RFC4253    SHOULD
         diffie-hellman-group14-sha256      new-modp   MUST
         diffie-hellman-group16-sha512      new-modp   SHOULD
         ecdh-sha2-nistp256                 RFC5656    SHOULD
         ecdh-sha2-nistp384                 RFC5656    SHOULD
         gss-gex-sha1-*                     RFC4462    SHOULD NOT
         gss-group1-sha1-*                  RFC4462    SHOULD NOT
         gss-group14-sha256-*               gss-keyex  SHOULD
         gss-group16-sha512-*               gss-keyex  SHOULD
         gss-nistp256-sha256-*              gss-keyex  SHOULD
         gss-nistp384-sha384-*              gss-keyex  SHOULD
         gss-curve25519-sha256-*            gss-keyex  SHOULD
         rsa1024-sha1                       RFC4432    MUST NOT

I also have a new piece of text that tries to describe the section of
SHA256 vs SHA384 vs SHA512. However, I am not sure it is reasonable.
I provide it here for your comments:

    Selecting an appropriate hashing algorithm

       As may be seen from the above, the Key Exchange Methods area
       all using either SHA256 or SHA512 with the exception of the
       ecdh-sha2-nistp384 which uses SHA384.

       The cited CNSA Suite specifies the use of SHA384 and says that
       SHA256 is no longer good enough for TOP SECRET. Nothing is said
       about the use of SHA512. It may be that the internal state of
       1024 bits in both SHA384 and SHA512 makes the SHA384 more
       secure because it does not leak an additional 128 bits of
       state. Of course, use of SHA384 also reduces the security
       strength to 192 bits instead of being 256 bits or more. This
       seems to contradict the desire to double the symmetric key
       strength in order to try to be safe from Post Quantum Computing
       (PQC) attacks given a session key derived from the key
       exchange will be limited to the security strength of the hash
       being used.

       The move away from SHA256 to SHA512 for the newer key exchange
       methods is more to try to slow Grover's algorithm (a PQC
       attack) slightly. It is also the case that SHA2-512 may, in
       many modern CPUs, be implemented more efficiently using 64-bit
       arithmetic than SHA256 which is faster on 32-bit CPUs. The
       selection of SHA384 vs SHA512 is more about reducing the number
       of code point alternatives to negotiate. There seemed to be
       consensus in favor of SHA2-512 over SHA2-384 for key exchanges.

Before I publish -09, it would be nice to see if this list
is reasonable or not for other folks on the list.

Interesting note: I did not find a gss-gex-sha2-* defined in RFC4462.
It is also not found in the I-D.ietf-curdle-gss-keyex-sha2 draft.

	Thank you,
	-- Mark

PS: For completness, here is the list of all of the Key Exchanges
methods in my current copy of the draft.

     3.1.  curve25519-sha256 . . . . . . . . . . . . . . . . . . . .   4
     3.2.  curve448-sha512 . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  diffie-hellman-group-exchange-sha1  . . . . . . . . . . .   4
     3.4.  diffie-hellman-group-exchange-sha256  . . . . . . . . . .   4
     3.5.  diffie-hellman-group1-sha1  . . . . . . . . . . . . . . .   4
     3.6.  diffie-hellman-group14-sha1 . . . . . . . . . . . . . . .   5
     3.7.  diffie-hellman-group14-sha256 . . . . . . . . . . . . . .   5
     3.8.  diffie-hellman-group15-sha512 . . . . . . . . . . . . . .   5
     3.9.  diffie-hellman-group16-sha512 . . . . . . . . . . . . . .   5
     3.10. diffie-hellman-group17-sha512 . . . . . . . . . . . . . .   6
     3.11. diffie-hellman-group18-sha512 . . . . . . . . . . . . . .   6
     3.12. ecdh-sha2-nistp256  . . . . . . . . . . . . . . . . . . .   6
     3.13. ecdh-sha2-nistp384  . . . . . . . . . . . . . . . . . . .   6
     3.14. ecdh-sha2-nistp521  . . . . . . . . . . . . . . . . . . .   6
     3.15. gss-gex-sha1-*  . . . . . . . . . . . . . . . . . . . . .   6
     3.16. gss-group1-sha1-* . . . . . . . . . . . . . . . . . . . .   7
     3.17. gss-group14-sha1-*  . . . . . . . . . . . . . . . . . . .   7
     3.18. gss-group14-sha256-*  . . . . . . . . . . . . . . . . . .   7
     3.19. gss-group15-sha512-*  . . . . . . . . . . . . . . . . . .   7
     3.20. gss-group16-sha512-*  . . . . . . . . . . . . . . . . . .   7
     3.21. gss-group17-sha512-*  . . . . . . . . . . . . . . . . . .   8
     3.22. gss-group18-sha512-*  . . . . . . . . . . . . . . . . . .   8
     3.23. gss-nistp256-sha256-* . . . . . . . . . . . . . . . . . .   8
     3.24. gss-nistp384-sha384-* . . . . . . . . . . . . . . . . . .   8
     3.25. gss-nistp521-sha512-* . . . . . . . . . . . . . . . . . .   8
     3.26. gss-curve25519-sha256-* . . . . . . . . . . . . . . . . .   8
     3.27. gss-curve448-sha512-* . . . . . . . . . . . . . . . . . .   8
     3.28. rsa1024-sha1  . . . . . . . . . . . . . . . . . . . . . .   8
     3.29. rsa2048-sha256  . . . . . . . . . . . . . . . . . . . . .   9