Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

Nimrod Aviram <> Sun, 01 August 2021 11:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6A9443A3779 for <>; Sun, 1 Aug 2021 04:27:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jDJt2Unzy-gK for <>; Sun, 1 Aug 2021 04:27:36 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 57F0A3A3776 for <>; Sun, 1 Aug 2021 04:27:36 -0700 (PDT)
Received: by with SMTP id t66so14087320qkb.0 for <>; Sun, 01 Aug 2021 04:27:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=uT7Zx7wqqHxj1tZuCgyUjagBZLSDXGF34Sq+n+XFOJw=; b=UinzGlgaw1/ikRVQHd4B+l204aS2jYsdE7suqR4zsi0mpSTdgYUjXnf8oNGDPbdCDP 3KOL9u9AAn0nTxc2zcJtrO5UILuMtjVWsXSRleivFXIAZQpVjIJZribszXnUELwOau5y qMYZPiiI0XXdPKL7U8Bd5ui2JDqkOnJK0FHBbSjxnITcdFLyNSs4Sv079MWN14MPYvUt pD3L9bCOflEkGR1xansJcQoXm4rgNsVIPW5q/5f6M1JigiU0aUHdmCWZf/+nK2Bm6g/E uAaY/q9rSeHRWpEokDWsNGu8ps755ZsfC8/bPJct+T0KuDSZ34EfHjmPCE809PqLHnMU BFaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=uT7Zx7wqqHxj1tZuCgyUjagBZLSDXGF34Sq+n+XFOJw=; b=kbVe4cUmizczrOEkgmUXHrdeDEt+2zUeS3Y/bVb2J4CPfzaYtEYioHZ9BjRMF/+EgV nYCcSHsRll6+ylPEzL1y6sCSjy7TNHZgNEPK54QU1o6gGUzjCIeXoB6VOYDJtU2MYe4S X5WyiktrDD7Z3p2zKu1QTpMYXRgd7Arl3XF3fyWl9E6zEYFKrxx5VGwtod/A8tcQrch1 aE3NGuUj/xr4GlCKHlstA0xPhgLB8ui8pwDN3tgJeV/u6VIjmG/gEeHDeAPbxPnVbNYl 7o7XQQANSaSS7Ve5aKFjj6xhh/UBCgCWxxRvoZ0anXLWZQRbd5YaZljSaSsYRMQhHCLG wpVw==
X-Gm-Message-State: AOAM531ysv8hykptMJa3KLH/WLZdYnZiOKHlGUu54OSvmkSzSGYuwH+S n/zHB3JGxXGXI5mVgFCd6aknqv5J/eKUUE0KNw0372Et0wuXtg==
X-Google-Smtp-Source: ABdhPJx0Lt5FulSrWn04VTuMFVqS7yFDhaqV+89rclI3Ic7XvLb24JD1Nbn2S2vUQCRpAmI9DqkRm0wJYOX8vV9Q/nA=
X-Received: by 2002:a37:a78d:: with SMTP id q135mr10749178qke.192.1627817253615; Sun, 01 Aug 2021 04:27:33 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <YQNLizvBb/> <> <YQRLcoKm/> <> <YQRXGUZ/> <> <>
In-Reply-To: <>
From: Nimrod Aviram <>
Date: Sun, 01 Aug 2021 14:27:22 +0300
Message-ID: <>
To: "<>" <>
Content-Type: multipart/alternative; boundary="000000000000293b7105c87dbd2d"
Archived-At: <>
Subject: Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 01 Aug 2021 11:27:42 -0000

Looks like we have consensus for the following:
- Clients may choose to not support FFDHE, a la Chrome. I don't see
consensus for full deprecation of FFDHE, please correct me if I'm wrong.
- Clients must not connect when the server uses a group of less than 2048
- Clients may connect when the server uses a well-known, safe prime group
of at least 2048 bits (well-known might mean "from RFC 7919 plus the
built-in Postfix group", or other reasonable definitions).
- Clients may connect when the server uses a custom safe prime group of at
least 2048 bits, if the client verifies that the prime is safe.

The only point where we don't have consensus seems to be:
- For clients who choose to support FFDHE, when the server uses a custom
group of at least 2048 bits, and the client isn't willing to check
safe-primality, what should the client do?
(This only applies when FFDHE is chosen in practice, rather than ECDHE.)
My personal opinion is that both options - either allowing or forbidding
the client to connect - would be reasonable here.
Perhaps it'd be best to leave this specific point to the next WG meeting?
We can still make progress on the document in the meanwhile.

I'll also ask around if we can get some metrics, in general and
specifically pertaining to that last point.

thanks again everyone,

---------- Forwarded message ---------
From: Viktor Dukhovni <>
Date: Sat, 31 Jul 2021 at 19:12
Subject: Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange
Methods in TLS
To: <>

On Sat, Jul 31, 2021 at 12:57:39PM +0000, Peter Gutmann wrote:
> Viktor Dukhovni <> writes:
> >I strongly doubt there's a non-negligible server population with weak
> >generated groups.
> Would you care to rephrase that so we can make sure you're saying what we
> think you're saying in order to disagree with it?

OK, who goes around bothering to actually generate custom DH parameters,
and with what tools, but then does not use a "strong" (Sophie Germain)

The only weakness I expect to encounter is a deprecated size of e.g.
512, 768 or 1024 bits.  Clients can easily detect that and enforce a
floor, but of course still don't get to negotiate a minimum.

Clients also don't get to negotiate the size of the server's RSA public
key, or as you mentioned various other ways for the server to not screw


TLS mailing list