[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)

["Richard T. Carback III" <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I do not support publishing draft-ietf-tls-mlkem-08 at this time.

I strongly urge the working group to wait a couple years for
implementations to mature and for QPUs to get closer. The
implementations are not ready, and what regulated deployments
need is nascent.

Even with "Recommended=N", publication is not neutral. The value of
an RFC, which is stated plainly in the announcement that opened this last
call [1],  is that downstream bodies rely on it: this announcement
cites liaisons from O-RAN, IEEE 802.11, and 3GPP requesting
publication because they "rely on the IETF to provide a stable
normative reference”.  That is, they want a standard to build
deployment on. An artifact that those bodies lobby for because it
will shape their decisions cannot, in the same breath, be said to
have no bearing on their decisions.

The cost of waiting is low. The ML-KEM code points already exist in
the registry at Recommended=N [2], so anyone who wants to implement
pure ML-KEM can already do so and interoperate today, without the
RFC. Thus, the substance this doc adds seems to reduce to an IETF
endorsement, which only encourages pure-only deployment in my view.

Given that the mission of the IETF is to seek the best outcome for
the whole Internet, the responsible default is caution (for now).
We are in the fortunate position of having a strictly stronger,
negligible-cost, already-Recommended=Y alternative available:
X25519MLKEM768 [2]. This has not been true for this kind of work
historically, with unfortunate and unavoidable fallout. Some
examples include:

   - RSA key-transport and static-DH suites were marked
     Recommended=N in 2018 (RFC 8447 [3]). Raccoon (2020) then
     exploited permitted-but-discouraged DH secret reuse in
     fielded stacks. CVE-2020-5929 did not even need a timing
     oracle [4] and Marvin (2023) found the 25-year-old
     Bleichenbacher timing class still live across OpenSSL,
     GnuTLS, Java, Go, Node.js, Mbed TLS, and hardware modules [5].

   - Export-grade RSA and DH, forced into stacks by 1990s
     regulation, were still enabling FREAK (CVE-2015-0204) and
     Logjam (CVE-2015-4000) twenty years later [6][7].

   - The heartbeat extension gave us Heartbleed in 2014
     (CVE-2014-0160, RFC 6520 [8]); AFAIK, the IANA
     registry still lists heartbeat as Recommended=Y [2].

Contrast these with one of IETF's finer moments: RFC 6176
prohibiting SSLv2 outright in 2011 [9]. Five years later DROWN
(CVE-2016-0800) used still-deployed SSLv2 to break TLS for roughly
a third of HTTPS servers [10]. While a "MUST NOT" did not
decommission everything, it did substantially reduce the impact
(and personally saved my infrastructure at the time).

In terms of **when** publication might make sense, I propose two
gates, both of which should hold:

1. A demonstrated CRQC.
2. ML-KEM available in more than one independently validated FIPS
   140-3 or similarly vetted module with published
   side-channel-resistance results.

An available CRQC diminishes the security of ECDSA to the cost to
run the attack (which is not likely to be trivial [11]). At which
point the PQC side protects. It will likely be a few years or more
before such CRQCs become common place.

High quality vetted implementations of the core primitives are
necessary for regulated deployments, and they should exist in some
quantity before an IETF endorsement for pure constructions. I did
read that much of this thread argued maturity in terms of whether
an ephemeral key exchange tolerates a bug. I believe that this is
the wrong yardstick for many deployments that are hard to fix
after the fact. Regulated systems like financial infrastructure
and anything under Common Criteria or FIPS evaluations often run
their cryptography inside validated boundaries and certified HSMs,
and they patch on validation timelines, not software timelines, so
I think it prudent to discourage pure-only option for these at the
moment.

No one can predict the future, but we do know the past. Endorsing
a pure mode now is an unnecessary risk when we have safe low-cost
alternatives.

In summary, for these reasons I believe that publishing this now
is not in the best interests of the internet. If the working group
does publish now, then at minimum the Security Considerations
should state the hybrid preference in the document body rather
than by reference to the registry column, and should note
explicitly that deployments bound by module-validation
requirements face a materially different risk profile with
standalone ML-KEM than with the hybrid groups.

I write as an implementer of post-quantum primitives (an early PQ
Ratchet, WOTS+/SHRINCS) and as someone who works with downstream
operators bound by module-validation and regulatory constraints.
It is from this perspective that this document looks premature.

Sincerely,

Richard T. Carback III, PhD
CTO, Postquant Labs

References
[1]  WG Last Call: draft-ietf-tls-mlkem-08 (J. Salowey, 2026-06-24)
     -- the announcement that opened this thread; the liaison quotes
     above are from it:
     <https://mailarchive.ietf.org/arch/msg/tls/ol2otAvtdDrdz_xY0_eKcuY1om0/>
     Full thread:
     <https://mailarchive.ietf.org/arch/browse/tls/?q=%22WG%20Last%20Call%3A%20draft-ietf-tls-mlkem-08%22>
[2]  IANA TLS Supported Groups registry (MLKEM512/768/1024 =
     Recommended N; X25519MLKEM768 = Y) and TLS ExtensionType
     registry (heartbeat = Recommended Y):
     <https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml>
     <https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml>
[3]  RFC 8447, IANA Registry Updates for TLS and DTLS (Recommended
     column): <https://www.rfc-editor.org/rfc/rfc8447.html>
     (updated by RFC 9847:
     <https://www.rfc-editor.org/rfc/rfc9847.html>)
[4]  Raccoon Attack: <https://raccoon-attack.com/> ; F5
     CVE-2020-5929; OpenSSL CVE-2020-1968:
     <https://nvd.nist.gov/vuln/detail/CVE-2020-1968>
[5]  Marvin Attack (timing Bleichenbacher, affected-implementation
     list): <https://people.redhat.com/~hkario/marvin/>
[6]  FREAK, CVE-2015-0204:
     <https://nvd.nist.gov/vuln/detail/CVE-2015-0204>
[7]  Logjam, CVE-2015-4000 (weakdh.org)
     <https://weakdh.org/> ;
     <https://nvd.nist.gov/vuln/detail/CVE-2015-4000>
[8]  Heartbleed, CVE-2014-0160 (RFC 6520 Heartbeat extension):
     <https://nvd.nist.gov/vuln/detail/CVE-2014-0160> ;
     <https://www.rfc-editor.org/rfc/rfc6520.html>
[9]  RFC 6176, Prohibiting Secure Sockets Layer (SSL) Version 2.0:
     <https://www.rfc-editor.org/rfc/rfc6176.html>
[10] DROWN Attack (CVE-2016-0800; ~33% of HTTPS servers):
     <https://drownattack.com/> ;
     <https://nvd.nist.gov/vuln/detail/CVE-2016-0800>
[11] Quantum Doom Clock, which references several analyses:
     <https://quantumdoomclock.com/>



On Wed, 2026-06-24 at 08:00 -0700, Joseph Salowey via Datatracker
wrote:
> This message initiates a new Working Group Last Call for draft-ietf-

> tls-mlkem[1], which defines standalone ML-KEM key establishment for

> TLS 1.3. The main question before the working group is: "Should the

> working group publish a document specifying stand alone ML-KEM?". If

> there is rough consensus then we will push to refine and publish the

> document; otherwise, we will stop discussing the draft and not

> progress it. Please respond to this call indicating whether you

> support publishing a document specifying a stand alone ML-KEM. Please

> refrain from further discussion on this topic as most arguments have

> been discussed multiple times.

> 

> Why are we holding this consensus call now?

> 

> Significant developments have occurred both within this document and

> in the broader TLS ecosystem to address the concerns raised in the

> last WGLC. Therefore, the third consensus call is warranted. We ask

> the working group to consider document publication in light of these

> recent changes:

> 

> - Promotion of Hybrids in draft-ietf-tls-ecdhe-mlkem: Following a

> separate consensus call, the WG agreed to promote the X25519MLKEM768

> hybrid group to Recommended: Y in the IANA registry. Consequently,

> the IANA registry will reflect a clear community preference for a

> hybrid because Recommended: Y clearly indicates this while the

> standalone ML-KEM groups defined in this draft remain Recommended: N.

> The updated security considerations in [1] reference the IANA

> registry to emphasize this preference.

> 

> - Key Share Reuse Prohibited in draft-ietf-tls-rfc8446bis: The WG

> recently reached consensus to explicitly prohibit key share reuse

> across connections in TLS 1.3. The new text changes the guidance from

> SHOULD NOT to a strict MUST NOT. This resolves the concerns regarding

> static key reuse and its associated privacy and forward-secrecy risks

> for ML-KEM.

> 

> - Nadim updated the ProVerif model of TLS 1.3 to evaluate KEM and

> hybrid KEM groups in TLS 1.3. This supports other results which show

> that KEMs are secure when used in TLS 1.3 and that hybrid groups are

> secure even if one of the components is compromised.

> 

> - Liaisons: We received liaison statements from multiple SDOs

> including  O-RAN[2], IEEE 802.11[4] and from 3GPP[3]  expressing

> support for the publication of draft-ietf-tls-mlkem as an RFC as they

> rely on the IETF to provide a stable normative reference.

> 

> Please note that a third-party IPR disclosure exists [5] against this

> document regarding patents related to the underlying ML-KEM

> algorithm. This IPR declaration has not changed since the last WGLC.

> As a reminder, per BCP 79, the IETF takes no stance on the validity

> of patent claims, and the working group may decide to proceed with a

> technology despite IPR disclosures if it decides that such use is

> warranted.

> 

> Conduct Reminder: Given the heated nature of previous discussions on

> this topic, participants are strongly reminded to adhere to the IETF

> Code of Conduct (BCP 54) and the TLS WG's Mail List Procedures. Keep

> feedback professional, technical, and focused on the document's text.

> 

> This working group last call will end on 2026-07-08.

> 

> Joe and Sean

> 

> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/

> [2] https://datatracker.ietf.org/liaison/2198/

> [3] https://datatracker.ietf.org/liaison/2151/

> [4] https://datatracker.ietf.org/liaison/2148/

> [5]

> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-tls-mlkem

> 

> _______________________________________________

> TLS mailing list -- [e-mail]

> To unsubscribe send an email to [e-mail]

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wsGoBAEBCABdBYJqTFFACRA/GuWbfQE6TTUUAAAAAAAcABBzYWx0QG5vdGF0
aW9ucy5vcGVucGdwanMub3JnMFgBVhHKkaWhfwSdn72QMRYhBAGFytdGt1Ef
10NhlD8a5Zt9ATpNAABE3Q/40T+1I67LRFYp14KAwY+FCmJvtOkUS+7vNY87
ABgqJzLV57LN/GnNS2ee/pPmKuB8iPtvS7fHu+x/H1wbwmDh6rh8kr4Y/ZOW
U5175F+Xp5NIGM3ola7TCnEpqZaDUgdQHPN8yJM5RRyQs5Ygfv6L6owoDADr
00DrScUCghZUqYtoWgpkeO4e9vTj5jMU+z9xvS23/nx5H3FzKaEW99J690Nm
BjDiDz5ANv/tCy3Xb7RGw29ZYd4LzRlRIGyDTxM1mw5A5JWWXURRsr+xG0Xb
xCEQk6qkPpmWquhTJ+PMLj+ftUGeMP72XfFqDzIMwd2KthzjIBMdBbKtXzwc
RHIYEhSd4aZMe4PhQYupJhUuOFnR8t3We6SwDmWPf0Qd/BBQGkWkPJPPXNUj
iDbjtPOREXok7nk6XFR2i8/fAfdvzrXM28EuoBI/2CvFlDcxK1+Bw9wM/Yqc
8wod3CehTc42dTwKGkjDQMI7s8/dvnIQVn1eMdB9LtKQrjZg+G0Zc+eW3kCI
VE7fL2mIUjkAJ5l702k7iFW7ZcZmdsAejdLBRGna+2onorsn93akjgjy/Fha
SjjRYUZ41J2vkjFrbAk+AH3MpnMPaep1VujxFnAc2LFCK6R62VmIW0Eub9Rk
c4cx5LUG167+yXuMB+MhgdnXDwJCFk3FXYrj9gbkI2xZ5A==
=qdtL
-----END PGP SIGNATURE-----