Subject: Re: [Curdle] Looking for comments on draft-ietf-curdle-ssh-kex-sha2

From: Simo Sorce <[email-masked]>
Date: Tue, 01 Dec 2020 10:36:05 -0500

On Thu, 2020-11-26 at 22:46 +0200, Tero Kivinen wrote:
> Mark D. Baushke writes:
> > I could add this informative reference:
> > 
> >     Karthikeyan Bhargavan, Gaeutan 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
> >     URL: https://hal.inria.fr/hal-01244855/document
> > 
> > to the informative section of the RFC and try to add additional
> > theoretical justification against SHA-1, is this really necessary?
> 
> I think it would be good idea to add that reference, even when it do
> consider that attack against ssh impractical with 2^77 work, but it do
> warn about not including weak ciphers in the list, and warn about the
> group exchange. 
> 
> > The paper does show that the group exchange (RFC4419) use of *-sha1 may
> > be somewhat easier to attack than the fixed group, but I have already
> > listed that as 'SHOULD NOT' in my -12 draft.
> 
> This could refer to this same paper.
> 
> > The real question here is if "SHOULD NOT" is the correct implementation
> > guidance for all use of diffie-hellman-group14-sha1 in key exchanges
> > which is a big jump from "MUST" right now. All of the other *-sha1
> > exchanges in the draft are listed as "SHOULD NOT" already.
> 
> I think it can still be SHOULD, just to keep backward compatibility
> with old devices. It does not need to be enabled by policy in default
> configuration, but sometimes you need to connect those devices, and it
> is painful if you need to find old version of some ssh client just to
> be able to connect to them.

A MAY is probably more adequate in this case. It means you can provide
it, but you are not out of spec if you decide not to implement it, and
not implementing it should be a valid choice.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

---

From: "Mark D. Baushke" <[email-masked]>
Date: Tue, 1 Dec 2020 08:18:50 -0800

Hi Simo,

> not implementing it should be a valid choice.

Yes, moving diffie-hellman-group14-sha1 to MAY makes sense to me.

I am unsure if ecdh-sha2-nistp256, ecdh-sha2-nistp384, and
ecdh-sha2-nistp512 should be MUST as given in RFC5656 or SHOULD
if ECC is being used at all.

After my .signature, I have provided a diff to handle the email
suggestions I have recevied since the -12 draft. Let me know if
this addresses your points.

Thank you for your patience in helping to reach consensus for this
draft.

	Be safe, stay healthy,
	-- Mark

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.

--- draft-ietf-curdle-ssh-kex-sha2-12.txt	2020-11-23 13:25:22.000000000 -0800
+++ draft-ietf-curdle-ssh-kex-sha2-13.txt	2020-12-01 08:06:53.000000000 -0800
@@ -4,9 +4,9 @@
 
 Internet Engineering Task Force                            M. D. Baushke
 Internet-Draft                                    Juniper Networks, Inc.
-Updates: 4250 (if approved)                             23 November 2020
+Updates: 4250 4253 4432 4462 (if approved)               1 December 2020
 Intended status: Standards Track                                        
-Expires: 27 May 2021
+Expires: 4 June 2021

  Key Exchange (KEX) Method Updates and Recommendations for Secure Shell
@@ -97,7 +97,11 @@
    considered secure is no longer considered secure.  The purpose of
    this RFC is to recommend that some published key exchanges be
    deprecated as well as recommending some that SHOULD and one that MUST
-   be adopted.  This document updates [RFC4250].
+   be adopted.  This document updates [RFC4250] [RFC4253] [RFC4432]
+   [RFC4462] by changing the requirement level ("MUST" moving to
+   "SHOULD" or "MAY" or "SHOULD NOT", and "MAY" moving to "MUST" or
+   "SHOULD" or "SHOULD NOT" or "MUST NOT") of various key-exchange
+   mechanisms.
 
    A key exchange has two components, a hashing algorithm and a public
    key algorithm.  The following subsections describe how to select each
@@ -121,11 +121,28 @@
    are weaknesses in the algorithm.  Therefore, it is desirable to move
    away from using it before attacks become more serious.
 
-   At present, the attacks against SHA-1 are collision attacks that rely
-   on human help rather than a pre-image attack.  So, it is still
-   possible to allow time backward compatibility use of SHA-1 during a
-   SSH key-exchange for a transition to stronger hashing.  However, any
-   such key exchanges should be listed last in the preference list.
+   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.
 
    Use of the SHA-2 family of hashes found in [RFC6234] rather than the
    SHA-1 hash is strongly advised.
@@ -305,7 +305,7 @@
    is the stronger of the two.  Group14 (a 2048-bit MODP group) is
    defined in [RFC3526].  It is reasonable to retain the diffie-hellman-
    group14-sha1 exchange for interoperability with legacy
-   implementations.  Therefore, diffie-hellman-group14-sha1 SHOULD be
+   implementations.  Therefore, diffie-hellman-group14-sha1 MAY be
    implemented and all other *-sha1 key exchanges SHOULD NOT be
    implemented.
 
@@ -519,7 +519,7 @@
      +--------------------------------------+-----------+------------+
      | diffie-hellman-group1-sha1           | RFC4253   | SHOULD NOT |
      +--------------------------------------+-----------+------------+
-     | diffie-hellman-group14-sha1          | RFC4253   | SHOULD     |
+     | diffie-hellman-group14-sha1          | RFC4253   | MAY        |
      +--------------------------------------+-----------+------------+
      | diffie-hellman-group14-sha256        | RFC8268   | MUST       |
      +--------------------------------------+-----------+------------+
@@ -750,6 +750,14 @@
               SHA-2", RFC 8732, DOI 10.17487/RFC8732, February 2020,
               <https://www.rfc-editor.org/info/rfc8732>.
 
+   [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>.
+
 Author's Address
 
    Mark D. Baushke