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

Viktor Dukhovni <> Fri, 30 July 2021 19:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E25273A0D78 for <>; Fri, 30 Jul 2021 12:46:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.899
X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_DOTEDU=1] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cJE1sS7ZXVE7 for <>; Fri, 30 Jul 2021 12:46:47 -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 AD0B13A0D86 for <>; Fri, 30 Jul 2021 12:46:34 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 74F95C17AA; Fri, 30 Jul 2021 15:46:33 -0400 (EDT)
Date: Fri, 30 Jul 2021 15:46:33 -0400
From: Viktor Dukhovni <>
Message-ID: <YQRXGUZ/>
References: <> <> <YQNLizvBb/> <> <YQRLcoKm/> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
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 19:47:00 -0000

On Fri, Jul 30, 2021 at 07:30:31PM +0000, Scott Fluhrer (sfluhrer) wrote:

> > Was it wrong to generate server-side DH parameters?
> The problem is that it is hard for the client to distinguish between a
> well designed server vs a server that isn't as well written, and
> selects the DH group in a naïve way.

I am well aware that verifying the safety of the server's choice is
computationally taxing.

> Now, as I mentioned in the WG meeting, it would be possible to detect
> if the server proposes a safe prime (it's not especially cheap, being
> several times as expensive as the rest of the DH operations, but it's
> possible), and that would prevent most of the problems that can happen

I don't think it is realistic for the client to go to that much trouble.
The server's choice of parameters is signed by the server's public key.
What is the threat model here?  Is the client trying to avoid servers
that shoot themselves in the foot by verifiably choosing bad parameters?

The server could also have a strong DH group, but a terrible RNG with a
well known RSA private key:

If the server is not one of these or similar, and attests to its choice
of DH parameters, and they happen to be less than ideal, so be it.
Server operators should be encouraged to choose strong parameters, but I
see little reason for clients to second-guess that choice.

If the DH parameter size is below a reasonable threshold (Logjam), a
client might balk, but otherwise I am not sure what practical problem
we're actually solving.

> Of course, this works only if the legacy servers you are talking about
> actually do use safe primes...

All the ones I know of use "openssl dhparam", which defaults to Sophie
Germain strong primes with generator 2.

I strongly doubt there's a non-negligible server population with weak
locally generated groups.  The only likely source of weak groups is
servers that used one the older now deemed weak groups published in
deprecated RFCs.

So it might suffice to refuse specific known weak "standard" groups,
which would have a much lower impact than requiring particular standard
groups with no mechanism to negotiate these.