Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

Filippo Valsorda <> Tue, 17 August 2021 13:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B4C0C3A1EB8 for <>; Tue, 17 Aug 2021 06:28:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=B+/cghR9; dkim=pass (2048-bit key) header.b=bO/+OO79
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VQB0UjDth0_v for <>; Tue, 17 Aug 2021 06:28:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2033D3A1EA1 for <>; Tue, 17 Aug 2021 06:28:45 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id B7C1D5C0118 for <>; Tue, 17 Aug 2021 09:28:43 -0400 (EDT)
Received: from imap1 ([]) by compute2.internal (MEProxy); Tue, 17 Aug 2021 09:28:43 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=PUm5ctDyMPcjUT3il4TnNx7X1nLjgB+ qb42USjvrero=; b=B+/cghR9PDfXPy9geqlY1cxMXgKEJyZWKUvDfREAelrE446 W2SfcvDi1pSAtmanEN9Q6BFcbbTITEhsIVEl0/2jD3t57ATxuQrGVYWYNEEIvSPa khnDa1tT3jT9xo4zz+3RldYqpnKoMjnIaGTXyBiwlY6Mw6xeYhSH0JIvhHB2vhYP oxXMqhk9sUDvSwIatLnf7teFed3f2Bx80E0C6zrVwA/nEH6gdkbDXxIy2IG7ULJj beomUB/BhdGf1Ynp0jQILvtyG0HmukY4el5Js+kno9n52B/Pf8W3FlY/PMESiuQW ZtM1A0rSD3vD6Qx4HUhtI8BlJSm4X8qQ3obuZsA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=PUm5ct DyMPcjUT3il4TnNx7X1nLjgB+qb42USjvrero=; b=bO/+OO79QiNdFYrdPGRFkj PJsIKJsVVw0yuqyRuCmIjo9cC+2OMo3pUJ4IDRJ68ciWduZrhHDQAZVgTzeRBJAO e2BK2PNpvKKsPcspht31yjf4XAKd7tla0XUCveyKyhvl3p5x+LR7YLhPcngJQa5C Z6yUYjKvWnr5jHK9UqXFceDnmDStFtIaJrr5AOc0sV+HaltMGbADG9CQ1iZfTpUH 9uEjPt9sT0X+TjqOgka4ARajxH4QMPXcIPLDv3cmtPTSSDBQ4D5TdMH9wX94k+Av Fb79WssII5MsEswwg+6W2h0Ys1bfdyYcm5iaXVdqHK47mQu0IZxXf7MK3oj2RCuA ==
X-ME-Sender: <xms:i7kbYXtpRTadlpkB0NXZ_VCh3I_MJQfrprZuOCxdfGsfhQu5LDrnUA> <xme:i7kbYYeHrKf1QAEhMr0cU0yWo5UxEkGhDd29eii38IMzpDssNVqCtCIBRc_Lk_DRz rIjLUr6bOK5yuzVsw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrleefgdeihecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdfhihhlihhpphhoucggrghlshhorhgurgdfuceofhhilhhi phhpohesmhhlrdhfihhlihhpphhordhioheqnecuggftrfgrthhtvghrnhepledtieefue eghfffteffieejtdffkeettdettdeghedtleevhedtgfehtddtleevnecuffhomhgrihhn peihohhuthhusggvrdgtohhmpdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehfihhlihhpphhosehmlhdrfhhilhhiphhp ohdrihho
X-ME-Proxy: <xmx:i7kbYaxWDWD3vKhxpNZ5VBZ7-b56oswPGK4rOBs7Se6aug5uMFFnfA> <xmx:i7kbYWPb_zQ1engcZwDaKNKhwyUoOmHA7g-h9bvKY7jsd6hvKryfFQ> <xmx:i7kbYX8fk8UUYOcNUA0si-nCK0vljAEmTmcnBQw1SVK9v9v65j2ANw> <xmx:i7kbYaJojUte3k2vF_77I9_drBVtVBvlkYFH0YUtBjpYL-JLPLqo0g>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4CF0F1300089; Tue, 17 Aug 2021 09:28:43 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-1118-g75eff666e5-fm-20210816.002-g75eff666
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 17 Aug 2021 15:28:22 +0200
From: Filippo Valsorda <>
Content-Type: multipart/alternative; boundary="50eae86159454813b1dde8804aa9ac72"
Archived-At: <>
Subject: Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites 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: Tue, 17 Aug 2021 13:28:52 -0000

(I am listed as author to one of the drafts, but haven't contributed significantly since suggesting the deprecation on the list, so I am going to renounce authorship and express my support for the adoption instead.)

As a TLS implementer, I don't want the specs to tell me what is *technically possible to implement correctly*. I want the specs to recommend the safer, most straightforward options for general purpose use.

*DH reuse is less safe than ephemeral shares.* I don't think we need to debate this fact. There is a mile-high pile of CVEs that include the words "if DH shares are reused". I personally turned a 2^-32 chance of a carry bug into a full key recovery against ES-DH <>, others have pulled off more and cooler attacks. None of these fun, job-security-providing stunts work with ephemeral shares, so it's with a heavy heart that I say we should absolutely deprecate all DH share reuses. (This includes all static kex, and an explicit MUST NOT for reuse in ephemeral kex.)

*Checking the safety of an arbitrary FFDH group is relatively hard, and slow.* Implementers tend to skip hard, slow operations with no visible outcome. Besides, it's also a compatibility risk, because the only recourse on a failed check is to terminate the connection, which again encourages implementers to skip or relax the check. The most straightforward path to retaining FFDH in TLS 1.2 I see is requiring the use of a few, well known groups, that can be checked by memcmp. Still, I would rather support deprecating pre-TLS 1.3 FFDH entirely.

It's not like things in the wild suddenly stop working when the IETF deprecates a cipher suite (that's my job!), it just tells bystanders "this is not the best way to do things" and in the case of DH reuse "you'll be much safer if you generate fresh shares" and in the case of FFDH "if you want to do FFDH it will be safer and more reliable to use TLS 1.3".

I support adoption, and recommend merging all these deprecations into a single draft, which would be easier to refer to and communicate as an implementer.

2021-08-17 03:45 GMT+02:00 Joseph Salowey <>:
> Regardless of the Raccoon attack, the static DH and ECDH ciphersuites do not provide forward secrecy, which is a main reason cited for deprecating RSA in draft-aviram-tls-deprecate-obsolete-kex.  Do you object to just the citation of the Raccoon attack or do you also feel that we should keep these ciphersuites that do not provide forward secrecy around?
> Cheers,
> Joe
> On Fri, Aug 13, 2021 at 10:20 AM Blumenthal, Uri - 0553 - MITLL <> wrote:
>> I agree with Rene’s points.____
>> __ __
>> -- ____
>> Regards,____
>> Uri____
>> __ __
>> __ __
>> *From: *TLS <> on behalf of Rene Struik <>
>> *Date: *Friday, August 13, 2021 at 09:58
>> ____
>> Dear colleagues:____
>> __ __
>> I think this document should absolutely *not* be adopted, without providing far more technical justification. The quoted Raccoon attack is an easy to mitigate attack (which has nothing to do with finite field groups, just with poor design choices of postprocessing, where one uses variable-size integer representations for a key). There are also good reasons to have key exchanges where one of the parties has a static key, whether ecc-based or ff-based (e.g., sni, opaque), for which secure implementations are known. No detail is provided and that alone should be sufficient reason to not adopt.____
>> __ __
>> Rene____
>> __ __
>> On 2021-07-29 5:50 p.m., Joseph Salowey wrote:____
>>> This is a working group call for adoption for Deprecating FFDH(E) Ciphersuites in TLS (draft-bartle-tls-deprecate-ffdhe-00 <>). We had a presentation for this draft at the IETF 110 meeting and since it is a similar topic to the key exchange deprecation draft the chairs want to get a sense if the working group wants to adopt this draft (perhaps the drafts could be merged if both move forward).  Please review the draft and post your comments to the list by Friday, August 13, 2021.  ____
>>> __ __
>>> Thanks,____
>>> __ __
>>> The TLS chairs____
>>> ____
>>> ___________________________________________________
>>> TLS mailing list____
>>> TLS@ietf.org____
>> __ __
>> -- ____
>> email: | Skype: rstruik____
>> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867____
> _______________________________________________
> TLS mailing list