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

Nimrod Aviram <nimrod.aviram@gmail.com> Fri, 27 August 2021 17:01 UTC

Return-Path: <nimrod.aviram@gmail.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 64F5C3A18D2 for <tls@ietfa.amsl.com>; Fri, 27 Aug 2021 10:01:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level:
X-Spam-Status: No, score=-1.097 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_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=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=gmail.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 evq3MKFLrc0F for <tls@ietfa.amsl.com>; Fri, 27 Aug 2021 10:01:08 -0700 (PDT)
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 67B803A18C4 for <tls@ietf.org>; Fri, 27 Aug 2021 10:01:08 -0700 (PDT)
Received: by mail-qk1-x72a.google.com with SMTP id y144so7888999qkb.6 for <tls@ietf.org>; Fri, 27 Aug 2021 10:01:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=zgrOaepS2J1dERObJ82Rk6L/wJtQjsvOCQTt1B9qUtU=; b=H9CuFIgNvghe+8IYC22IkLKgGjZo9Drq2jE1hTMm+dRM28ARhOZIB9Gt91GUHdgKD7 1CGdQFmFLh6gwf3UO06vso6JaZemR86berCaQpv5ds2MAqdg73e8+LdqoA24gTHu6CPK kekyc3fmYqu59dr53TQAnI+ZBzSlilcJa6KiIYKYE6sWj2MxkJ+gL74nD62vXZN6Tda9 OOcwHdkBR4fCGGE0or753LU0iP2y5d/eNlix2LMSTlFyqsSK1M3KM1I3tKo7P0sgaaS0 iQIB49OzMJZiYwVilx1SgTMD67UMxX92rn5v0UOFbBDNxsWWR8h1Gz00tYumGxjt5A6L lTTA==
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; bh=zgrOaepS2J1dERObJ82Rk6L/wJtQjsvOCQTt1B9qUtU=; b=Rinxx2Si0T7hVf543Zc0vf79uRmcmxuL19bYtM7l0lS/ZR08r6NqYh3zzazmmWZIcF bhDK2BbGnY9BqmriYXHK/niL/r5Ng7rtQI4EqMYfQFogF0HlUssrj4V2/vR/mPTURFY0 KiMzQLF6k8h/E0Ghy2wKUkaePE440KdVZcwf+aaCz4rfVDaxflHnQWJyg0+XEfdauidu PoKM+5yfeovgdX9HdyPdepqAR+tQ0lJyf0jBvEKVrQq0fiAEhLNXFXM9CPNl6uOPdSXO sANKS0qi68C4pr5YiWnnsoEBq0EpobsvcUZ6JRQnCzJdNKZa8Pm6lhUkNGKo7Sk+HjEo sz9g==
X-Gm-Message-State: AOAM530Vu7UueYG79gugleUrAHRb6u8fhsqZGR/Pzh3Hr7FnAzLx2xUC NYKnONdvihzojgQPTWnQJVNs5lcb+bXK+6YKX+liSXZyMvSIqQ==
X-Google-Smtp-Source: ABdhPJxMZNIQNZriXzmOWVjyljEFLjaNRYfMbqrZGWBZdK3s+W8HsEho0B51a/m/Ckkost3kg2GekZdpiG7z0/1re80=
X-Received: by 2002:a37:2cc4:: with SMTP id s187mr10088117qkh.407.1630083666441; Fri, 27 Aug 2021 10:01:06 -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> <BD109A95-129A-4995-AFCA-FEF10DBD6440@icloud.com> <CAOgPGoBMhhsTupXuWF__zkLuy-4qQhha_Kp1_+ToZrNoaFUsgQ@mail.gmail.com> <13b9e674-9e0b-46aa-b5d6-49798c310d85@www.fastmail.com>
In-Reply-To: <13b9e674-9e0b-46aa-b5d6-49798c310d85@www.fastmail.com>
From: Nimrod Aviram <nimrod.aviram@gmail.com>
Date: Fri, 27 Aug 2021 20:00:54 +0300
Message-ID: <CABiKAoT3rwhXHAm3YeuuMzQMp5hH-N2sL6WPadE5i+bX1hrTjw@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e479eb05ca8d6d3c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/JLVYf3v0sdgh4O4YUVSp7y0fMOM>
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 17:01:15 -0000

> The implementation guidance to avoid weaknesses in any ephemeral-static
exchange is "don't get anything wrong, anything at all
Agreed that it's not workable. I'm not sure there is existing and suitable
implementation guidance.
To avoid the Raccoon attack, one would have to implement the KDF such that
it is constant time, even for variable-length secrets. This is possible, at
least in principle, but I'm not aware of any implementation that does it or
plans to do it, and neither of any document that describes the complex
strategy for achieving this.


On Fri, 27 Aug 2021 at 12:26, Filippo Valsorda <filippo@ml.filippo.io>
wrote:

> 2021-08-27 05:08 GMT+02:00 Joseph Salowey <joe@salowey.net>et>:
>
> 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?
>
> 2. 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?
>
>
> 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.
>
> 3. ephemeral-ephemeral  - I think these are already covered in the
> obsolete keyex draft.
>
> Thanks,
>
> Joe
>
> 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
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>