[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

Jan Schaumann <jschauma@netmeister.org> Thu, 27 February 2025 03:53 UTC

Return-Path: <jschauma@netmeister.org>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id DF697282BE8 for <tls@mail2.ietf.org>; Wed, 26 Feb 2025 19:53:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietfa.org (amavisd-new); dkim=pass (2048-bit key) header.d=netmeister.org
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietfa.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mj4Xb3tgNZ60 for <tls@mail2.ietf.org>; Wed, 26 Feb 2025 19:53:39 -0800 (PST)
Received: from panix.netmeister.org (panix.netmeister.org [166.84.7.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 0802D282BE3 for <tls@ietf.org>; Wed, 26 Feb 2025 19:53:38 -0800 (PST)
Received: by panix.netmeister.org (Postfix, from userid 1000) id 2AC8B5359D; Wed, 26 Feb 2025 22:53:08 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=netmeister.org; s=2025; t=1740628388; bh=InVn52NP2S8xO9ss7aZlqjgZxRY6P7z97y4uxsrcR+k=; h=From:To:Subject:Content-Type:From:To:Subject; b=I6WziiZBxM6IlXNbDDMOCWVlD7TQT4jcsDyCK78mjTV5JXGDxznbX6FiRRF6ZujaA N6gZzVHQTWOm1t3R5EuEAZ5fon0VQh2p3+IVdbOQt/mInGZ75oEEvAat/gsWCPx+GP VXTgWlLQlkQ0KHfh/gD3aw3rLL32l0y/MPwvxVD1sxDs+MmdIw88dsdOJSNF9YAIiG klOQAJXYicMIOJSyzfDSx719TwjI5cfaTs6wmyBLlsw33AewdYzoz9O7JRkFwC+Ob0 D5SSfxn2d3T/QGx47bfkZe6lSVlt9blEi5N0sYrxuUqIEZ6SLmPfrvfpCjVVNgHUB7 fu1VFcqLyDoQg==
Date: Wed, 26 Feb 2025 22:53:07 -0500
From: Jan Schaumann <jschauma@netmeister.org>
To: "tls@ietf.org" <tls@ietf.org>
Message-ID: <Z7_ho3LlAQ4oT7NS@netmeister.org>
Mail-Followup-To: "tls@ietf.org" <tls@ietf.org>
References: <68EDF12D-1C97-4823-AFFE-19BF261D7034@sn3rd.com> <E0D776C8-FD56-4D0B-BDC1-3AB88A8CEE88@heapingbits.net> <Z7-CbKePNWI1FdOH@netmeister.org> <ME0P300MB071318BBC6F7E42D7BC6F85CEECD2@ME0P300MB0713.AUSP300.PROD.OUTLOOK.COM> <CADQzZqttobvF_0ui6c4_sFCBronXeYmk+4APc4+dBPNn9bxCUQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CADQzZqttobvF_0ui6c4_sFCBronXeYmk+4APc4+dBPNn9bxCUQ@mail.gmail.com>
Message-ID-Hash: 5GFLQF2RRVUBU45TZNDNQSGREP3KWSLL
X-Message-ID-Hash: 5GFLQF2RRVUBU45TZNDNQSGREP3KWSLL
X-MailFrom: jschauma@netmeister.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/IC5umbQ1hkX-mNWJpCImww6nPSY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

Mike Shaver <mike.shaver@gmail.com> wrote:
> It's interesting, IMO, that there is so much belief that an RFC designation
> will drive so much adoption here, but it didn't seem to be the same
> consensus that enshrining SSLKEYLOGFILE in an RFC might increase the number
> of systems that support key exfil.

My guess: Different target audience.  SSLKEYLOGFILE is
of interest primarily to folks working lower on the
stack with much higher understanding of the details.

Support for PQC TLS key exchanges is an actual feature
to sell and market in large scale services and
commercial products with millions of dollars of
product or contracts on the line.

-Jan