People seem to keep forgetting (or ignoring) the whole purpose of the PQ. If your data won’t remain sensitive by the time CRQC arrives - you don’t en need a hybrid. Just use your Classic ECC, experiment with PQ or not, and prepare for eventual transition at some point in the future.
If your data will remain sensitive - then the difference between “it got compromised today” and “it got compromised with CRQC” is small, and ECC won’t help at all. — Regards, Uri Secure Resilient Systems and Technologies MIT Lincoln Laboratory > On Jun 30, 2026, at 16:59, Bertrand Jacquin > <[email protected]> wrote: > > Joseph, WG, > > I have read draft-ietf-tls-mlkem-08. For the record: I do not > support publication of a standards-track document specifying > standalone ML-KEM key establishment for TLS 1.3. > > Standalone removes the only classical hedge, and that is the wrong > default for TLS. Standalone ML-KEM is secure only if ML-KEM holds, > forever, against both classical and quantum cryptanalysis and against > implementation flaws in the field. The entire reason to deploy PQC in > TLS now, ahead of a cryptographically relevant quantum computer, is > harvest-now-decrypt- later. That threat model justifies adding a PQ KEM; > it never justifies removing the classical one. A hybrid such as > X25519MLKEM768 is secure if either component holds. > > The proposal s a large bet on a young primitive. FIPS 203 was finalized > in 2024; lattice KEM cryptanalysis is far less mature than the decades > behind X25519 and the NIST P-curves. We have recent reminders that > "post-quantum" does not mean "safe": the 2022 classical break of SIKE > (Castryck-Decru) destroyed a scheme that had survived years of NIST > scrutiny, and the KyberSlash timing side channels (2023-2024) showed > that even reference ML-KEM code shipped exploitable secret- dependent > behaviour. None of this says ML-KEM is broken. It says betting the > confidentiality of the Internet's most important security protocol on a > single new primitive, with no fallback, is imprudent when the fallback > costs almost nothing. > > And it does cost almost nothing. The classical half of the hybrid is 32 > bytes and one X25519 scalar multiplication, lost in the noise next to > ML-KEM-768's ~1.1 KB public key and ciphertext. There is no performance > case for dropping it. The tradeoff is trivial cost against catastrophic, > retroactive downside. For TLS, that asymmetry alone settles it. > > If the WG's clear, registered preference is hybrid, and the draft's own > Security Considerations now point at the registry to say so, then we are > about to publish a standards-track specification whose own text tells > you to prefer something else. That is self-undermining. The honest > outcome of a "hybrid preferred" consensus is to not ship a > standards-track standalone spec at all. > > Key-share reuse changed to MUST NOT in rfc8446bis. Welcome, but > orthogonal. It resolves static-key reuse, forward secrecy and a privacy > concern. It does nothing about the absence of a classical hedge, which > is the actual objection. Citing it here is a non sequitur. > > Once code points are standardized and implemented, they get enabled. > The recommendation column is advisory and is routinely overridden by > compliance mandates and procurement checklists. A WG standards-track RFC > confers exactly the legitimacy and momentum that drive deployment. "We > standardized it but marked it not recommended" is not protection; it is > a downgrade and foot-gun surface that we are choosing to create. > > Cheers, > Bertrand > >> On Wednesday, June 24 2026 at 08:00:07 -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 > > -- > Bertrand > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] > <signature.asc>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
