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

Viktor Dukhovni <> Sun, 01 August 2021 19:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 02F3F3A0755 for <>; Sun, 1 Aug 2021 12:11:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 8_ZFAMb_QH3d for <>; Sun, 1 Aug 2021 12:11:04 -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 948713A0746 for <>; Sun, 1 Aug 2021 12:11:04 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 18E8AC272F; Sun, 1 Aug 2021 15:11:03 -0400 (EDT)
Date: Sun, 01 Aug 2021 15:11:03 -0400
From: Viktor Dukhovni <>
To: "<>" <>
Message-ID: <YQbxx3tLAr07Aus/>
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: Sun, 01 Aug 2021 19:11:09 -0000

On Sun, Aug 01, 2021 at 02:27:22PM +0300, Nimrod Aviram wrote:

> Looks like we have consensus for the following:

IIRC we're not looking for consensus on the substance of the draft at
this point, this just a WG adoption call.  So the issues below do not
need to be resolved at this time...  We just happen to be taking the
opportunity to discuss them...

> - Clients may choose to not support FFDHE, a la Chrome. I don't see
>   consensus for full deprecation of FFDHE, please correct me if I'm wrong.
> - Clients must not connect when the server uses a group of less than 2048 bits.
> - Clients may connect when the server uses a well-known, safe prime group
>   of at least 2048 bits (well-known might mean "from RFC 7919 plus the
>   built-in Postfix group", or other reasonable definitions).
> - Clients may connect when the server uses a custom safe prime group of at
>   least 2048 bits, if the client verifies that the prime is safe.
> The only point where we don't have consensus seems to be:
> - For clients who choose to support FFDHE, when the server uses a custom
>   group of at least 2048 bits, and the client isn't willing to check
>   safe-primality, what should the client do?

And so, with confirmation from Peter Gutmann below that any custom
groups we're likely to encounter are almost certainly safe (given a
sufficiently large prime), I see no need to do anything beyond:

    - Client should set a floor on the FFDHE group size that is appropriate
      for its application ecosystem.  Typically 2048, in ecosystems where
      smaller groups are sufficiently rare to non-existent.

    - A few specific, previously recommended, "standard" groups might now be
      explicitly refused.

    - Given that neither of the above can be negotiated in TLS 1.2, some
      clients and servers might choose to drop support for FFDHE either
      in TLS 1.2 or across the board.

I don't see a realistic scenario in which sufficiently large ad-hoc
server DH parameters are a problem.  Only some specific "standard"
groups (from outdated informational RFCs, ...) of suspect provenance
might reasonably be blacklisted.

On Sun, Aug 01, 2021 at 11:42:22AM +0000, Peter Gutmann wrote:
> Viktor Dukhovni <> writes:
> >OK, who goes around bothering to actually generate custom DH parameters, and
> >with what tools, but then does not use a "strong" (Sophie Germain) prime?
> That's better :-).  That was my thought too, every DH/DLP keygen I've seen
> generates either Sophie Germain or FIPS 186 primes/parameters, so on the off
> chance that your server feels like generating custom primes you'd need to go
> out of your way to generate unsuitable ones, i.e. you'd probably need to write
> custom code specifically for bad prime generation, and if you're going to do
> that then all bets are off anyway.