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

Ron Frederick <ronf@timeheart.net> Tue, 15 December 2020 03:44 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 A22EF3A03C9 for <curdle@ietfa.amsl.com>; Mon, 14 Dec 2020 19:44:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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=unavailable 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 Q2T2FB6hrsQe for <curdle@ietfa.amsl.com>; Mon, 14 Dec 2020 19:44:45 -0800 (PST)
Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 1E11F3A0332 for <curdle@ietf.org>; Mon, 14 Dec 2020 19:44:44 -0800 (PST)
Received: by mail-pl1-x62a.google.com with SMTP id j1so10236953pld.3 for <curdle@ietf.org>; Mon, 14 Dec 2020 19:44:44 -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=j/2j2xbA0mIBC10jZ2GmnAxAqCsCecAqd+BndY9vvlQ=; b=AbsIDqdnr0lX7lUmhX+4hObqhNumDtaptdg/GjHMtz3g/9In6U2y7EDF+wfVcfP4/9 w4EdAf2G+TxezxebpSwt88pH6yNoNyltsiOObq3qookQ+24rDGS7r8JF70D218w42UvL fEwxqtRHQUj39q5jvLod2L2gzKgVvlv+q/TIs=
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=j/2j2xbA0mIBC10jZ2GmnAxAqCsCecAqd+BndY9vvlQ=; b=tv+mSTtxANHF1dM9zEEcdYNBZG+Q78cXRAGbGDIupdAeO/57Us3Fj8NT5Y2ORKBsAF 45uPDiQfOaNpaDBAUTTr+R/UkqRZWLYip5hoqSPSjDYBGDKwM1zVzkQkLM4WDVq0fwtB P4ZwVCuFCUmLhQ2tsIvcPmpja1luRTLfoC+KHIGxVFSITPE4kAqZOTr9QOZF8XKvBDoq 2ex8IH0dxibbDlPNWNw5VXVBnnKt4cyHvi+5Dg+nE8h5qw1KcHLrMbutzX//9QsGsKMG AVVarRJnkBb6dKACmqJZ9gF3a8vcWcHY5+M8oV+ksn4bfgF0N4vCZHzU7dtq7Z5JDbT8 uC+A==
X-Gm-Message-State: AOAM532+3+ANYZ+/eNpujIoTvuka7HyruQ8Gx0HfTc6tqLfr7Ab4by7J r1vEeXH5TQti4DILYQgYXskLbg==
X-Google-Smtp-Source: ABdhPJxxkowwNGs+7EqBsZS0nLCDu85exCTHrjfrP1REGDn5kfDpfF8devfbe7Tb+jfPNRRLbQYbXg==
X-Received: by 2002:a17:90a:470b:: with SMTP id h11mr27692954pjg.186.1608003884213; Mon, 14 Dec 2020 19:44:44 -0800 (PST)
Received: from quad.timeheart.net ([74.93.13.193]) by smtp.gmail.com with ESMTPSA id a26sm22038278pgd.64.2020.12.14.19.44.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Dec 2020 19:44:43 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
From: Ron Frederick <ronf@timeheart.net>
In-Reply-To: <2917.1607672034@eng-mail01.juniper.net>
Date: Mon, 14 Dec 2020 19:44:40 -0800
Cc: Peter Gutmann <pgut001@cs.auckland.ac.nz>, Rich Salz <rsalz@akamai.com>, Curdle Mailing List <curdle@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>, Daniel Migault <mglt.ietf@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <012AE120-2516-44F6-B729-ED342A137535@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>
To: "Mark D. Baushke" <mdb=40juniper.net@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/AiieMdIf96mFul4FjkPzJGo8-Fg>
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 03:44:47 -0000

On Dec 10, 2020, at 11:33 PM, Mark D. Baushke <mdb=40juniper.net@dmarc.ietf.org> wrote:
> The guidance of this draft suggests that any *-sha1 SHOULD NOT be
> implemented and that the formerly REQUIRED and group14 SHA1 hashed
> parameters MAY be implemented only as a transitional step.
> 
> If we were changing this draft into to a BCP, then group1-sha1 would be
> certainly be a MUST NOT (due to the group1 of 1024-bits of MODP being so
> weak) and group14-sha1 would be a SHOULD NOT or a MUST NOT (the former
> to allow for legacy key exchanges and the latter based on a desire to
> eliminate SHA1 entirely).
> 
> If there is consensus, I would be happy to make ALL *-sha1* KeX
> algorithms get changed to MUST NOT as well as note that consistent with
> RFC 8270, no group exchange MODP group should be less than 2048 bits...
> that is instead of just being the recommended size it be the mandatory
> minimum size.

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.

If you do try to cover BCP in this draft, I think it’s worth thinking about how implementations should handle interoperability with older or slower devices which don’t support modern ciphers. Running SSH with a weaker cipher may still be preferable to connecting to such a device in the clear with something like “telnet”, and some devices may only support SSH with weaker ciphers and not even provide a plaintext option. Perhaps the recommendation should be to simply disable these weaker ciphers by default but leave them available to be enabled on a case-by-case basis for when there aren’t any better options and admins can choose if they’re willing to make this trade-off.
-- 
Ron Frederick
ronf@timeheart.net