Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 30 July 2021 18:56 UTC
Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B4A3A0ABA for <tls@ietfa.amsl.com>; Fri, 30 Jul 2021 11:56:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 OcO6I6lmzU0k for <tls@ietfa.amsl.com>; Fri, 30 Jul 2021 11:56:53 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ECF23A0B70 for <tls@ietf.org>; Fri, 30 Jul 2021 11:56:51 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 1FBDEC1883; Fri, 30 Jul 2021 14:56:50 -0400 (EDT)
Date: Fri, 30 Jul 2021 14:56:50 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <YQRLcoKm/+lVGwfv@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <CAOgPGoARpxr8-FzYJPRcup9XF-DRv875aAnuNZtoLPHM9-6j-w@mail.gmail.com> <4c0aafd3-fc8f-453a-a009-44ecc18dafd7@www.fastmail.com> <YQNLizvBb/xZyxkl@straasha.imrryr.org> <SY4PR01MB6251677071C9EDF4E5149616EEEC9@SY4PR01MB6251.ausprd01.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <SY4PR01MB6251677071C9EDF4E5149616EEEC9@SY4PR01MB6251.ausprd01.prod.outlook.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Uq6whHMDoCN1Zl2OMil3LwvGJQs>
Subject: Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Jul 2021 18:57:05 -0000
On Fri, Jul 30, 2021 at 05:14:08AM +0000, Peter Gutmann wrote: > >The only other alternative is to define brand new TLS 1.2 FFDHE cipher code > >points that use negotiated groups from the group list. But it is far from > >clear that this is worth doing given that we now have ECDHE, X25519 and X448. > > There's still an awful lot of SCADA gear that does FFDHE, and that's never > going to change from that. The current draft as it stands is fine, in fact it > seems kinda redundant since all it's saying is "don't do things that you > should never have been doing in the first place", but I assume someone needs > to explicitly say that. No need to go beyond that. Can you explain what you mean by "don't do things that you should never have been doing in the first place"? There are quite a few deployments that generate local strong (Sophie Germain prime) DH parameters. These would break if the draft sails through as-is, and there's no mechanism for the client to inform the legacy server that its would be choice of DH parameters is not acceptable. Was it wrong to generate server-side DH parameters? -- Viktor.
- [TLS] Adoption call for Deprecating Obsolete Key … Joseph Salowey
- Re: [TLS] Adoption call for Deprecating Obsolete … Salz, Rich
- Re: [TLS] Adoption call for Deprecating Obsolete … Martin Thomson
- Re: [TLS] Adoption call for Deprecating Obsolete … Viktor Dukhovni
- Re: [TLS] Adoption call for Deprecating Obsolete … Peter Gutmann
- Re: [TLS] Adoption call for Deprecating Obsolete … Viktor Dukhovni
- Re: [TLS] Adoption call for Deprecating Obsolete … Scott Fluhrer (sfluhrer)
- Re: [TLS] Adoption call for Deprecating Obsolete … Viktor Dukhovni
- Re: [TLS] Adoption call for Deprecating Obsolete … Peter Gutmann
- Re: [TLS] Adoption call for Deprecating Obsolete … Peter Gutmann
- Re: [TLS] Adoption call for Deprecating Obsolete … Peter Gutmann
- Re: [TLS] Adoption call for Deprecating Obsolete … Viktor Dukhovni
- Re: [TLS] Adoption call for Deprecating Obsolete … Nimrod Aviram
- Re: [TLS] Adoption call for Deprecating Obsolete … Peter Gutmann
- Re: [TLS] Adoption call for Deprecating Obsolete … Viktor Dukhovni
- Re: [TLS] Adoption call for Deprecating Obsolete … Peter Gutmann
- Re: [TLS] Adoption call for Deprecating Obsolete … Carrick Bartle
- Re: [TLS] Adoption call for Deprecating Obsolete … Ilari Liusvaara
- Re: [TLS] Adoption call for Deprecating Obsolete … Carrick Bartle
- Re: [TLS] Adoption call for Deprecating Obsolete … Loganaden Velvindron
- Re: [TLS] Adoption call for Deprecating Obsolete … David Schinazi
- Re: [TLS] Adoption call for Deprecating Obsolete … Joseph Salowey