> 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 <nadim@symbolic.software>
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
> >> <paul=40nohats.ca@dmarc.ietf.org> 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 -- tls@ietf.org
> >> To unsubscribe send an email to tls-leave@ietf.org
> >
>
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>