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
>