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

Benjamin Kaduk <kaduk@mit.edu> Sat, 05 December 2020 19:47 UTC

Return-Path: <kaduk@mit.edu>
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 1E3C23A0C37 for <curdle@ietfa.amsl.com>; Sat, 5 Dec 2020 11:47:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=unavailable autolearn_force=no
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 yhkg1kyRCkZ1 for <curdle@ietfa.amsl.com>; Sat, 5 Dec 2020 11:47:35 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 0F2C63A0C33 for <curdle@ietf.org>; Sat, 5 Dec 2020 11:47:34 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0B5JlP70003354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 5 Dec 2020 14:47:29 -0500
Date: Sat, 5 Dec 2020 11:47:24 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Mark D. Baushke" <mdb=40juniper.net@dmarc.ietf.org>
Cc: Daniel Migault <mglt.ietf@gmail.com>, Rich Salz <rsalz@akamai.com>, Curdle Mailing List <curdle@ietf.org>
Message-ID: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <18479.1606885358@eng-mail01.juniper.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/Mz10D6Bk9TzTAspaorR_2fBXZGM>
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: Sat, 05 Dec 2020 19:47:37 -0000

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 but
am not sure whether we think that is a stable enough URL to mention in the
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).

-Ben


>  Count         Key exchange
> 
>     45         diffie-hellman-group1-sha1
>     44         diffie-hellman-group14-sha1
>     38         diffie-hellman-group-exchange-sha1
>     35         diffie-hellman-group-exchange-sha256
>     30         ecdh-sha2-nistp256
>     25         ecdh-sha2-nistp521
>     25         ecdh-sha2-nistp384
>     14         curve25519-sha256@libssh.org
>     10         diffie-hellman-group14-sha256
>     10         curve25519-sha256
>      9         diffie-hellman-group16-sha512
>      7         diffie-hellman-group18-sha512
>      5         rsa2048-sha256
>      5         rsa1024-sha1
>      4         gss-gex-sha1-*
>      4         ext-info-c
>      4         diffie-hellman-group15-sha512
>      3         gss-group14-sha1-*
>      3         gss-group1-sha1-*
>      3         ecdh-sha2-1.3.132.0.10 (this is the ansip256k1 curve)
>      3         diffie-hellman-group17-sha512
>      3         diffie-hellman-group16-sha256
>      3         diffie-hellman-group15-sha256
>      3         curve448-sha512
>      2         diffie-hellman-group18-sha512@ssh.com
>      2         diffie-hellman-group16-sha512@ssh.com
>      2         diffie-hellman-group16-sha384@ssh.com
>      2         diffie-hellman-group15-sha384@ssh.com
>      2         diffie-hellman-group15-sha256@ssh.com
>      2         diffie-hellman-group14-sha256@ssh.com
>      1         kexguess2@matt.ucc.asn.au
>      1         gss-nistp521-sha512-*
>      1         gss-nistp384-sha256-*
>      1         gss-nistp256-sha256-*
>      1         gss-group18-sha512-*
>      1         gss-group17-sha512-*
>      1         gss-group16-sha512-*
>      1         gss-group15-sha512-*
>      1         gss-group14-sha256-*
>      1         gss-gex-sha256-*
>      1         gss-curve448-sha512-*
>      1         gss-curve25519-sha256-*
>      1         gss-13.3.132.0.10-sha256-*
>      1         ext-info-s
>      1         diffie-hellman-group14-sha224@ssh.com
>      1         diffie-hellman-group-exchange-sha512@ssh.com
>      1         diffie-hellman-group-exchange-sha384@ssh.com
>      1         diffie-hellman-group-exchange-sha224@ssh.com
>      0         ecmqv-sha2
> 
> Of course, this draft will NOT be listing the 'private' @domain.name
> exchanges.
> 
> 	Be safe, stay healthy,
> 	-- Mark
> 
> _______________________________________________
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle