-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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 <[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: 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 -- [email protected] > > > To unsubscribe send an email to [email protected] > > -----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----- -----BEGIN PGP SIGNATURE----- Version: ProtonMail wsGpBAEBCABdBYJqTGXoCRA/GuWbfQE6TTUUAAAAAAAcABBzYWx0QG5vdGF0 aW9ucy5vcGVucGdwanMub3Jn3gAFhK9m/KIFiN55VTWVgBYhBAGFytdGt1Ef 10NhlD8a5Zt9ATpNAACU2w/+Iqe4nHRpaaetbP8/b1MgyWQgQSvPwOPRDXsJ wSPMuPQ3mcYqeWLc8Ey+1KiRqJlwpulQrJjVnp5f7VPD7rjVLAiXNX5CdtCK HMFWhy+u0o5z3jbp9+m69RGoTUdXvIlYoWv0A1c4bJjv9l84mIokM+jzoi+8 zNQ+riSta8rB/jSy6nNYAxphz5IHwVUtXjMYpo4mX85EODtonrXoU91QoxVb yaohTWUcRySubzYVH4GGeUbV7KPMBjC4aJZo85+WzFDMbdNeBiYUwfQZ8hQG eVP1WP2KkwfyiZBFnXmhvu6ROLX0tgzy+q2WA6/DmD7XMJxauKkjzkrdzm/j aYd0NZYhn2NDbBppgd0ICNxpE7Gv9GPmhZotbXkaQrGyz4bBRNmGuaolL1Ec PSlJSMZgCpfdpyZV8nOJRdP+hao7q9NArZRv6v3mdRceZ5jJhcQEk7gTlTJ7 ojUiMy3RAQsiALwVDSPyPUoWZah8uPuDak+L6eAxiuc/DKsUhrXx1vY+5M1q zTNUr0EWXDTFKiP6XC6yd6/iXjQSwbwqIUy6pbp/eP5d0jTpjqiyihI6b8SH XzoWv2jNGZBYL4OjI9DhsAD0SbT1dyG7AkXvZqnZZnaWIkDGpwnOjDyp3Uz7 zvZHJIHdN9fkj/Q0m440hoAGZEadsa+Q86ztB5T5UD4a7Yk= =a9uU -----END PGP SIGNATURE-----
publickey - [email protected] - 0x0185CAD7.asc
Description: application/pgp-keys
publickey - [email protected] - 0x0185CAD7.asc.sig
Description: PGP signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
