Hi Deirdre, You are correct. The quote I attributed to the Motivation section is not the text in -07. I apologize for the error; I was looking at multiple draft versions.
The actual Motivation text names three use cases: regulatory frameworks requiring standalone post-quantum key establishment, smaller key sizes or less computation, and simplicity. My underlying concern applies to each of these: these claims do not in my view constitute motivation for removing compositional security. A hybrid construction is already simpler than many TLS 1.3 configurations in production, and the performance delta between an ML-KEM-only and ECDHE+ML-KEM handshake does not approach the threshold that would justify discarding a well-analyzed security property. The remaining points in my objection stand. Nadim Kobeissi Symbolic Software • https://symbolic.software > On 21 Feb 2026, at 5:54 PM, Deirdre Connolly <[email protected]> wrote: > > > The Motivation section of -07 states that pure ML-KEM key establishment > is "necessary for migrating beyond hybrids and for users that want or > need post-quantum security without hybrids." > > This is not the text in -07 nor the text on #main on GitHub including > feedback from this call. This is the current text of the Motivation section: > > https://www.ietf.org/archive/id/draft-ietf-tls-mlkem-07.html#section-1.1 > > "FIPS 203 (ML-KEM) [FIPS203] is a FIPS standard for post-quantum [RFC9794] > key establishment via a lattice-based key encapsulation mechanism (KEM). This > document defines key establishment options for TLS 1.3 that use solely > post-quantum algorithms, without a hybrid construction that also includes a > traditional cryptographic algorithm. Use cases include regulatory frameworks > that require standalone post-quantum key establishment, targeting smaller key > sizes or less computation, and simplicity." > > On Sat, Feb 21, 2026, 11:23 AM Nadim Kobeissi <[email protected]> wrote: >> Hi everyone, >> >> Following the exchanges since my initial objection and after some >> additional appraisal of the situation, I am writing to set out a fuller >> objection to the publication of draft-ietf-tls-mlkem-07. I ask the >> chairs to treat this as a blocking objection and to reflect it >> accurately in any consensus call summary. >> >> I want to state my position plainly. I do not believe this document >> should be published. A pure post-quantum key establishment option for >> TLS 1.3 discards compositional security under component compromise -- a >> property deliberately designed into TLS 1.3 that has served the deployed >> Internet well -- and the document identifies no concrete benefit gained >> in exchange. The hybrid constructions already adopted by this working >> group provide post-quantum security while retaining that compositional >> guarantee. This document proposes to remove that guarantee, and I have >> yet to see a justification for doing so that withstands scrutiny. >> >> My background in formal verification of the TLS 1.3 key schedule -- >> including co-authoring verified models that contributed directly to TLS >> 1.3's standardization (Bhargavan, Blanchet, Kobeissi, IEEE S&P 2017, DOI >> 10.1109/SP.2017.26) -- informs the specific concerns I set out below. >> >> --- >> >> 1. THE DOCUMENT'S MOTIVATION IS CIRCULAR >> >> The Motivation section of -07 states that pure ML-KEM key establishment >> is "necessary for migrating beyond hybrids and for users that want or >> need post-quantum security without hybrids." >> >> This is circular: it asserts that pure PQ key establishment is needed by >> those who want pure PQ key establishment. The section does not identify >> any deployment scenario in which a hybrid construction is technically >> infeasible, any security property gained by removing the classical >> component, or any basis for concluding that the time for "migrating >> beyond hybrids" has arrived. >> >> The compositional security argument for hybrid constructions is >> well-established: a hybrid key establishment scheme is secure if either >> component is secure. ML-KEM is relatively young as a standardized >> primitive; its mathematical hardness assumptions are less studied than >> those underlying established elliptic curve constructions. The world's >> Internet has been running TLS 1.3 with hybrid constructions for years, >> providing post-quantum security via ML-KEM while retaining higher >> assurance against classical attacks via ECC. Removing the classical >> component of this working arrangement discards a concrete security >> guarantee for no identified gain. >> >> One would expect that disrupting a functioning, well-analyzed status quo >> would require exceptional motivation. The document does not provide one, >> and none has been offered in discussion despite my repeated requests. I >> cannot support publication of a standard that removes a security >> property without justification. >> >> --- >> >> 2. THE FATT PROCESS HAS NOT BEEN COMPLETED >> >> The FATT charter (https://github.com/tlswg/tls-fatt) states: >> >> "A proposal that modifies the TLS key schedule or the authentication >> process or any other part of the cryptographic protocol that has been >> formally modeled and analyzed in the past would likely result in asking >> the FATT." >> >> This document introduces pure ML-KEM as a NamedGroup, substituting the >> ML-KEM shared_secret into the TLS 1.3 key schedule in place of the >> (EC)DHE shared secret (Section 4.3, Figure 1). That substitution >> directly affects a component of the TLS 1.3 key schedule that has been >> formally modeled and analyzed, including in: >> >> - Bhargavan, Blanchet, Kobeissi, "Verified Models and Reference >> Implementations for the TLS 1.3 Standard Candidate," IEEE S&P 2017, DOI >> 10.1109/SP.2017.26. >> >> - Dowling, Fischlin, Gunther, Stebila, "A Cryptographic Analysis of >> the TLS 1.3 Handshake Protocol," Journal of Cryptology, 2021, DOI >> 10.1007/s00145-021-09384-1 (cited in the draft as [DOWLING]). >> >> The prior analyses modeled the (EC)DHE input as a freshly generated >> ephemeral value. My own 2017 work explicitly modeled TLS 1.3 client key >> shares as ephemeral. As Muhammad Usama Sardar noted on this list on >> February 20, and as John Mattsson confirmed, this draft introduces a >> materially different assumption: Section 5.3 of -07 explicitly permits >> ML-KEM key share reuse. >> >> From direct knowledge of the 2017 proof, I can confirm that its >> security arguments do not straightforwardly extend to a static key share >> case. The proof relies on the ephemerality of client key shares at a >> structural level. Substituting a potentially reused ML-KEM encapsulation >> key for a fresh ephemeral (EC)DHE value changes the adversarial model >> the proof operates under. >> >> Under the FATT charter, the chairs were expected to determine whether >> FATT review was warranted at adoption time. I have been unable to find a >> public record that FATT was engaged for this document: there is no FATT >> point person named in the FATT repository, and no FATT assessment >> appears in the shepherd write-up (which shows no shepherd assigned). >> >> I would appreciate it if the chairs could clarify on the record whether >> FATT triage was initiated and, if so, what the outcome was. This is a >> straightforward process question, and answering it would help the >> working group understand whether this document has received the formal >> analysis review that our own processes call for. >> >> --- >> >> 3. THE KEY REUSE LANGUAGE CONTAINS ERRORS AND CONFLICTS WITH NIST SP 800-227 >> >> Section 5.3 of -07 states: >> >> "While it is recommended that implementations avoid reuse of ML-KEM >> keypairs to ensure forward secrecy, implementations that do reuse MUST >> ensure that the number of reuses abides by bounds in [FIPS203] or >> subsequent security analyses of ML-KEM." >> >> This language has two concrete problems. >> >> First, FIPS 203 does not define a reuse bound. FIPS 203 specifies the >> ML-KEM algorithm; for usage guidance, it explicitly directs implementers >> to SP 800-227. SP 800-227 is normatively cited in -07 as >> [NIST-SP-800-227]. Section 5.3's invocation of "bounds in [FIPS203]" >> attributes guidance to a document that does not contain it. This is a >> factual error in normative text, verifiable by anyone who reads the >> cited document. >> >> Second, SP 800-227 (September 2025) states: >> >> "If an application uses an ephemeral key pair, the key pair shall be >> used for only one execution of key-establishment via a KEM and shall be >> destroyed as soon as possible after its use." >> >> SP 800-227 distinguishes sharply between ephemeral keys, which are >> single-use and must be destroyed, and static keys, which are reusable >> but subject to additional authentication and key management requirements >> including proof of possession. The draft simultaneously recommends >> against reuse and permits it, with a MUST qualifier pointing to a bound >> that does not exist in the cited document. The result is a normative >> contradiction that implementers cannot resolve by reading the documents >> cited. >> >> The security consequences of key reuse in deployed TLS go beyond the >> IND-CCA property of ML-KEM in isolation. IND-CCA is a primitive-level >> property; it does not guarantee forward secrecy, resistance to traffic >> analysis based on linkability of reused encapsulation keys, or >> compliance with SP 800-227's additional requirements for static-key >> deployments. The draft addresses none of these protocol-level concerns. >> >> John Mattsson raised this point on February 12 and proposed removing all >> key reuse text as the condition for his support. The changes in -07 >> addressed his concern only partially and did not correct the FIPS 203 >> citation. >> >> --- >> >> 4. THE FRAMING OF THIS SECOND WGLC DOES NOT ACCURATELY REFLECT THE FIRST >> WGLC'S CONCLUSION >> >> Paul Wouters's message of February 20, sent in his capacity as AD, >> describes the first WGLC as follows: >> >> "We already had a WGLC on this document [1] and the conclusion [2] >> was that it passed WGLC provided some clarifying text would be >> added that stated that for the general use case, hybrids were >> preferred." >> >> This description does not match the conclusion it cites. The conclusion >> of the first WGLC, as recorded by Joseph Salowey on December 8, 2025 in >> the very message Wouters cites as [2], reads: >> >> "The working group last call for pure ML-KEM has concluded, thanks >> to those that participated in the discussion. In summary, we do not >> have consensus to publish the document as is. [...] Given this, the >> chairs will move the document back to the 'WG Document' state and >> ask the author to work on resolving the issues brought up on the >> list including text to address concerns that there are reasons to >> prefer hybrid over the pure approach. The chairs will then redo a >> working group last call to see if there is rough consensus for >> publishing this document." >> >> [2]: https://mailarchive.ietf.org/arch/msg/tls/Gc6KVPrVHn-QCkeEcvJ_qtRcFxY/ >> >> The recorded conclusion is an explicit finding of no consensus to >> publish, with the document returned to WG Document state. Anyone can >> read [2] and compare. Describing this outcome as the document having >> "passed WGLC" is not a paraphrase; it reverses the recorded finding. >> This matters because the framing of this second WGLC as a narrow >> confirmatory step depends on that characterization. If the first WGLC >> found no consensus -- as [2] explicitly records -- then this second WGLC >> is properly a fresh determination of rough consensus, not a check on >> whether added text satisfies conditional supporters. >> >> Per RFC 2418 Section 7.4, a working group last call determines rough >> consensus across the working group as a whole. The first WGLC generated >> substantive objections from multiple participants -- including D.J. >> Bernstein, Stephen Farrell, Rich Salz, Simon Josefsson, and myself -- >> that have not been resolved by the revisions in -07. The conclusion of >> the first WGLC is itself under active appeal at the IESG >> (https://datatracker.ietf.org/group/iesg/appeals/artifact/230). I would >> ask the chairs to clarify how the interaction between that pending >> appeal and this second WGLC is being handled. >> >> --- >> >> 5. SCOPE OF THIS OBJECTION >> >> I note the AD's guidance that this second WGLC is directed at assessing >> whether the revisions in -07 address concerns raised in the first WGLC. >> My response to that framing is twofold. >> >> First, several of the concerns I raise above are specific to the -07 >> text itself: the FIPS 203 citation error, the SP 800-227 conflict, and >> the absence of FATT review are all concerns that arise from -- or remain >> unaddressed by -- the current revision. These are squarely within scope >> of any reading of this WGLC's purpose. >> >> Second, the substantive objections from the first WGLC that were not >> resolved by -07 do not lapse because a second WGLC has been called. The >> revisions did not address the absence of a concrete motivation for >> removing the classical component, did not initiate FATT review, did not >> correct the FIPS 203 citation, and did not resolve the tension with SP >> 800-227. These objections remain open. >> >> I ask the chairs to confirm that this objection has been received, that >> it will be reflected in the consensus call summary, and that the pending >> IESG appeal of the first WGLC's conclusion will be resolved before this >> document advances. >> >> Nadim Kobeissi >> Symbolic Software • https://symbolic.software <https://symbolic.software/> >> >> On 2/21/26 11:28 AM, Nadim Kobeissi wrote: >> > Hi Paul, >> > >> > You write: >> > >> >> We already had a WGLC on this document [1] and the conclusion [2] was >> >> that it passed WGLC provided some clarifying text would be added that >> >> stated that for the general use case, hybrids were preferred. >> > >> > I just had a look at [2] and to my surprise, it didn’t seem to match >> > your description. What [2] seems to show was that the chairs decided >> > that there was no consensus. Quoting: >> > >> > > The working group last call for pure ML-KEM has concluded, thanks to >> > those >> > > that participated in the discussion. In summary, we do not have >> > consensus >> > > to publish the document as is. >> > > […] >> > > Given this, the chairs will move the document back to the "WG Document" >> > > state and ask the author to work on resolving the issues brought up >> > on the >> > > list including text to address concerns that there are reasons to prefer >> > > hybrid over the pure approach. The chairs will then redo a working group >> > > last call to see if there is rough consensus for publishing this >> > document. >> > >> > I am very confused. You say that [2] showed that it passed WGLC provided >> > that some clarifying text would be added. Absolutely none of this is >> > reflected in [2]. Instead, what [2] shows is an explicit admission of >> > the lack of any consensus to publish the document, and the document >> > being moved back to a “WG Document” state. >> > >> > Could you please clarify this rather large discrepancy between your >> > description of [2] and what [2] actually appears to say? >> > >> > Thank you, >> > >> > [2] https://mailarchive.ietf.org/arch/msg/tls/Gc6KVPrVHn-QCkeEcvJ_qtRcFxY/ >> > >> > Nadim Kobeissi >> > Symbolic Software • https://symbolic.software <https://symbolic.software/> >> > >> >> On 20 Feb 2026, at 4:00 PM, Paul Wouters >> >> <[email protected] <mailto:[email protected]>> >> >> wrote: >> >> >> >> >> >> [ AD hat on ] >> >> >> >> All, >> >> >> >> I want to remind people that the goal of this 2nd WGLC is to focus on >> >> the new text changed in responds to the conclusion of the 1st WGLC. >> >> >> >> We already had a WGLC on this document [1] and the conclusion [2] was >> >> that it passed WGLC provided some clarifying text would be added that >> >> stated that for the general use case, hybrids were preferred. This >> >> 2nd WGLC is about that topic. >> >> >> >> There is an appeal chain that got muddled by the inappropriate use of >> >> derivative clauses that is still in progress, but so far yielded the AD >> >> statement [3] that confirmed the WG Chairs view that the consensus call >> >> passed. There is an appeal with the IESG [4] on that decision, and this >> >> document will not be placed in the RFC Editor queue until that appeal has >> >> concluded, but will also not stop all processing while the appeal runs. >> >> >> >> This 2nd WGLC is meant to get those people who provisionally said "yes" >> >> to publication of this document pending some extra text, to review this >> >> text and let us know if that resolves the conditional part of their >> >> "yes" statement. The text changes to discuss can be seen at: >> >> >> >> https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls- >> >> mlkem-05&url2=draft-ietf-tls-mlkem-07&difftype=--html >> >> >> >> >> >> I understand this is a heated topic. I am also not hearing from people >> >> that they have changed their opinion on whether or not to publish this >> >> document at all. Confirming your views are fine, but again, that is not >> >> the goal of this 2nd WGLC. It would be helpful if, especially those >> >> people who wanted additional clarifying text, to give us feedback on >> >> this. And ideally, offer up suggestions that would address any still >> >> outstanding issues. >> >> >> >> Thanks, >> >> >> >> Paul >> >> >> >> [1] https://mailarchive.ietf.org/arch/msg/tls/Pzdox1sDDG36q19PWDVPghsiyXA/ >> >> [2] https://mailarchive.ietf.org/arch/msg/tls/Gc6KVPrVHn-QCkeEcvJ_qtRcFxY/ >> >> [3] https://mailarchive.ietf.org/arch/msg/tls/dzPT8KQe4S-_pZROLUJMvS9pM0M/ >> >> [4] https://datatracker.ietf.org/group/iesg/appeals/artifact/230 >> >> >> >> _______________________________________________ >> >> TLS mailing list -- [email protected] <mailto:[email protected]> >> >> To unsubscribe send an email to [email protected] >> >> <mailto:[email protected]> >> > >> >> _______________________________________________ >> TLS mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
