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

denis bider <denisbider.ietf@gmail.com> Tue, 05 January 2021 19:45 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 04F6A3A0FED for <curdle@ietfa.amsl.com>; Tue, 5 Jan 2021 11:45:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=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 rFcbPFdzOnyx for <curdle@ietfa.amsl.com>; Tue, 5 Jan 2021 11:45:08 -0800 (PST)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 AF4DA3A0FCD for <curdle@ietf.org>; Tue, 5 Jan 2021 11:45:08 -0800 (PST)
Received: by mail-ot1-x334.google.com with SMTP id w3so786266otp.13 for <curdle@ietf.org>; Tue, 05 Jan 2021 11:45:08 -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=RF+RTC3Kdq7L7LK41KLk/0q2rypDSsNUMrzzLijKhbg=; b=pWhqS9V/45PxANUjrCbZg0tfiWZ6AswT2nNUBlonnGcW/Urrs8XIkdpWnh+/Ef9Tjb MKIcovZgJQ03RVCd60u05HdlJH6qRnXz4NiZzZqj+ovuHUHZo+oX4txqhAqw9Ntixt+G XvMIlKciFpHgkVNJIt84qS7xOJ+dGhu/nXJ0bhEQXzyI2LDSiAE4rjY0N7Q/2Qt8hOye buLHbL3ihRj5dREJQAIDA2k63WOj2n4kQVNpsDRg7z979BVP3/CaR2X6NhS21W2EkyW/ z6an496xy0KEQdVl82vunnKdByI0f32ICI4iQ7/p1MErQb4ebRVVfExfg3PBkEUtQz5f SAHA==
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=RF+RTC3Kdq7L7LK41KLk/0q2rypDSsNUMrzzLijKhbg=; b=Ji6ChtDb14zr+Mh9fvPCwbb7SGvbLsJeIRsKRv6h4KJj7XUQqdiO8nzwf0ECqUufgQ v3+JqzlKjPlrXfRNhu+HYEaW1nng1pz7Ldu7UUb0TcWhGEKQbAvVShQ/crwT5zsJ29Pf 9gOV+tWaonHJ/F7alCnTdkLgHEUARa3YU7CifFxm9tU4OZl7RE3Qpz6QKYxBKuQy92U0 4lvdccn5MYKvb4yI2lR5iECtmJ8fYibvFUuQ7+85WKgZTmOjmJ7TUk5k5FGBuBsMpK8y oAZe/KCoAOg5Ka6TvIbGa7Zj6wXQiXyY7X2ZsT0EYNhQVxwAP478YjDliBYLqfyecE3i V6iQ==
X-Gm-Message-State: AOAM5312X1Kl3GaS7y6mV6Ug16NdAWjwVsHeLEpIBpP8yPmYfywlXSPd 6XYq5lOvrB6yVKfqiP21rRpSpWBUoUqJoW3JvRkCZjYnUHb0ng==
X-Google-Smtp-Source: ABdhPJwCzxT6556s+iaaqWm6s8e0XlEIwI7MeTlVFq/WiWaQg8d77y5KIfKOz3EfEg0lUK82k37fIlhsEa5I+HmjMF8=
X-Received: by 2002:a05:6830:1d66:: with SMTP id l6mr809625oti.23.1609875908083; Tue, 05 Jan 2021 11:45:08 -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> <CADPMZDBwdv2d5ds_myvPpuMArz-yGBCh3NkvWNyQNpv_OYY2Vg@mail.gmail.com> <d80ac2564bc35d29c19c1cc2ac1a528bfbe84814.camel@redhat.com>
In-Reply-To: <d80ac2564bc35d29c19c1cc2ac1a528bfbe84814.camel@redhat.com>
From: denis bider <denisbider.ietf@gmail.com>
Date: Tue, 5 Jan 2021 13:44:57 -0600
Message-ID: <CADPMZDD9n6bPsT4Qdzxu1OV+MpMZSG3Apuvoqb7YTYSqm1CPOA@mail.gmail.com>
To: Simo Sorce <simo@redhat.com>
Cc: "Mark D. Baushke" <mdb=40juniper.net@dmarc.ietf.org>, curdle <curdle@ietf.org>, Hubert Kario <hkario@redhat.com>
Content-Type: multipart/alternative; boundary="000000000000a244b005b82c71bd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/iRDQ8PSm642NCP9C1WOBtZP2pwU>
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 19:45:11 -0000

Hubert:

> by "user" I mean "administrator"

Yes, and so did I.

> and system administrators do read RFC

That's technically correct if you meant 0.1% of administrators read RFCs.

Simo:

> The users I am in contact with (sysadmins/devops)
> are very knowledgeable

These are the 0.1%. The 99.9% do not have a way to access you to begin with.

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

You think I'm being hateful and antagonistic, so therefore you become
hateful and antagonistic.

I'm not being hateful and antagonistic. That's all you.

I'm telling you how things are.

denis


On Tue, Jan 5, 2021 at 8:17 AM Simo Sorce <simo@redhat.com> wrote:

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