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
>