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

"Mark D. Baushke" <mdb@juniper.net> Thu, 10 December 2020 17:34 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 7D7EF3A1134 for <curdle@ietfa.amsl.com>; Thu, 10 Dec 2020 09:34:47 -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=Mmponwo5; dkim=pass (1024-bit key) header.d=juniper.net header.b=StVap4FV
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 okHk1bt7YVIS for <curdle@ietfa.amsl.com>; Thu, 10 Dec 2020 09:34:45 -0800 (PST)
Received: from mx0a-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 883C63A1133 for <curdle@ietf.org>; Thu, 10 Dec 2020 09:34:45 -0800 (PST)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0BAHVS9m026897; Thu, 10 Dec 2020 09:34:42 -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=7OXCXI8Y2apOr/mimSVG4CSFdQuIDjDedoWcWfgH8HU=; b=Mmponwo5rpG/XQZb9x9YaquZTPO3erVOWEvA970Ip26y/GbS6fsHYJCcWHUflvLI9ISD zXI7Dzt70ilJi0/NSoXr18NGVdrV5BP1pE8ro6mC1iWyjvlHPRsMzCmeEoYg4DlwLQXC I9WFZ6CT1Be7wsbiWgFQH+YiRBdcI7ND7ch2xsLi782t/k5Ki5mQlUUuloT0xQn8Ua/+ z1Hb3FQ+t7tY5GG3xlAaj3KIGI5NvucuYqQtn8JCNbYiI18MWlIa0snjG5SSf3T+uxhV 5Vd8Yf6IWUkDABdKqSVeBxpLpyCVcjjUBhAWE225A2p3JLa7F9+vmhUKRxOgyWtwqnvm sw==
Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2176.outbound.protection.outlook.com [104.47.57.176]) by mx0a-00273201.pphosted.com with ESMTP id 35axtt2feq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Dec 2020 09:34:41 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FaYMcbaQObhGzuHBS2Zv8caF9UXD7tR3vB7xLNmXh8VPVAzHmrHYK+Ew2I0GP5ig/d2waBxKMmg/oU0O6M9Idd0CxoTwh4OcIHtEJ0matJKYGCyBOd1uyDVhyD5qIVfJmqFtWCeNlQuJG6jpYnT2uNNiejuo0hzVvkwfacyWjtwMj9fd7cMfeRaMyubSTM8sHHGJXQLOLGW4dIM+KB34UPSajrNvzDt27R90+HZ6KEtv83hf3DfAo8hUbMKsnrlXiculdNSpob6JHb/Dym4x5+W+VgpEEpEj7GZvIDiy+HAMwKAEhOyEg4Jz9pePbhzxTzYBDXKiOG4EJrL2MfbMMQ==
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=7OXCXI8Y2apOr/mimSVG4CSFdQuIDjDedoWcWfgH8HU=; b=ZVvzkQlDyVtO/EMMIZnurLXQo7mEIh5L9kVNuiqQMyoFwtjDg7WPZ45SPg4mL0VZ7LDHZ1/Q4Nrd1X8w6jh0ipKJBITpIvTNWbOgCFRc5trXUak8sea+kcA2vbXISv95cEm2DeXGkUZ488xYkpHqy0y4AjTEnlqBb8D+m97eqnxWsp8LDCyg9PLi5PTlZqk3BAnLq+qvChJWUOH6erZM2jAI9eoEQ73vwdgIQ0a+0NL7+NhlKADokX/wVwpxkPUerfEUJvLpDCVrPZ3uhPvv7BB65zFPiSUKgvdzypwa7+alpKZrM85r+y9r62qPR8VDuG0WKdOsiNsGmSQ4bXx9EQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.242.13) smtp.rcpttodomain=ietf.org 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=7OXCXI8Y2apOr/mimSVG4CSFdQuIDjDedoWcWfgH8HU=; b=StVap4FV1rkGDxu84IbJiMOtA2GNyFdjLdlHBRzn2RjZluGoemG94V2wbpOhB1u30ToSV1cGnKMRN6TDpjZkEeKV4oPod0zQH3TTIrwcqkGqR+st04RyOWGFXaPVPGzOOsUq0rgGuXfo8eeIstqTgxNPYoua85STzP7HJczzVZs=
Received: from MWHPR22CA0010.namprd22.prod.outlook.com (2603:10b6:300:ef::20) by BYAPR05MB4870.namprd05.prod.outlook.com (2603:10b6:a03:52::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.10; Thu, 10 Dec 2020 17:34:25 +0000
Received: from MW2NAM12FT023.eop-nam12.prod.protection.outlook.com (2603:10b6:300:ef:cafe::52) by MWHPR22CA0010.outlook.office365.com (2603:10b6:300:ef::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12 via Frontend Transport; Thu, 10 Dec 2020 17:34:24 +0000
X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.242.13) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=oreject header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.242.13 as permitted sender)
Received: from P-EXFEND-EQX-02.jnpr.net (66.129.242.13) by MW2NAM12FT023.mail.protection.outlook.com (10.13.180.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.3654.10 via Frontend Transport; Thu, 10 Dec 2020 17:34:24 +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; Thu, 10 Dec 2020 09:34:23 -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; Thu, 10 Dec 2020 09:34:22 -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; Thu, 10 Dec 2020 09:34:22 -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 0BAHYL59030990; Thu, 10 Dec 2020 09:34:21 -0800 (envelope-from mdb@juniper.net)
To: Benjamin Kaduk <kaduk@mit.edu>
CC: Daniel Migault <mglt.ietf@gmail.com>, Rich Salz <rsalz@akamai.com>, "Curdle Mailing List" <curdle@ietf.org>
In-Reply-To: <20201205194724.GB64351@kduck.mit.edu>
References: <2CCABC30-F757-4659-9FF3-5AADDD51EE30@akamai.com> <4b681efd49274f03c7e0521e127e031426632ad0.camel@redhat.com> <CADZyTkk--kCWqE7q0Xi5C40V92MuZBktDzQGt_vPSZPiBy7v9w@mail.gmail.com> <18479.1606885358@eng-mail01.juniper.net> <20201205194724.GB64351@kduck.mit.edu>
Comments: In-reply-to: Benjamin Kaduk <kaduk@mit.edu> message dated "Sat, 05 Dec 2020 11:47:24 -0800."
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: <37690.1607621661.1@eng-mail01.juniper.net>
Date: Thu, 10 Dec 2020 09:34:21 -0800
Message-ID: <37691.1607621661@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: 10229315-d01b-4faf-2f94-08d89d31d624
X-MS-TrafficTypeDiagnostic: BYAPR05MB4870:
X-Microsoft-Antispam-PRVS: <BYAPR05MB487003140502CF3CAD42AF64BFCB0@BYAPR05MB4870.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: omk1Gq1Y0qU6F1hc91t6mZTtHZrUM6P/JXyc7s+9/Kij5rgh22HkQ+sO+NJ7gX3WBMFSqVyEp1GRpsKNVFxXTeZlBnPIf0FKviywHTx9Q4Ah37+cAV3UPtXiJA4jKMJYJsxaH99Z2Nzu7HRT7iEg4Z6GWj3aeJhklgjycEwT9SF2oBKRPOW5zS/bDN0IwaaDlDYyI7xkPFY/B58spREPc9wA8P7U1c4Oeavo0N6s5dfY8Dh3Ysw8k6dIjBxB81Ic9m3KmY7vEErSKAoc5dsL+NRmhg4xS/BgmFQ3DwE+WZ1yTYTvsEYZhFBp8hHegwlSEFjZXDyTu4cd3jPUQ+tyzVHw+G/IGo9uWK8ZWuYui2dM3NgsXJSGVEUDo+/pSJ7iUTdE57Rl8UBhwqTIvWq43l/+aB0AiDoB2INHjDVM1beeFhUgtnV6HJvigfCTKjHt
X-Forefront-Antispam-Report: CIP:66.129.242.13; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:P-EXFEND-EQX-02.jnpr.net; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(4636009)(136003)(376002)(346002)(46966005)(82310400003)(86362001)(5660300002)(8936002)(54906003)(70206006)(426003)(2906002)(8676002)(966005)(336012)(47076004)(70586007)(7696005)(66574015)(186003)(6916009)(4326008)(508600001)(356005)(81166007)(83380400001)(26005); DIR:OUT; SFP:1102;
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Dec 2020 17:34:24.3559 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 10229315-d01b-4faf-2f94-08d89d31d624
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.242.13]; Helo=[P-EXFEND-EQX-02.jnpr.net]
X-MS-Exchange-CrossTenant-AuthSource: MW2NAM12FT023.eop-nam12.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4870
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-10_07:2020-12-09, 2020-12-10 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 bulkscore=0 impostorscore=0 clxscore=1015 lowpriorityscore=0 spamscore=0 malwarescore=0 mlxscore=0 adultscore=0 suspectscore=0 phishscore=0 priorityscore=1501 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012100109
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/89Y88nvKqksIx1xGj2A2oWrYAno>
Subject: Re: [Curdle] Which curves are MUST and SHOULD ?
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: Thu, 10 Dec 2020 17:34:48 -0000

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 <kaduk@mit.edu> writes:

> On Tue, Dec 01, 2020 at 09:02:38PM -0800, Mark D. Baushke wrote:
> > Hi Folks,
> >
> > Daniel Migault <mglt.ietf@gmail.com> writes:
> >
> > > I think the reason for SHOULD is to let time for implementations to
> > > 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?
> 
> I assume it refers to
> https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility
> am not sure whether we think that is a stable enough URL to mention in the
> RFC.

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

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

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