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

Carrick Bartle <> Mon, 02 August 2021 19:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E1B623A1922 for <>; Mon, 2 Aug 2021 12:45:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.845
X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W6ns4BeK8YzG for <>; Mon, 2 Aug 2021 12:44:58 -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 9905B3A191F for <>; Mon, 2 Aug 2021 12:44:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=1a1hai; t=1627933498; bh=Bgzp5nvVZ0s4l3KJ+qLTdUiS3ty8cjiutc4aG0Psl6Q=; h=From:Content-Type:Mime-Version:Subject:Date:To:Message-Id; b=l2GayddDdtAd7KAzWdZMyTSMNFBFl4LMW+uRrZv9JsFa/AUhBhg2fcbu0sqmyY7Z4 ZH4/iEU5hO+MgiK91ntzR0IGc8qrSXxIGI64WmmEnvpsMLEIhbtwyoRRYnCfwrrUBL OwLLxI6qMfSVLvJIt5ezp8yV9ojuLlWaIIRoLKYd83eC53KlpjO/TRLNtM+XrB0++w Kh9SbGvo0wrKhFFLQ2PQJ0yjw7kGjd4XeR1MeM2GEnAzJ1+ONX9UsQNjVWjM4sM21s cnuorkXIADmQt/k8cPhmUS1Jwtfh6zOxd/49n2GjzXQCiuMDdKRNacbeoW9cm2TGS2 ii6qyToYvuMbg==
Received: from (unknown []) by (Postfix) with ESMTPSA id D5B1ED20474 for <>; Mon, 2 Aug 2021 19:44:57 +0000 (UTC)
From: Carrick Bartle <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Mon, 02 Aug 2021 12:44:57 -0700
References: <> <> <YQNLizvBb/> <> <YQRLcoKm/> <> <YQRXGUZ/>
To: "<>" <>
In-Reply-To: <YQRXGUZ/>
Message-Id: <>
X-Mailer: Apple Mail (2.3654.
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.1.170-22c6f66c430a71ce266a39bfe25bc2903e8d5c8f:6.0.391,18.0.790,17.0.607.475.0000000 definitions=2021-08-02_07:2021-08-02_02,2021-08-02_07,2020-04-07_01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 suspectscore=0 adultscore=0 phishscore=0 mlxscore=0 spamscore=0 clxscore=1015 bulkscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2108020127
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: Mon, 02 Aug 2021 19:45:05 -0000

Is there benefit in stating that the server SHOULD choose a safe group, even if the client is unable to negotiate one?

Either way, I would support deprecating FFDHE completely.

> On Jul 30, 2021, at 12:46 PM, Viktor Dukhovni <> wrote:
> 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.
> -- 
>    Viktor.
> _______________________________________________
> TLS mailing list