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

[Henrick Hellström <[e-mail]>]

Hi Richard,

As an independent implementer, I would like to weigh in. I believe there 
might be a misunderstanding here.

While it is common for software libraries to implement active 
Internet-Drafts, this is not a viable long-term solution. Features 
backed only by a rejected, long-dead draft cannot be safely maintained 
over time.

Furthermore, while hardware isn't my primary domain, I highly doubt any 
hardware manufacturer would commit resources to implementing a rejected 
draft.

 >> 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.

Henrick Wibell Hellström,
StreamSec

On 2026-07-07 04:35, Richard T. Carback III wrote:
> Hi Uri,
> 
> Please read my entire comment, specifically the 4th paragraph which addressed this and states:
> 
>> 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.
> 
> 
> Cheers,
> 
> Richard T. Carback III, PhD
> CTO, Postquant Labs
> 
> 
> 
>> On Jul 6, 2026, at 21:16, Blumenthal, Uri - 0553 - MITLL <[e-mail]> wrote:
> 
>> This is not about being able to implement — it’s about being able to implement in an interoperable way.
> 
>> I do wish people would gain some IETF experience before speaking up.
>> --
>> V/R,
>> Uri
>> From: Richard T. Carback III <[e-mail] <mailto:[e-mail]>>
>> Date: Monday, July 6, 2026 at 21:08
>> To: [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
>> Cc: [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
>> Subject: [EXT] [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)
> 
>> -----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]
> 
>> 

> 
> 
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]