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

"Mark D. Baushke" <mdb@juniper.net> Tue, 01 December 2020 16:18 UTC

Return-Path: <mdb@juniper.net>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E783A0E13 for <curdle@ietfa.amsl.com>; Tue, 1 Dec 2020 08:18:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=nd61wlrH; dkim=pass (1024-bit key) header.d=juniper.net header.b=O2HndLU8
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhASKTBfFm4n for <curdle@ietfa.amsl.com>; Tue, 1 Dec 2020 08:18:55 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 458813A0E00 for <curdle@ietf.org>; Tue, 1 Dec 2020 08:18:55 -0800 (PST)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0B1G5bsH021981; Tue, 1 Dec 2020 08:18:54 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : date : message-id; s=PPS1017; bh=V/3wgl7Oj2d9k4JZVE+un1VOA4205fvszCqkJogtoQM=; b=nd61wlrHLFYDh6La1eOVUjOPrq7eZ6es0v/ko762sNIBtYXDHJTt+KYTb+BK6FZ8V3Rp uscb1wcVsZspnK1vsOpQMqXoeWzzz3qWFAAx7k+NkXAm6/ju9NyUPOlf6bJfyOlAt1g9 bqTPutkMFdCYqbqnZ6m2i/dQT/fuOacJhWWuf0VSKo4dipjFRpGX6KeGuLADP25L9Uyo kWp9v/YwPOKnYGBJ2v0fB30UzGySB/xctPRKQaXwPhLWGX85QstaqHwyU+bDQhyhN9wA Du8RSxDZ4MxNymZHX11h7ZB96+VT5hmAV/2ENwBRPAvp2/v9Sm5OLGfM17pYzfuywpTF gQ==
Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2047.outbound.protection.outlook.com [104.47.66.47]) by mx0a-00273201.pphosted.com with ESMTP id 355awahe42-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 01 Dec 2020 08:18:54 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ib9d1UBTGcBAPRftxQa0NZB/2Y37MKzyoglTaduX0BgV7XcgmhvnV7Sq//yU/wOnoT6KmruOekEtOisLDbTH+F/Kebe7j4fKSVl1qwPYoeslggCrA353EOGf1duem786YXJwllfp009bh2f9fpWC6czU4DhVZxNMHwHbDjDAiyDeZkTYrrRvkVV1ZCSItR72TaAGLmIL90V6J3GmmNnSTDrE1k+zq2uYxu2g0FIyCfy7vXJ2s8ygLxKVuJT0UR5ngYh8zRLfNQgIhHSfeOesoEq7+M0Ucz5uRttdnqsirls3KCrRsXM/LyZtN7npYDEIAcb+3+YWmWLtbBwMXnFJmg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=V/3wgl7Oj2d9k4JZVE+un1VOA4205fvszCqkJogtoQM=; b=bIdwTcG7v3eK9n4LAErcq9zLE9lEkUA40R3FerfWvTfvcZyKXtfjZvfrM8LA2OgfCWQKVQA40RtsDegNsSZrlgDTUaMRuMlXsf8AaMWnCgknfJti4SER5bAqKZRhY0EOV93IYAUmp9hAIS+/B5xhpCWmI53WSYyfMc7APd91hbP8Yc0jixyvBFQ3KFa0yOXKMwy0syB2jVcOj+RVyKfRWJdQhpO8TZYEVHJsbNp/YhDj1s9GbzbC5yn5tCLKK3r2CDcIBGrcx0L/JgO7Bvqs55scari1XAT0KuOBNnres8Xy/ZttSTGc5/YMPz8dhsOGhZIGBQZXM0j6U36R/n7E7w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.13) smtp.rcpttodomain=redhat.com smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=V/3wgl7Oj2d9k4JZVE+un1VOA4205fvszCqkJogtoQM=; b=O2HndLU8fQa7fsU3qGWB6F6nv+Hmi669sq8wPinfuPGugmUE8xiYXcK5a9fQVzNXb4LKFI1jul+7YecW0xfyVmspV/H9cBVN3o4/rKGEryLYku8PbF1DDo6YwiQlMwMyf4s713na3FqQQ39+vczXmOjrMSHquRfhGrBT8gKH9MQ=
Received: from CO1PR15CA0088.namprd15.prod.outlook.com (2603:10b6:101:20::32) by SN2PR05MB2461.namprd05.prod.outlook.com (2603:10b6:804:15::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.9; Tue, 1 Dec 2020 16:18:53 +0000
Received: from MW2NAM12FT044.eop-nam12.prod.protection.outlook.com (2603:10b6:101:20:cafe::87) by CO1PR15CA0088.outlook.office365.com (2603:10b6:101:20::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17 via Frontend Transport; Tue, 1 Dec 2020 16:18:52 +0000
X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.13) smtp.mailfrom=juniper.net; redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=fail action=oreject header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.13 as permitted sender)
Received: from P-EXFEND-EQX-02.jnpr.net (66.129.239.13) by MW2NAM12FT044.mail.protection.outlook.com (10.13.180.247) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.3611.11 via Frontend Transport; Tue, 1 Dec 2020 16:18:52 +0000
Received: from P-EXBEND-EQX-03.jnpr.net (10.104.8.56) by P-EXFEND-EQX-02.jnpr.net (10.104.8.55) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 1 Dec 2020 08:18:52 -0800
Received: from P-EXBEND-EQX-02.jnpr.net (10.104.8.53) by P-EXBEND-EQX-03.jnpr.net (10.104.8.56) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 1 Dec 2020 08:18:51 -0800
Received: from p-mailhub01.juniper.net (10.104.20.6) by P-EXBEND-EQX-02.jnpr.net (10.104.8.53) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 1 Dec 2020 08:18:51 -0800
Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [10.108.17.159]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 0B1GIou2012042; Tue, 1 Dec 2020 08:18:50 -0800 (envelope-from mdb@juniper.net)
To: Simo Sorce <simo@redhat.com>
CC: Tero Kivinen <kivinen@iki.fi>, <curdle@ietf.org>, Hubert Kario <hkario@redhat.com>
In-Reply-To: <2f6c95ef41c29eaf1e505aa65dab0a21ecb80c27.camel@redhat.com>
References: <25423.1596646626@eng-mail01.juniper.net> <SA0PR15MB37917F0E55D801609AF23EB0E34B0@SA0PR15MB3791.namprd15.prod.outlook.com> <20200807052623.GM92412@kduck.mit.edu> <71619.1606168457@eng-mail01.juniper.net> <7107b6ac-0e6c-419d-96ac-d0a53b65ee5b@redhat.com> <24511.57685.169815.673441@fireball.acr.fi> <afea8fb0-82e2-46e9-b2cc-4dca4038b630@redhat.com> <6050.1606417649@eng-mail01.juniper.net> <24512.5140.838958.415785@fireball.acr.fi> <2f6c95ef41c29eaf1e505aa65dab0a21ecb80c27.camel@redhat.com>
Comments: In-reply-to: Simo Sorce <simo@redhat.com> message dated "Tue, 01 Dec 2020 10:36:05 -0500."
From: "Mark D. Baushke" <mdb@juniper.net>
X-Phone: +1 408 745-2952 (Office)
X-Mailer: MH-E 8.6+git; nmh 1.6; GNU Emacs 26.3
X-Face: #8D_6URD2G%vC.hzU<dI&#Y9szHj$'mGtUq&d=rXy^L$-=G_-LmZ^5!Fszk:yXZp$k\nTF? 8Up0!v/%1Q[(d?ES0mQW8dRCXi18gK)luJu)loHk, }4{Vi`yX?p?crF5o:LL{6#eiO:(E:YMxLXULB k|'a*EjN.B&L+[J!PhJ*aX0n:5/
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <85120.1606839530.1@eng-mail01.juniper.net>
Date: Tue, 1 Dec 2020 08:18:50 -0800
Message-ID: <85121.1606839530@eng-mail01.juniper.net>
X-EXCLAIMER-MD-CONFIG: e3cb0ff2-54e7-4646-8a04-0dae4ac7b136
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: cfd9f898-690f-4dc1-bd00-08d89614cb52
X-MS-TrafficTypeDiagnostic: SN2PR05MB2461:
X-Microsoft-Antispam-PRVS: <SN2PR05MB246115471B8DED2C538D969DBFF40@SN2PR05MB2461.namprd05.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 2krpFObTbsPLG21Bn7FJMNfeNgQRWJ6uLWMOocpHl7hlvYS8wtAKNR46V3gLq7SjkYUoaZkFJ5SMGszrLHoz2Nkf6f5FiQqfH7PP8Dxlg31ktFgCUqOied+OR9x5kvGp0Tn09So4OuRW5j794CANgjNnJG3ICw9llES1GPlkpk/P98aILQmE2xGUE6mNTi8h7nIgxNJaaYvGX6vv0PhBs46j8hvp/wJ/rCtRw8zTDTZF9GBV7K1l5K2/EbESd0Eqp/S4bCJaXv1hfyFIoUKtq0PJynzR43UWuztU5MyDLP6g4vwJnjwsevbYSeWan7NKPX07bgMY1IF07bSIO3oyYE/kqMS3WJ51GghR2kd9AZRv9/M3S3XSSclrUWsEUqUM54j72Oe0vMfvwm2yXbKJubM/yTbl0Bbdkzy3D227mh08LnflMr/AKdC/VTv4wVvkeFNUuLdyfgaLz/F3ady0I0mzRAL1+mF/H4Cy9pykWbQeBldiKSv2lD2njWEHMVfF
X-Forefront-Antispam-Report: CIP:66.129.239.13; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:P-EXFEND-EQX-02.jnpr.net; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(4636009)(39850400004)(396003)(136003)(376002)(346002)(46966005)(8936002)(66574015)(8676002)(83380400001)(26005)(426003)(336012)(86362001)(2906002)(4001150100001)(7696005)(82740400003)(34020700004)(186003)(47076004)(70586007)(82310400003)(5660300002)(81166007)(70206006)(4326008)(6916009)(54906003)(478600001)(316002)(356005); DIR:OUT; SFP:1102;
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Dec 2020 16:18:52.6665 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: cfd9f898-690f-4dc1-bd00-08d89614cb52
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.13]; Helo=[P-EXFEND-EQX-02.jnpr.net]
X-MS-Exchange-CrossTenant-AuthSource: MW2NAM12FT044.eop-nam12.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2461
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-12-01_07:2020-11-30, 2020-12-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 adultscore=0 clxscore=1011 mlxscore=0 suspectscore=0 priorityscore=1501 bulkscore=0 malwarescore=0 phishscore=0 mlxlogscore=999 impostorscore=0 lowpriorityscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012010101
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/8eevsmc5zN6gDib8DA4BjbANJV4>
Subject: Re: [Curdle] Looking for comments on draft-ietf-curdle-ssh-kex-sha2
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Dec 2020 16:18:57 -0000

Hi Simo,

Simo Sorce wrote:

> 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.

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