IETF Logo Mail Archive

[TLS] Publish ML-KEM after all (Re: Re: New Liaison Statement, "Liaison communication to IETF regarding draft-ietf-tls-mlkem")

Nico Williams <nico@cryptonector.com> Sat, 04 April 2026 04:56 UTC

Return-Path: <nico@cryptonector.com>
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 CA386D655C06 for <tls@mail2.ietf.org>; Fri, 3 Apr 2026 21:56:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1775278603; bh=h+4QCyrvfKjRYgu32SmuWDz3bDWXLVqwLSJ1w0SMo+U=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=eWQ1T1pUWXQf19HkXoIvgqman8irwOJEottXzk00aD5gTQR6OOHRXCHNmiuIV/nkX 1cTfCKPUIEiJHLQuHX1028H0fBoj92UByAETrsWJ6eAELTh3fjsEytgVe3amCe1XAh cT5rheerp5yuhjCbc4LxAF42A0apxabU77P0Sb8w=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=cryptonector.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxsiKMf-Af3l for <tls@mail2.ietf.org>; Fri, 3 Apr 2026 21:56:43 -0700 (PDT)
Received: from aye.elm.relay.mailchannels.net (aye.elm.relay.mailchannels.net [23.83.212.6]) (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 F15A9D655C01 for <tls@ietf.org>; Fri, 3 Apr 2026 21:56:42 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id A479182259B; Sat, 04 Apr 2026 04:56:36 +0000 (UTC)
Received: from pdx1-sub0-mail-a207.dreamhost.com (100-121-207-159.trex-nlb.outbound.svc.cluster.local [100.121.207.159]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 3020782302E; Sat, 04 Apr 2026 04:56:36 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; d=mailchannels.net; s=arc-2022; cv=none; t=1775278596; b=J8GwPfrHi5+SVwe+MyezT6Z4ozioeGw78k7h+UEpaZ+3M9QtlYOoYnkSkXxNYvUx3EaHkx s0B8cu/RXgTGlT3Z9cyswcGlhd+5PIRkbtEEFoc5jglH2s//ItMutFOD7uNGyM32MBBUgu o4lNXzKpStBcnxMFu0FWFrrGY5vdGALK3Zjybh4+0p8v26xwwwKD5Rymbsh7/GkbodpF1U qJ0yo1C8jYQHhX70Xc/JloO86Tm3QM7JktEq4Xs4yCmlOwLOlsbumyh5BqohYpOxEK/PDm U6DW6VWJWRc4CyWNoaYZvWIJgtD4qJD0q/YX96msued5lpP2AS/J/Jlbegf2GA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1775278596; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:dkim-signature; bh=sHceE8ah4eyIn62IEqHeg/jsaXFZPWbC9HTP0nfEe3A=; b=zrNQRbsKCEqd7+m2OilDOBCUcken79PvUACFBoqzEWQX4tn87aM14ykhu7uRMycRcI1Xpc IP3gf3TIQR3p5eolCR3gssoTrWhuNew2f9zUJD3gKlxCe0ijljylCwgBwPcHwXFkDbEZI7 Ge8fZHT85Jon9uhZY1tQMk7spxBTmsz+phyYBFb5ds30Lu83gzUFBe66XB+ite6VtQS0o/ D0CxYzncfugtelgfq+bNKK1rBadqQm2b3DHsOqwdLWMHB+allpAfbrMztkQvru/EQ3osV9 5xnGspr80T3axtSVkVcwfcCR3QPKDZxzg8QqzaQKTwKtX7WMBMLWx18OxGCvFA==
ARC-Authentication-Results: i=1; rspamd-7d86dcc447-dlzb5; auth=pass smtp.auth=dreamhost smtp.mailfrom=nico@cryptonector.com
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Bottle-Troubled: 5f72c9321151aa4b_1775278596433_723181351
X-MC-Loop-Signature: 1775278596433:4200348565
X-MC-Ingress-Time: 1775278596433
Received: from pdx1-sub0-mail-a207.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.121.207.159 (trex/7.1.5); Sat, 04 Apr 2026 04:56:36 +0000
Received: from ubby (unknown [75.81.95.64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a207.dreamhost.com (Postfix) with ESMTPSA id 4fnjwz3fvTz1M8; Fri, 3 Apr 2026 21:56:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cryptonector.com; s=dreamhost; t=1775278596; bh=sHceE8ah4eyIn62IEqHeg/jsaXFZPWbC9HTP0nfEe3A=; h=Date:From:To:Cc:Subject:Content-Type; b=e5pFaAcMvuHBIN308uBNRYF+2PbrqmkHeDYPHg3I19qXBVaoQmI1td+9w8vTfpv/g zlQKYpuXk92Rp+9pYEIRjpO6O0fLa52lT1B7CthobhyUxJvAemufdvtcPM/9gtQA4c fQuBE/ISVyF2X8Ou53mL8mvKgQFMcWgkhtYf+BhWQoNSExODUbyu9rv4wBB7LknGB0 VTyRsR+WZk3TgMUwVl2UVjeIxLL6jDspufiJZVjuHhIB2sj4iM4VKKJhQR89bIJ5yh zFpneZlvmOxnjnH8lL6bMdocOakSKX9CAIxgNHAOdCZ1EwQD/ruILwU1xs36fAZD6n edKLpl0B8vx4Q==
Date: Fri, 03 Apr 2026 23:56:33 -0500
From: Nico Williams <nico@cryptonector.com>
To: Russ Housley <housley@vigilsec.com>
Message-ID: <adCaAWmOkit8jNJo@ubby>
References: <2efcd86e-c248-4cce-a601-b65e3ee4b5ae@tu-dresden.de> <5E23938A-6AAC-44A8-A515-C8B031203A16@vigilsec.com> <CAL02cgRS0VXm9ZyXZd=-ZOi-VCvTbvk05rjbTCm6_ksgu-RBKg@mail.gmail.com> <ac7oEfBv6zLisnIi@ubby> <CAL02cgRyekc5oz5FaGRcLvxcxNrUSYKH0pXxxxATke_SLZ1aLw@mail.gmail.com> <CAF8qwaBcotZqOnY2qJ6d0fRoa=5v0sZTOSWqeqkou+bLJcy9LA@mail.gmail.com> <CABcZeBPr+WeivTWpSCVC4f95fRuSiOytvvBPB_6r+af9Didhgw@mail.gmail.com> <CEB84168-5998-432A-9D62-36E28B9CDFA5@vigilsec.com> <CABcZeBM-eoqh+kJ7H6SiwC9p4tKAt+YiQhzetJZJmPNpXc+5OA@mail.gmail.com> <34F06406-749F-46DF-9F50-AC2B99C3BBC0@vigilsec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <34F06406-749F-46DF-9F50-AC2B99C3BBC0@vigilsec.com>
Message-ID-Hash: UW2MUWGHRDNFMZ3YQFDEYO37QGY7GANY
X-Message-ID-Hash: UW2MUWGHRDNFMZ3YQFDEYO37QGY7GANY
X-MailFrom: nico@cryptonector.com
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
CC: Transport Layer Security Discussion List <tls@ietf.org>, Sean Turner <sean+ietf@sn3rd.com>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Publish ML-KEM after all (Re: Re: New Liaison Statement, "Liaison communication to IETF regarding draft-ietf-tls-mlkem")
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/gRr7LnImlDYbWQZZuOCMR03AftA>
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>

On Fri, Apr 03, 2026 at 02:26:45PM -0400, Russ Housley wrote:
> If the IETF does not publish such document in a way that other SDOs
> can cite them, then some other group will fill that void.  We know
> that the IEEE needs a document to reference.  I believe 3GPP and ITU-T
> are in the same situation.  In my view, another body filling that void
> would be bad for the IETF.  Maybe that is the point where we disagree,

The IETF specified GSER outside ITU-T SG-17.  ECMA specifies JSON and
has rather disagreed with IETF about JSON before.  This sort of thing is
not the end of the world.  If as far as IANA is concerned the ML-KEM
codepoints come from an I-D and the IEEE/3GPP/ITU-T/etc. all use an IEEE
(say) standards document instead, the situation will resemble JSON and
will not be a terrible one.

That said, if other SDOs are willing to fill this gap then that is a
good argument for the IETF publishing ML-KEM as an Internet RFC after
all.  Not because other SDOs doing so is particularly bad but because
there is no point rejecting ML-KEM here if it will be a fait accompli
_and_ we lose an opportunity to state the (real) consensus that we
prefer hybrids.

In other words: why oppose publication of ML-KEM?  Because it's not a
hybrid.  But the rest of the world will use it anyways, so what will we
have accomplished?  IMO we should publish ML-KEM with suitable Security
Considerations language recommending the use of hybrids for some time.

Nico
--

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