Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS
Eric Rescorla <ekr@rtfm.com> Tue, 17 August 2021 17:57 UTC
Return-Path: <ekr@rtfm.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 DAE8E3A249E for <tls@ietfa.amsl.com>; Tue, 17 Aug 2021 10:57:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.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 r5YenHT3jTON for <tls@ietfa.amsl.com>; Tue, 17 Aug 2021 10:57:12 -0700 (PDT)
Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0633A249D for <tls@ietf.org>; Tue, 17 Aug 2021 10:57:12 -0700 (PDT)
Received: by mail-il1-x12b.google.com with SMTP id f15so19167847ilk.4 for <tls@ietf.org>; Tue, 17 Aug 2021 10:57:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/UNbGJDOdilXe1z6gPzK6fgyAQqNfOAXBaCVDsgTHZM=; b=gE/NRPh/CVPbZQ/5UHrxSExmgJ6iOMWTLNOhCgdWPPA6FnchTv3UHBxznaiY+k8WY8 8FWBUOYveQo/3EqeDOrUoqFosyQosqJizRWXewbKGJs42hWHocUmJjPrntyER/OcAMW5 8xVC18xLmJbYt3kHoIc2F5F25kqBj0ZmcI4o+n9/N92g05NUXta4a8JdkpvOfriGik2u w6KYbEWF80wtd2SiCv7wsGKvihvqx/g79onZuSWApGcpoi/vM2ZXJzrT1DsEbiV27BdK qFjkltLmJj+OPAAebnyu9DttdtMTV8CMPTmkTVyYpEE9/mQTqcqZkAKY8sSN4XH2z7Pu wsmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/UNbGJDOdilXe1z6gPzK6fgyAQqNfOAXBaCVDsgTHZM=; b=gMN8ZnHcpuAfZRAvPF10/SovvOUyNX566Ph4QcEnr7l3VIu3kQ1TfnnlWXKBAx2F/y sBp+r7mmZLCceZuCH46ywDb1tdf/bJgNASWYcczG/vrFDci0hSoGrIGct1xhryWzi2UG SQ6hm3qKV4WC5z4qtNOIVm8gYxzMn2a6CauyuJSzwplG2phbwanrCcDuiiMigDBh1Y7z qnncNKjMNLRtewMCzb7EglfBxuTwHwosV93TgYITmP779qaa8O0RrEDGYrnjrjbD1ERI 8RvAz5oyA3d9lPmvZqIyoVqlGiclOxqUpUkCXW6guPTQX7hUsDKrTaGxWcJIvYLrB/vH +bTA==
X-Gm-Message-State: AOAM532MSAipO2RDflFJUZjOq0etniAjrsrtePJcYGRY0OY4gXHdx/oE amPsNRBSYKEBrl9K4qX9RdSEEc7hEWOdf5ZZrT6IAw==
X-Google-Smtp-Source: ABdhPJzmPRxtRCKFhMVu7bIzPt1PHhTsFJCoJQQBv0aWdNKvGK8sWPBzkemQ2XDKIKGTnULId7O0I/gfU39nu46xfKs=
X-Received: by 2002:a05:6e02:5c8:: with SMTP id l8mr3264981ils.282.1629223029722; Tue, 17 Aug 2021 10:57:09 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <C8E91D9B-2326-4AAF-9952-69481081E337@ll.mit.edu>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 17 Aug 2021 10:56:33 -0700
Message-ID: <CABcZeBNtoGBLvuPzrhqC7YDsxW6x0kQDGwA8HH2d0Ews-yuyqg@mail.gmail.com>
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
Cc: Joseph Salowey <joe@salowey.net>, Rene Struik <rstruik.ext@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f268c505c9c50b63"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/q_XJPfkMjA6nU25JR_Gu49jqVCE>
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: Tue, 17 Aug 2021 17:57:18 -0000
On Tue, 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? > FWIW I don't think we should use post-quantum KEMs in pure "static" modes (a la traditional static RSA). -Ekr > > > 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] Adoption call for Deprecating FFDH(E) Ciphe… Joseph Salowey
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Salz, Rich
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Martin Thomson
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Carrick Bartle
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Carrick Bartle
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Martin Thomson
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Ilari Liusvaara
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Viktor Dukhovni
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Viktor Dukhovni
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Benjamin Kaduk
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Carrick Bartle
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Rene Struik
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Joseph Salowey
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Filippo Valsorda
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… David Benjamin
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Eric Rescorla
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Salz, Rich
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Loganaden Velvindron
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Benjamin Kaduk
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Dan Brown
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Peter Gutmann
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Carrick Bartle
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Joseph Salowey
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Filippo Valsorda
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Filippo Valsorda
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Rene Struik
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Filippo Valsorda
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Nimrod Aviram
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Rene Struik
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Rob Sayre
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Nimrod Aviram
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Carrick Bartle
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Carrick Bartle
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Rob Sayre
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Carrick Bartle
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Salz, Rich
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Joseph Salowey
- Re: [TLS] Adoption call for Deprecating FFDH(E) C… Salz, Rich