[TLS] Re: Status of ML-KEM WGLC

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 23 March 2026 05:30 UTC

Date: Mon, 23 Mar 2026 16:30:45 +1100
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <acDQBdwmqyF8QGor@chardros.imrryr.org>
References: <CAOgPGoDd=qhg-mGzB8mrFOGVKHY_9uz+_EO3P_i0_e8TG6v0Mw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAOgPGoDd=qhg-mGzB8mrFOGVKHY_9uz+_EO3P_i0_e8TG6v0Mw@mail.gmail.com>
Mail-Followup-To: <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: VGVJYMKZQZIQ65PNWE33NZTCC7557YPX
Precedence: list
Reply-To: tls@ietf.org
Subject: [TLS] Re: Status of ML-KEM WGLC
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/CMqmXhpJiA_PAh8EvoHRYi0vVwA>

On Sun, Mar 22, 2026 at 10:49:56AM -0700, Joseph Salowey wrote:

> We are working through issues brought up during the working group last
> call. We believe addressing these issues is necessary to determine if we
> have rough consensus to move forward. We expect the author to address the
> following points:
> 
> * Key Reuse
> * Text for preferring Hybrids
> * Whether to include motivations (see Liaison Statement)
> 
> We expect resolving these issues will take a few weeks after which we will
> run a targeted consensus call to see if text changes are acceptable to the
> working group.

FWIW, the essential question that might be answered is whether an
updated I-D would be less objectionable if:

    - Advocacy for use of non-hybrid ML-KEM in some example use cases
      were removed.  Yes, that perhaps creates an opening to criticise
      the draft as "lacking motivation", but I don't think that's a
      substantive concern.  The motivation is to publish a stable
      specification of the how, not the why.

      For an example of "jus the how", see "Elliptic Curve Cryptography
      (ECC) Cipher Suites for Transport Layer Security (TLS) Versions
      1.2 and Earlier": <https://datatracker.ietf.org/doc/html/rfc8422>,
      in which I find just the nuts and bolts, apologies if I overlooked
      the advocacy section.

      Another "just the how", can be found in "Negotiated Finite Field
      Diffie-Hellman Ephemeral Parameters for Transport Layer Security
      (TLS)": <https://datatracker.ietf.org/doc/html/rfc7919>, there's
      no advocacy there to use FFDHE over ECDHE, just a means to more
      negotiate of the specified groups.  Some (or many) now consider
      negotiated FFDHE undesirable in both TLS 1.2 and 1.3, but if you
      want to use it, there's a published reference.

    - Clear guidance in the security considerations were added to
      note that hybrid algorithms provide a recommended safety net,
      in case the still novel ML-KEM construction succumbs to an 
      improved attack.  That is, hybrids are recommended unless
      the user fully understands and accepts the risk of relying
      on ML-KEM alone.

    - "Feel good" prohibition of reuse of its ephemeral key by the client
      across multiple connections is added.

    - The importance of non-reuse of the encapsulation random value by
      the server is noted.  This would allow the associated clients to
      compute the shared secret the server negotiated with other clients
      (provided the associated public keys, sent in the clear in the
      client hello messages, are known).

This I-D presents an opportunity to those who would like to see a strong
recommendation in favour of hybrids across all IETF specifications to
test whether consensus for such a recommendation can at least be reached
in the context of this draft.

Given the extant IANA code points, and that support for non-hybrid
ML-KEM is already present (though typically either or both not
preferred, or enabled by default) in multiple TLS libraries, I see no
rational motivation to oppose publication "in any form".  Surely, with
appropriate caveats there's a way to get this specification published
as an informational(!) RFC.

Blocking its publication changes little in practice, but creates some
confusion about whether the specification is still subject to change,
and may leave an impression that the IETF is out of touch. :-(

-- 
    Viktor.  🇺🇦 Слава Україні!

[TLS] Status of ML-KEM WGLC Joseph Salowey
[TLS] Re: Status of ML-KEM WGLC Stephen Farrell
[TLS] Re: Status of ML-KEM WGLC Muhammad Usama Sardar
[TLS] Re: Status of ML-KEM WGLC Filippo Valsorda
[TLS] Re: Status of ML-KEM WGLC Eric Rescorla
[TLS] Re: Status of ML-KEM WGLC Viktor Dukhovni
[TLS] Re: Status of ML-KEM WGLC Loganaden Velvindron
[TLS] Re: Status of ML-KEM WGLC Nadim Kobeissi
[TLS] Re: Status of ML-KEM WGLC Viktor Dukhovni
[TLS] Re: Status of ML-KEM WGLC Filippo Valsorda
[TLS] Re: Status of ML-KEM WGLC Loganaden Velvindron
[TLS] Re: Status of ML-KEM WGLC Eric Rescorla
[TLS] Re: Status of ML-KEM WGLC Joseph Salowey
[TLS] Re: Status of ML-KEM WGLC Daniel Apon
[TLS] Re: Status of ML-KEM WGLC Eric Rescorla
[TLS] Re: Status of ML-KEM WGLC John Mattsson
[TLS] Re: Status of ML-KEM WGLC Muhammad Usama Sardar
[TLS] Re: Status of ML-KEM WGLC Paul Wouters
[TLS] Re: Status of ML-KEM WGLC Watson Ladd
[TLS] Re: Status of ML-KEM WGLC Daniel Apon
[TLS] Re: Status of ML-KEM WGLC Daniel Apon
[TLS] Re: Status of ML-KEM WGLC Peter Gutmann