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

denis bider <denisbider.ietf@gmail.com> Tue, 05 January 2021 13:02 UTC

Return-Path: <denisbider.ietf@gmail.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 43A793A0C30 for <curdle@ietfa.amsl.com>; Tue, 5 Jan 2021 05:02:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 AsYTaLo0dwG8 for <curdle@ietfa.amsl.com>; Tue, 5 Jan 2021 05:02:28 -0800 (PST)
Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 4AD333A0C18 for <curdle@ietf.org>; Tue, 5 Jan 2021 05:02:28 -0800 (PST)
Received: by mail-ot1-x333.google.com with SMTP id i6so29196866otr.2 for <curdle@ietf.org>; Tue, 05 Jan 2021 05:02:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KU5UF/dPIJoq+zrVgI2t2me6EKxOFCw3JQ+oVyAGJBY=; b=JlykA+XEnq1DmAmD2scCP/tTKyPZyVHwdsFxRfTJW5hQDuPffGIPkYsqGcnnw5VxS0 6M/cVcEZqsJyob9r4OGgrxlI9hT1JmSzd7mREepzMFPCwZEH/8KZ0frPF0Rd4a59S8RY FKfyqCQ4x8jbilZs3kk49heGTDzWjM1IVxWyBbmZJQ3l1qnOEAbsyiH8otCkNpTSmvCw DN7JPu2VEXMxwNdPTLk+2yotq/SF81UbD1zJt5kl+fBMgYIin6pSq94VY+3SQH1QlMFj dEq/Vo8RBD2V1OUtqo4uqZiBWc+gVM/6yKSEChK200nkCq1tI0gWIJjOBXOWrm2eeK96 Rtzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KU5UF/dPIJoq+zrVgI2t2me6EKxOFCw3JQ+oVyAGJBY=; b=j7KyHZMRklwLNnkjjyntEZWRzKxTe/Ac++mceiVDwreHyg8ylo+JuC9Gk7+PzVtlND 9IIYQuYdxwtp73q6mONSeXiUZ0MFsq1oNDF6gRe8t2ZoglCiRPfrNcYmBTe+ES++v9OG Wc8PmoAUdmMdR90b/xxh7BxVCIzlJS4xv1QkRVE8/DZ+nWKxyDvy5YzTr0VjpOwLptR1 fPVFS5F1BNPhZjA2dBqtTmMameE5OkU524WnqS2PTvzZf6vOqjHNzjKuoD/gK6IQob5G 02WdUuQa1lAGLd5b6aSksT9/djXzYLtE7jTFr2pLnnlQf9wtkwhqX33X8yzOb8DB2Je0 vBjQ==
X-Gm-Message-State: AOAM532Qk/2h+FGjvh1WcGYkIR46zbxrPB30Egl5NUCZxlF1wOoW9ZeP cJ4pSR3KQHdbMrgNYgApaAh9qlsMdSnoBVbBJ0dVhI9o
X-Google-Smtp-Source: ABdhPJwAnKe8uk0L1Jw9HuEJE12SKY14BySyyjST5hLxfJH2wz21qSk7bmn5Vff5OXcIQioBmZ4o2wKs4tXMdZDBshE=
X-Received: by 2002:a05:6830:1d66:: with SMTP id l6mr55440355oti.23.1609851747573; Tue, 05 Jan 2021 05:02:27 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <CADPMZDAb6Tcbiqi2UDrWOKzj5SQiSU-FOkqOjEELxiru--m8yw@mail.gmail.com>
From: denis bider <denisbider.ietf@gmail.com>
Date: Tue, 05 Jan 2021 07:02:16 -0600
Message-ID: <CADPMZDBwdv2d5ds_myvPpuMArz-yGBCh3NkvWNyQNpv_OYY2Vg@mail.gmail.com>
To: "Mark D. Baushke" <mdb=40juniper.net@dmarc.ietf.org>
Cc: Hubert Kario <hkario@redhat.com>, curdle <curdle@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008e254c05b826d1fa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/aQ49-HcqWSbNsTjPo8MiXm9HdXA>
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 13:02:30 -0000

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