I very much dislike this definition of "participant" and the assumption that
those who don't speak up are in agreement. I've been a participant for more
than 10 years and I strongly object to the publication. I stayed quiet the last
rounds and I'm already bracing for impact of what YouTube links and weird
messages I'll get this time round, but that does not mean that I approve of the
document, or even want publication. The AD or chairs cannot make assumptions
about the attitudes of people who do not state them.
I think it is irresponsible of the WG to publish an RFC that encourages risky
behavior. Users will take the reputation of the IETF and understand this as a
recommendation, whether it says = N or not. As much as I like PQC and push for
its adoption asap because we're too late (not my fault), I also warn about
stability and code quality and we must acknowledge that. I love formally
verified software like everybody else and it's the best we can do, but also
that is still a research area and we are currently in a situation where code
can be formally verified and have bugs at the same time. That's not even
addressing the mathematical stability of the problems. Still, it's better to
add ML-KEM than not deploying it, but please not without ECC. I can't stop
people from shooting themselves in the foot but I don't want the WG to cause
this.
If I understand the email from Keegan correctly then we have a perfect example
of the damage that this RFC can be causing as the Canadian government seems to
be waiting for this RFC in order to recommend ditching hybrids in favor of
fully exposed PQC. It's not hypothetical that people would ignore the = N, we
have a stated intention on list. [And before I get the mansplaining: yes, I'm
aware of the CA publication already including the option for exposed PQC. I'm
also aware that that document has been referenced as motivation for the draft
(though sold as regulation there). What was interesting to me from the email
was that it sounds like this becoming an RFC carries more weight for them and
will impact ther recommendations. That would then be our fault.]
All the best
Tanja
On Wed, Feb 25, 2026 at 07:00:55PM +0100, Nadim Kobeissi wrote:
> I'm encountering some concerning conduct from the AD regarding my blocking
> objection.
>
> I've so far continued to receive off-list emails from the AD despite repeated
> explicit requests that they stop emailing me off-list and acknowledge my
> objection on-list, as well as address their inaccurate summary of [2].
>
> The explanation provided by the AD to me (off-list, despite my explicit lack
> of consent) amounted to the following:
>
> > The largest number of participants wanted to publish the document as is,
> > however there was also a significant number that wanted changes to the
> > document before publication and a small, but vocal, number of participants
> > that do not want the document to be published at all.
> >
> > where: largest > significant > small but vocal
> >
> > and: (largest + significant) / (largest + significant + small but vocal) ==
> > rough consensus
>
> I don't know why they insisted on sending this explanation off-list, but I'm
> sorry to say that it makes no sense. [2] clearly states:
>
> > In summary, we do not have consensus to publish the document as is. [...]
> > The chairs will then redo a working group last call to see if there is
> > rough consensus for publishing this document.
>
> I am a bit disturbed to see that the AD resorted to sending me strange
> justifications for their interpretation of [2] despite it clearly stating
> that "In summary, we do not have consensus to publish the document as is.
> [...] The chairs will then redo a working group last call to see if there is
> rough consensus for publishing this document."
>
> I encourage more transparent behavior from this WG, and for the issues I
> raise to be treated in a more transparent manner.
>
> [2] https://mailarchive.ietf.org/arch/msg/tls/Gc6KVPrVHn-QCkeEcvJ_qtRcFxY/
>
> On Wed, Feb 25, 2026, at 12:56 PM, Nadim Kobeissi wrote:
> > Hi everyone,
> >
> > Despite emails sent from the AD on this list (and to me off-list), I still
> > don't see any acknowledgment regarding this blocking objection submission,
> > despite my request for one.
> >
> > I would appreciate it if the ADs could address my points on the record.
> > Point
> > 4, especially, is to me quite concerning, and according to my judgement
> > deserves an explanation.
> >
> > Thank you,
> >
> > On Saturday, February 21, 2026 5:23:29 PM Central European Standard Time
> > Nadim
> > Kobeissi 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]
> >
> >
> >
> > Nadim Kobeissi
> > Symbolic Software • https://symbolic.software
> >
> >
> > _______________________________________________
> > TLS mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
>
> --
> Nadim Kobeissi
> Symbolic Software • https://symbolic.software
>
> _______________________________________________
> 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]
