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

Ron Frederick <ronf@timeheart.net> Tue, 15 December 2020 17:00 UTC

Return-Path: <ronf@timeheart.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 667923A1260 for <curdle@ietfa.amsl.com>; Tue, 15 Dec 2020 09:00:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=timeheart.net
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 w1sx9F4aMnCf for <curdle@ietfa.amsl.com>; Tue, 15 Dec 2020 09:00:02 -0800 (PST)
Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B2DC3A125F for <curdle@ietf.org>; Tue, 15 Dec 2020 09:00:01 -0800 (PST)
Received: by mail-pf1-x434.google.com with SMTP id m6so5127192pfm.6 for <curdle@ietf.org>; Tue, 15 Dec 2020 09:00:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timeheart.net; s=mail; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JsEregWOe8oON47IvopvEb5qLDWMkILwq+DD1J31g14=; b=AZ/zNtDnxXRVJ8UAo70YqyOVFppd/VshBnlF5EY00emzpesZDBqIccJ5bwWg3bjacQ cNc1/zaUZ0rZtqXjK7oqBKDvOouyKzHrkFbr4zRPMYdZjs47lk1RzAoM57ASY7axGPkr EejyaFE2aSFlyaF84hwmZ1L79Sk8R3hKdvbZY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JsEregWOe8oON47IvopvEb5qLDWMkILwq+DD1J31g14=; b=ZjmIdHzYc9JaVXrqMVWreiccSgwyqUruKfzUbICxSs57a0wR+NvBOeZLUD8+Zl7Tyg OKhn+qDxPboGR2y3U5/wku9Wi+83zSiIKVlycgqBtX/3I1uT/2arAWSKM24dH3D/QQbx APtGXjK49wkcoiES1NJrtcDJBYX5rCU1X8n/SUt9xNkFMylxFHOTdXhnK9eT7IWVOL6g 9+36Tb7Gz6l9DsarJKEqHGFf3whnLrbcmIILNnM1QKUqmHxA8BV1YVTCnpTCSLnJ+ENQ pZySRqSblnd39IipKvi5C84Crz41F72Oxvms/OIvk+M8W+5PlfoDM/xE+rBr05Yx6fm4 OABw==
X-Gm-Message-State: AOAM531HIay0J1EiHSA6U0lULv5TeUCvOwwwmxqABDVpUd/+U1V5EgxM CmhdWKvLFABZjAnh7Q3OyBP0+Q==
X-Google-Smtp-Source: ABdhPJyB36sa2fMPPuRaYNx/t2Rzb876deX1nW2ClpilVBvNNhoAoZGv3SFe68+mSLtlWxV6jWZ7rA==
X-Received: by 2002:a63:c407:: with SMTP id h7mr30170960pgd.150.1608051600650; Tue, 15 Dec 2020 09:00:00 -0800 (PST)
Received: from d25qp0mlgq17.wifi.broadcom.net ([192.19.8.250]) by smtp.gmail.com with ESMTPSA id q16sm24889668pfg.139.2020.12.15.08.59.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Dec 2020 08:59:59 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Ron Frederick <ronf@timeheart.net>
In-Reply-To: <ED8F3B46-A5CC-4D14-A714-FD1C0AA67486@akamai.com>
Date: Tue, 15 Dec 2020 08:59:59 -0800
Cc: "Mark D. Baushke" <mdb=40juniper.net@dmarc.ietf.org>, Peter Gutmann <pgut001@cs.auckland.ac.nz>, Curdle Mailing List <curdle@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>, Daniel Migault <mglt.ietf@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <12959BD6-F3AB-418B-8CE0-C3BE43999435@timeheart.net>
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> <37691.1607621661@eng-mail01.juniper.net> <1607647129866.76532@cs.auckland.ac.nz> <2917.1607672034@eng-mail01.juniper.net> <012AE120-2516-44F6-B729-ED342A137535@timeheart.net> <ED8F3B46-A5CC-4D14-A714-FD1C0AA67486@akamai.com>
To: "Salz, Rich" <rsalz@akamai.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/lwJxGAvtZufzBa593t5RTmVu8xc>
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: Tue, 15 Dec 2020 17:00:04 -0000

On Dec 15, 2020, at 8:09 AM, Salz, Rich <rsalz@akamai.com> wrote:
>>   I’m not comfortable with algorithms going from REQUIRED to SHOULD NOT without some kind of transitional period. My suggestion would be to ease into this with SHOULD NOT for now. If you want to discuss BCP in this draft, perhaps that can be a separate section.
> 
> We've done it before, MD5, short RSA/DH keys, etc.
> 
> We shouldn't pretend that crypto-breaking advances haven't happened.
> 
> Admins can make trade-offs anyway.


Sorry, I meant not going to “MUST NOT” here. I’m good with “SHOULD NOT”, or perhaps even something stronger but qualified with the fact that ineroperability with older/slower devices should be considered.
 -- 
Ron Frederick
ronf@timeheart.net