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

Simo Sorce <simo@redhat.com> Tue, 05 January 2021 14:18 UTC

Return-Path: <simo@redhat.com>
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 5895C3A0F41 for <curdle@ietfa.amsl.com>; Tue, 5 Jan 2021 06:18:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.369
X-Spam-Level:
X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-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 (1024-bit key) header.d=redhat.com
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 BcEbWLavRNvK for <curdle@ietfa.amsl.com>; Tue, 5 Jan 2021 06:17:58 -0800 (PST)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A434D3A0F47 for <curdle@ietf.org>; Tue, 5 Jan 2021 06:17:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1609856275; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pnhVK/xBNlqJXTBDLlf5lHIw/xexWPbdHf9R0MQY5FE=; b=CKq0lhrDkNGg01QXV1ftBlDmvyxlOsRWDMZMWuWG8Pe0G2NmPq+XSIexQmhdwHArW4iJqu sjEQKIWpxlBgjVpLIRCzgf+saMCPmEWtRwm+AkH74g9QRUCJRoS33vJyo9uSH4zwLv2Vmn 0zvgq31wzmKtM/Yzy2gOQeH4TySmYDM=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-493-n6EcNX0xNTaHtYuxSLN-3w-1; Tue, 05 Jan 2021 09:17:52 -0500
X-MC-Unique: n6EcNX0xNTaHtYuxSLN-3w-1
Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0226910054FF; Tue, 5 Jan 2021 14:17:51 +0000 (UTC)
Received: from ovpn-112-247.phx2.redhat.com (ovpn-112-247.phx2.redhat.com [10.3.112.247]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7712419714; Tue, 5 Jan 2021 14:17:50 +0000 (UTC)
Message-ID: <d80ac2564bc35d29c19c1cc2ac1a528bfbe84814.camel@redhat.com>
From: Simo Sorce <simo@redhat.com>
To: denis bider <denisbider.ietf@gmail.com>, "Mark D. Baushke" <mdb=40juniper.net@dmarc.ietf.org>
Cc: curdle <curdle@ietf.org>, Hubert Kario <hkario@redhat.com>
Date: Tue, 05 Jan 2021 09:17:49 -0500
In-Reply-To: <CADPMZDBwdv2d5ds_myvPpuMArz-yGBCh3NkvWNyQNpv_OYY2Vg@mail.gmail.com>
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> <12959BD6-F3AB-418B-8CE0-C3BE43999435@timeheart.net> <40887.1608233724@eng-mail03> <0f4dce32-b362-43d8-85e0-9608ca3427ab@redhat.com> <90135.1609791710@eng-mail03> <CADPMZDAb6Tcbiqi2UDrWOKzj5SQiSU-FOkqOjEELxiru--m8yw@mail.gmail.com> <CADPMZDBwdv2d5ds_myvPpuMArz-yGBCh3NkvWNyQNpv_OYY2Vg@mail.gmail.com>
Organization: Red Hat, Inc.
Mime-Version: 1.0
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23
Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=simo@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/EfS-RadPWKX0Yjqly0IW0Xb7s6k>
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, 05 Jan 2021 14:18:00 -0000

Hi Denis,
it does not serve any purpose to characterize users by depicting them
as ignorant, repeating trite tropes is demeaning and useless,
especially in a WG.

Users cover a large spectrum, just like developers cover a large
spectrum. If I wanted to make fun of developers I could say the exact
things you wrote of some of them.

The users I am in contact with (sysadmins/devops) are very
knowledgeable, and can make reasoned choices, as well as understand
perfectly well what SSH is and what the various algorithm acronyms
stand for.

In this case users understand pretty well what their installed base is,
whether they can move off of some legacy algorithm or not, and how
fast. In this area, my experience is that developers have generally not
enough data to make good choices, instead.

Peace & Empathy,
Simo.

On Tue, 2021-01-05 at 07:02 -0600, denis bider wrote:
> Furthermore, in my experience dealing with users, you can generally expect:
> 
> - Users think "SSH" is a misspelling of "SSL"
> 
> - They're given a security requirement to disable old TLS versions, and
> they look into SSH server settings to achieve that
> 
> - They think "SHA" is a signature algorithm
> 
> - They don't know what "RSA" is or what "DH" does
> 
> - They think they need to set up TLS certificates with SSH (which is
> possible, sure, but not needed or widely supported - our software still
> doesn't)
> 
> These are users.
> 
> Users might think "RFC" stands for "Request For Cake".
> 
> denis
> 
> 
> 
> On Tue, Jan 5, 2021 at 6:54 AM denis bider <denisbider.ietf@gmail.com>
> wrote:
> 
> > It's not both. It is developers that are aware of RFCs.
> > 
> > In my experience supporting users over 20 years, only a vanishing minority
> > of users are even aware of RFCs, and none read them.
> > 
> > denis
> > 
> > 
> > On Mon, Jan 4, 2021 at 2:21 PM Mark D. Baushke <mdb=
> > 40juniper.net@dmarc.ietf.org> wrote:
> > 
> > > Hubert Kario <hkario@redhat.com> writes:
> > > 
> > > > On Thursday, 17 December 2020 20:35:24 CET, Mark D. Baushke wrote:
> > > > > Ron Frederick <ronf@timeheart.net> writes:
> > > > > 
> > > > > > 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.
> > > > > 
> > > > > I am under the impression that the audience here is the maintainers of
> > > > > SSHv2 software rather than the administrators that manage the sites
> > > > > using it.
> > > > 
> > > > it's both
> > > 
> > > Fair enough.
> > > 
> > > Two kinds of stakeholders: a) "implementors" and b) "users" should mean
> > > more responses for the question.
> > > 
> > > Okay. In the original RFC4253 specification both
> > > 
> > >     diffie-hellman-group1-sha1
> > > and
> > >     diffie-hellman-group14-sha1
> > > 
> > > were REQUIRED key exchanges.
> > > 
> > > The group1 parameters in RFC4253 point to the 1024-bit MODP Second
> > > Oakley Group given in RFC2409 section 6.2 and RFC2412 section E.2.
> > > 
> > > There are two issues with diffie-hellman-group1-sha1: 1) recent
> > > estimages are that it has roughly 80 bits of security strength, and 2)
> > > it uses SHA1 for hashing which is considered weak.
> > > 
> > > If we choose "MUST NOT" for this key exchange, then we are going from
> > > "MUST" to "MUST NOT" which could be a hardship for low-end devices
> > > unable to run calculations to generate a shared secret using a larger
> > > MODP group if support is completely removed.
> > > 
> > > If we choose "SHOULD NOT", then it is hoped that most implementors would
> > > default to not configuring this option by default, but may provide it
> > > for enviornments that need it.
> > > 
> > > If we choose "MAY", then it is not certain if implementors or users will
> > > do much of anything different and this potentially insecure key exchange
> > > may continue to be used even when it may be a hazard to those that
> > > desire a more secure by default system.
> > > 
> > > Are you an SSH impelmentor or user or both?
> > > 
> > >   Implementor
> > >   User
> > >   Both
> > > 
> > > I would like to get a straw vote for the six *sha1* related key
> > > exchanges. I am proposing that the rsa1024-sha1-* kex be a MUST NOT and
> > > that all of the others be a SHOULD NOT.
> > > 
> > > 1. For diffie-hellman-group1-sha1 what is your vote?
> > > 
> > >   MUST          -- current for RFC4253
> > >   SHOULD
> > >   MAY
> > >   SHOULD NOT    -- proposed in the -13 draft
> > >   MUST NOT
> > > 
> > > 2. For diffie-hellman-group14-sha1 what is your vote?
> > > 
> > >   MUST          -- current for RFC4253
> > >   SHOULD
> > >   MAY           -- proposed in the -13 draft
> > >   SHOULD NOT
> > >   MUST NOT
> > > 
> > > 3. For diffie-hellman-group-exchange-sha1 what is your vote?
> > > 
> > >   MUST
> > >   SHOULD
> > >   MAY           -- current for RFC4419
> > >   SHOULD NOT    -- proposed in the -13 draft
> > >   MUST NOT
> > > 
> > > 4. For rsa1024-sha1 what is your vote?
> > > 
> > >   MUST
> > >   SHOULD
> > >   MAY           -- current for RFC4432
> > >   SHOULD NOT
> > >   MUST NOT      -- proposed in the -13 draft
> > > 
> > > 5. For gss-gex-sha1-* what is your vote?
> > > 
> > >   MUST
> > >   SHOULD        -- current for RFC4462
> > >   MAY
> > >   SHOULD NOT    -- proposed in the -13 draft
> > >   MUST NOT
> > > 
> > > 6. For gss-group1-sha1-* what is your vote?
> > > 
> > >   MUST
> > >   SHOULD        -- current for RFC4462
> > >   MAY
> > >   SHOULD NOT    -- proposed in the -13 draft
> > >   MUST NOT
> > > 
> > > You may direct your votes to the list or to the chairs and me.
> > > 
> > >         Be safe, stay healthy,
> > >         -- Mark
> > > 
> > > _______________________________________________
> > > Curdle mailing list
> > > Curdle@ietf.org
> > > https://www.ietf.org/mailman/listinfo/curdle
> > > 
> 
> _______________________________________________
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc