[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)

[Nadim Kobeissi <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 
>> >> <paul=[e-mail] <mailto:[e-mail]>> 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 -- [e-mail] <mailto:[e-mail]>
>> >> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
>> > 
>> 
>> _______________________________________________
>> TLS mailing list -- [e-mail] <mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>