Subject: [TLS] Publish ML-KEM after all (Re: Re: New Liaison Statement, "Liaison communication to IETF regarding draft-ietf-tls-mlkem")
From: Nico Williams <[email-masked]>
To: Russ Housley <[email-masked]>
Cc: Transport Layer Security Discussion List <[email-masked]>, Sean Turner <[email-masked]>
Date: Fri, 3 Apr 2026 23:56:33 -0500
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.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
--