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

Carrick Bartle <cbartle891@icloud.com> Mon, 23 August 2021 04:32 UTC

Return-Path: <cbartle891@icloud.com>
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 52E353A15CF for <tls@ietfa.amsl.com>; Sun, 22 Aug 2021 21:32:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.848
X-Spam-Level:
X-Spam-Status: No, score=-0.848 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com
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 ZpJLVKqFGLVJ for <tls@ietfa.amsl.com>; Sun, 22 Aug 2021 21:32:53 -0700 (PDT)
Received: from mr85p00im-hyfv06021301.me.com (mr85p00im-hyfv06021301.me.com [17.58.23.188]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 831363A15CC for <tls@ietf.org>; Sun, 22 Aug 2021 21:32:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1629693173; bh=lP84BxfTU74M9a4v1VRJ1ScbFnZo3LhouP5wF7OK4Mg=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; b=ysErqJVowi/1xmO3RsUVHIcwUZLHd9TtObj5h5LwSv9BpDX4MQodatD4JyEu77YoH dSqxdYT8sYqKrOw3Bo0HHJ0cvz5+adOy8oQ2VoZ3UJX3xzOBUEg17NdaHA9ugG7Pz4 sNONZasmWOP3U3QxtEknCEti6naJOPAmGtfnRuoLjbpuVCmQHk2H6ybiUBSIe5cQGM /Lnet0+wGV6U08qHZOoF3n7BFo8l1PFGXG5APAzepKhB6LxVNfoJYqOckDkFzT6roi AuH0oYIGcuSgu06r8gX13Xit3MhGtiwQatJuruFnodpsk0LPeGxNcAcpc4pIn+jLcD vIqGPKefYldRA==
Received: from smtpclient.apple (unknown [17.234.76.202]) by mr85p00im-hyfv06021301.me.com (Postfix) with ESMTPSA id ADC4340389; Mon, 23 Aug 2021 04:32:52 +0000 (UTC)
From: Carrick Bartle <cbartle891@icloud.com>
Message-Id: <BD109A95-129A-4995-AFCA-FEF10DBD6440@icloud.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DE1B205E-1FF3-4344-A83F-DF52C1EC69E1"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\))
Date: Sun, 22 Aug 2021 21:32:51 -0700
In-Reply-To: <C8E91D9B-2326-4AAF-9952-69481081E337@ll.mit.edu>
Cc: Joseph Salowey <joe@salowey.net>, Rene Struik <rstruik.ext@gmail.com>, "tls@ietf.org" <tls@ietf.org>
To: "Blumenthal, Uri - 0553 - MITLL" <uri@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>
X-Mailer: Apple Mail (2.3654.80.0.2.43)
X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.391,18.0.790,17.0.607.475.0000000_definitions?= =?UTF-8?Q?=3D2021-08-23=5F01:2021-08-20=5F02,2021-08-23=5F01,2020-04-07?= =?UTF-8?Q?=5F01_signatures=3D0?=
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 malwarescore=0 adultscore=0 mlxscore=0 spamscore=0 mlxlogscore=999 bulkscore=0 suspectscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2108230026
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/MLNkUXOr6jPvdKB1u5xjkbtrC1E>
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: Mon, 23 Aug 2021 04:32:59 -0000

> >   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 <mailto:uri@ll.mit.edu>> wrote:
>> I agree with Rene’s points.
>>  
>> -- 
>> Regards,
>> Uri
>>  
>>  
>> From: TLS <tls-bounces@ietf.org <mailto:tls-bounces@ietf.org>> on behalf of Rene Struik <rstruik.ext@gmail.com <mailto: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 <mailto:TLS@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls> 
>> 
>> -- 
>> email: rstruik.ext@gmail.com <mailto: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