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.