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

Filippo Valsorda <filippo@ml.filippo.io> Fri, 27 August 2021 13:35 UTC

Return-Path: <filippo@ml.filippo.io>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5831C3A17AD for <tls@ietfa.amsl.com>; Fri, 27 Aug 2021 06:35:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=filippo.io header.b=WbpQk9QQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Naa+jGvP
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSjwcUIRDfO0 for <tls@ietfa.amsl.com>; Fri, 27 Aug 2021 06:34:56 -0700 (PDT)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C0A3A17D0 for <tls@ietf.org>; Fri, 27 Aug 2021 06:34:56 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id B192D3200918; Fri, 27 Aug 2021 09:34:54 -0400 (EDT)
Received: from imap1 ([10.202.2.51]) by compute2.internal (MEProxy); Fri, 27 Aug 2021 09:34:54 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filippo.io; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=sbp2uHRO7I5NwfqiYrynypxGWsmX7Yp 0e9XWef7hYZA=; b=WbpQk9QQaoJffj9vMUCln1QZfbTogrz3GFGgeCPjSApIz/1 Ok+oA1zDttpmXDT1Lz82jinHgNDJT8YQt9ce8/ECtYiXG9mqwNmVXiLlnkyZVT3F eYvRp54NSSFA/ZV/EF21hULU/3NJHyieIQMXPuPlUByV7pF7D9vaqvOrzW38hzOs 0siJnbxvcWXgFllDsFtF0qpwwSwu///r0pLTXdY5HnS+uwdWaQhpXiQJanwFjwGD ctiD9ol0zclDEWStFuI0pwXCMqBIesBWz2G8zgL96uF/wN0x8rzDzYgNksg6lqPk ZHfk5l0lDMi1z2o2Btba6U/SjNuEJhe51oVhkSQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; 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=sbp2uH RO7I5NwfqiYrynypxGWsmX7Yp0e9XWef7hYZA=; b=Naa+jGvPx54k26cbLbzd8+ 3Alwy1CvPsMIcvr+hSl1BMTSNvTo0TXgBT2bkfBBoh6TXltEIVMDvpomj9VnmS6N G5Vd7bWpNW3GgCtLJr03/tW0CD1Rq1MbkWKQBBMw0ZyamJayj243tpnArURotQcD zxLA060PVQ1kNSj9Qys8EBwnEya1hUyalGT14cu6W9nnIdolIuM7EYLTyfx3mBvp 7vdzcJvM0AwPzkOq4qNa/gFPHXFupOicPrgmCwBJBkvjW9INxgQDyuDqPtQYKor2 j1GwFYlLR365wDiJbk7960eIcdObNQkU32CFhe5QzGSCMGPnS4xTnWMBqSmzotIQ ==
X-ME-Sender: <xms:_ekoYQ_soPyB5U3ruEMLUdSGJaiRqzL4HFDIdzFLfWONKqdOfGNJnw> <xme:_ekoYYsYZAyGUXeockhXiV1KjAIrDG7P6FS2h1v-JPhMyaSEAqnQXA9Yxpa3NIUhj 0Gz6OdsbTIqqYkElQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddruddufedgieeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfhfhilhhiphhpohcugggrlhhsohhruggrfdcuoehfihhl ihhpphhosehmlhdrfhhilhhiphhpohdrihhoqeenucggtffrrghtthgvrhhnpeeliefffe dtfeffteehvdeuleetffelleduiedvfedvheffhfelkeeggfelgeehjeenucffohhmrghi nhepihgrtghrrdhorhhgpdgslhgrtghkhhgrthdrtghomhdpihgvthhfrdhorhhgnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepfhhilhhiphhp ohesmhhlrdhfihhlihhpphhordhioh
X-ME-Proxy: <xmx:_ekoYWCtL1bCOU1DRDvv9ifuciEJOUy4715xLXq036Kmh2m7ll0G7Q> <xmx:_ekoYQd-dOF1MNcMd5p8rckUxsSOPJzOjAVz3V1gTF0LNPHc6P6hwg> <xmx:_ekoYVO3iyQJxgO6_XNXIPJRjfnij3pVBYEwnjmFT6wzCLfjDDIFMg> <xmx:_ukoYcaxABUyoToxSK0SiD2o7B5JqumTiznr2Um3haYDf2PjF3B6Vw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 51EDB1300087; Fri, 27 Aug 2021 09:34:53 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-1125-g685cec594c-fm-20210825.001-g685cec59
Mime-Version: 1.0
Message-Id: <bc91502a-471e-484e-ae5f-d843b703edd6@www.fastmail.com>
In-Reply-To: <5D5FB49A-7D18-4EC9-B572-BD860479CD5E@ll.mit.edu>
References: <CAOgPGoC4C0bWz0h0iyzGzMPEoDKAPv4euoOkmS+6Uuxncux4Zg@mail.gmail.com> <cc9c9d9f-d6b1-3b93-1231-a9a9c34a7fcd@gmail.com> <67533325-2983-47B7-871C-D90799D09532@ll.mit.edu> <CAOgPGoDAvnFic3VmEsge3i8C2FEfWp74ac_ievtfNo=MQB+C8g@mail.gmail.com> <C8E91D9B-2326-4AAF-9952-69481081E337@ll.mit.edu> <BD109A95-129A-4995-AFCA-FEF10DBD6440@icloud.com> <CAOgPGoBMhhsTupXuWF__zkLuy-4qQhha_Kp1_+ToZrNoaFUsgQ@mail.gmail.com> <13b9e674-9e0b-46aa-b5d6-49798c310d85@www.fastmail.com> <5D5FB49A-7D18-4EC9-B572-BD860479CD5E@ll.mit.edu>
Date: Fri, 27 Aug 2021 15:34:18 +0200
From: "Filippo Valsorda" <filippo@ml.filippo.io>
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=3086059ac19e4f559e2613ee1afe3f1c
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Z-yw4tvSzAvxWsAokvjng-o5s-I>
Subject: Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Aug 2021 13:35:04 -0000

2021-08-27 15:13 GMT+02:00 Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu>du>:
>> Thanks for all the discussion on this topic.  There are several modes that TLS 1.2 can operate with respect to DH.  Below is a proposal on cases to merge some of the cases covered by this draft into the obsolete keyex draft.  I'd like to see if there is some consensus to make this change before we adopt it into the working group. 
>>  
>>  1. static-static where both client and server have DH certificates with long term keys.  I think we have general consensus that this mode should be a must not.  To deprecate this mode I think we need to state that clients MUST NOT use certificates of type rsa_fixed_dh and dsa_fixed_dh and server MUST NOT request them.  Would the working group support merging this guidance into the obsolete keyex draft?  
>>  
>> Static-static is OK only when coupled with ephemeral (for forward secrecy), using the static part for implicit mutual authentication. Not good when used “alone”. Within the TLS context, OK to “MUST NOT”.
>>  
>>  1. ephemeral-static where the client uses an ephemeral key and the server uses a long term key.  This mode does not provide forward secrecy.  I'm not sure we have reached consensus on how far to deprecate this option.  Would the working group support MUST NOT use these ciphersuites unless forward secrecy does not matter for your use case and any implementation guidance provided to avoid weaknesses is followed?
>> Forward secrecy here is “asymmetric”: “server fails” -> “secrecy fails”. There are use cases…
>> I recommend “SHOULD NOT” here.
>  
> [FV] The implementation guidance to avoid weaknesses in any ephemeral-static exchange is "don't get anything wrong, anything at all, all the way down to your field arithmetic libraries". I don't think that's a workable recommendation, and I believe we should deprecate modes that are so unsafe to implement.
>  
> Static-ephemeral is _not_ “so unsafe to implement”, not any more than any other mode. It shouldn’t be encouraged, but shouldn’t be killed off either.

This is empirically disproved by a number of vulnerabilities that are exploitable (or near-misses for other reasons) only in ephemeral-static mode, such as CVE-2016-0701, CVE-2016-7055, CVE-2017-3732, CVE-2017-3736, CVE-2017-3738, CVE-2019-1551 just in the past 5 years in OpenSSL, and CVE-2017-8932 and CVE-2021-3114 in Go. https://eprint.iacr.org/2011/633 gives a good explanation of how these attacks work, and you might find https://i.blackhat.com/us-18/Wed-August-8/us-18-Valsorda-Squeezing-A-Key-Through-A-Carry-Bit-wp.pdf interesting as well.

Anyway, we keep going in circles around what deprecation is. In my opinion, an IETF deprecation doesn't "kill off" anything, it just says it's not encouraged, so it sounds like you support deprecation in those terms.

>  
>>  1. ephemeral-ephemeral  - I think these are already covered in the obsolete keyex draft. 
>> Absolutely no reason to deprecate or obsolete this mode.
>>  
>>  
>> On Sun, Aug 22, 2021 at 9:32 PM Carrick Bartle <cbartle891@icloud.com> wrote:
>>>> >   which is a main reason cited for deprecating RSA in draft-aviram-tls-deprecate-obsolete-kex.
>>>>  
>>>> Have the authors look at Post-Quantum KEMs?
>>>  
>>> I'm not sure why PQ KEMs are relevant here.
>>>  
>>>  
>>>> On Aug 17, 2021, at 10:41 AM, Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu> wrote:
>>>>  
>>>> >  Regardless of the Raccoon attack, the static DH and ECDH ciphersuites do not provide
>>>> >  forward secrecy,
>>>>  
>>>> Unless you use semi-static exchange, which in many cases makes sense.
>>>>  
>>>> >   which is a main reason cited for deprecating RSA in draft-aviram-tls-deprecate-obsolete-kex.
>>>>  
>>>> Have the authors look at Post-Quantum KEMs?
>>>>  
>>>> >  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?
>>>>  
>>>> I think these suites should stay around. 
>>>>  
>>>> While static-static indeed do not provide forward secrecy (and many of us – though not everybody! – carry for that), static-ephemeral DH and ECDH are perfectly fine from that point of view.
>>>>  
>>>>  
>>>>  
>>>> On Fri, Aug 13, 2021 at 10:20 AM Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu> wrote:
>>>>> I agree with Rene’s points.
>>>>>  
>>>>> -- 
>>>>> Regards,
>>>>> Uri
>>>>>  
>>>>>  
>>>>> *From: *TLS <tls-bounces@ietf.org> on behalf of Rene Struik <rstruik.ext@gmail.com>
>>>>> *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 <https://datatracker.ietf.org/doc/draft-bartle-tls-deprecate-ffdhe/>). 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
>>>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>>  
>>>>> 
>>>>> -- 
>>>>> email: rstruik.ext@gmail.com | Skype: rstruik
>>>>> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
>>>> _______________________________________________
>>>> TLS mailing list
>>>> TLS@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tls
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>  
>  
> 
> *Attachments:*
>  * smime.p7s