Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

Viktor Dukhovni <> Fri, 30 July 2021 00:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E4F2B3A129A for <>; Thu, 29 Jul 2021 17:45:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yAe8cCK-Uxln for <>; Thu, 29 Jul 2021 17:45:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A1D2E3A12AE for <>; Thu, 29 Jul 2021 17:45:00 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 83824C1012; Thu, 29 Jul 2021 20:44:59 -0400 (EDT)
Date: Thu, 29 Jul 2021 20:44:59 -0400
From: Viktor Dukhovni <>
Message-ID: <YQNLizvBb/>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Jul 2021 00:45:06 -0000

On Fri, Jul 30, 2021 at 10:34:55AM +1000, Martin Thomson wrote:

> On Fri, Jul 30, 2021, at 07:50, Joseph Salowey wrote:
> > This is a working group call for adoption of Deprecating Obsolete Key 
> > Exchange Methods in TLS  (draft-aviram-tls-deprecate-obsolete-kex-00 
> > <>).  There was support for adopting this draft at the IETF 111 meeting.  Please review the draft and post your comments to the list by Friday, August 13, 2021.  
> Yep, let's do it.  There were comments suggesting that this wasn't
> going to work for some deployments yet.  That's OK, that's how this
> works: we decide to deprecate, discuss and publish a document, then
> people get to work out how they change their deployments.  If we don't
> take that first step, then in many ways things don't get better.
> Adopting this is that first step and a good idea.

I support adoption of the draft and deprecation of RSA key exchange.

For FFDHE, I'd much rather see outright deprecation a la Chrome, than a
silent restriction by client (with no mechanism to negotiate otherwise0
to parameters that the server may not be prepared to support.

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 is far less risk of interoperability failure if the client or
drops support for FFDHE, rather than silently chooses to reject
previously working parameters.