> 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 > > 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 > > > >> On 20 Feb 2026, at 4:00 PM, Paul Wouters > >> <[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] > >> To unsubscribe send an email to [email protected] > > > > _______________________________________________ > 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]
