IETF Logo Mail Archive

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

Jan Schaumann <jschauma@netmeister.org> Wed, 26 February 2025 21:07 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 BB76323ED89 for <tls@mail2.ietf.org>; Wed, 26 Feb 2025 13:07:24 -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 JMhX8-YjTTje for <tls@mail2.ietf.org>; Wed, 26 Feb 2025 13:07:23 -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 7352523ED68 for <tls@ietf.org>; Wed, 26 Feb 2025 13:07:23 -0800 (PST)
Received: by panix.netmeister.org (Postfix, from userid 1000) id AD33B5359D; Wed, 26 Feb 2025 16:06:52 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=netmeister.org; s=2025; t=1740604012; bh=cxJqX9H3qeLsSLINPOWSRpdBaQOrdGnROYxDlYizJV0=; h=From:To:Subject:Content-Type:From:To:Subject; b=YwcTcY++MO3yn7gBGG+W3lnjuooNR0idoIf15LRefpcG+ynyGreUeX7AcPnyc2i4Z TsGhzgJNOAds7K8wPz8Dk0ST38f0wOOFBiw/KR0EBPZ+vRODzko15cviNQ0uYBigCB sYTZylXP2hx0qPANK1AOaYu0TARStdFfPAciksxd7MzMhcQWDSsSWKZwj0AAQTjVaL iOiRKIfM8v5hk0af5dMaz577U8XRUTnFm06eigYNgOqzBlWaevOvBrCiWq/Ox0JN+5 Z2sdgYRSlj6f8RGyr8PT1EIXo+wKYHdKfdQn9se5/o4ABsLao7iu1JyEHU1SXBMNQE 7TIqJrZPhv9Dg==
Date: Wed, 26 Feb 2025 16:06:52 -0500
From: Jan Schaumann <jschauma@netmeister.org>
To: tls@ietf.org
Message-ID: <Z7-CbKePNWI1FdOH@netmeister.org>
Mail-Followup-To: tls@ietf.org
References: <68EDF12D-1C97-4823-AFFE-19BF261D7034@sn3rd.com> <E0D776C8-FD56-4D0B-BDC1-3AB88A8CEE88@heapingbits.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <E0D776C8-FD56-4D0B-BDC1-3AB88A8CEE88@heapingbits.net>
Message-ID-Hash: OUV4ZLXNZNXK664PBSD7HMGKPZWXH3VK
X-Message-ID-Hash: OUV4ZLXNZNXK664PBSD7HMGKPZWXH3VK
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/ley3r4L47ZEH8Os0RatH9CGKxb8>
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>

Christopher Wood <caw@heapingbits.net> wrote:
> I wonder: what is the point of adopting this draft when the important work is already done? If it’s that some folks won’t implement it until there’s an RFC number assigned to it, well, that’s pretty silly.

It may seem silly to all folks who are directly
involved here in these discussions, but many software
and service providers view a "draft" as immature, not
final, subject to change and may not implement until
it has an RFC number.

For those who are not actively tracking developments
in the IETF and standards communities and who are
relying on formal publications, this is an important
signal.

Likewise, for customers of such providers it's a lot
easier to inquire "do you implement RFCXXXX" or, for
interoperation, to request compliance with an RFC than
with a "draft".

With that, I support adoption.

-Jan

v2.29.0 | Report a Bug | By Email | System Status