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]
