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 LabsOn Jul 6, 2026, at 21:16, Blumenthal, Uri - 0553 - MITLL <[email protected]> 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 <[email protected] <mailto:[email protected]>> Date: Monday, July 6, 2026 at 21:08 To: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]>> Cc: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]>>; [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]>>; [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]>> Subject: [EXT] [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256I 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 LabsReferences [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 forTLS 1.3. The main question before the working group is: "Should theworking group publish a document specifying stand alone ML-KEM?". Ifthere is rough consensus then we will push to refine and publish thedocument; otherwise, we will stop discussing the draft and notprogress it. Please respond to this call indicating whether yousupport publishing a document specifying a stand alone ML-KEM. Pleaserefrain from further discussion on this topic as most arguments havebeen discussed multiple times.Why are we holding this consensus call now?Significant developments have occurred both within this document andin the broader TLS ecosystem to address the concerns raised in thelast WGLC. Therefore, the third consensus call is warranted. We askthe working group to consider document publication in light of theserecent changes:- Promotion of Hybrids in draft-ietf-tls-ecdhe-mlkem: Following aseparate consensus call, the WG agreed to promote the X25519MLKEM768hybrid group to Recommended: Y in the IANA registry. Consequently,the IANA registry will reflect a clear community preference for ahybrid because Recommended: Y clearly indicates this while thestandalone ML-KEM groups defined in this draft remain Recommended: N.The updated security considerations in [1] reference the IANAregistry to emphasize this preference.- Key Share Reuse Prohibited in draft-ietf-tls-rfc8446bis: The WGrecently reached consensus to explicitly prohibit key share reuseacross connections in TLS 1.3. The new text changes the guidance fromSHOULD NOT to a strict MUST NOT. This resolves the concerns regardingstatic key reuse and its associated privacy and forward-secrecy risksfor ML-KEM.- Nadim updated the ProVerif model of TLS 1.3 to evaluate KEM andhybrid KEM groups in TLS 1.3. This supports other results which showthat KEMs are secure when used in TLS 1.3 and that hybrid groups aresecure even if one of the components is compromised.- Liaisons: We received liaison statements from multiple SDOsincluding O-RAN[2], IEEE 802.11[4] and from 3GPP[3] expressingsupport for the publication of draft-ietf-tls-mlkem as an RFC as theyrely on the IETF to provide a stable normative reference.Please note that a third-party IPR disclosure exists [5] against thisdocument regarding patents related to the underlying ML-KEMalgorithm. This IPR declaration has not changed since the last WGLC.As a reminder, per BCP 79, the IETF takes no stance on the validityof patent claims, and the working group may decide to proceed with atechnology despite IPR disclosures if it decides that such use iswarranted.Conduct Reminder: Given the heated nature of previous discussions onthis topic, participants are strongly reminded to adhere to the IETFCode of Conduct (BCP 54) and the TLS WG's Mail List Procedures. Keepfeedback 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 -- [email protected]To unsubscribe send an email to [email protected]
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
