On Sat, Nov 1, 2025 at 6:05 AM IETF Chair <[email protected]> wrote:
> Hi Dr. Bernstein!
>
> The IESG response to your appeal can be found at
> https://datatracker.ietf.org/group/iesg/appeals/artifact/220
The IESG has requested that I evaluate the WG Adoption call
results for ML-KEM Post-Quantum Key Agreement for TLS 1.3
(draft-connolly-tls-mlkem-key-agreement). Please see below.
ExecSum
-------
I agree with the TLS WG Chairs that the Adoption Call result
was that there was rough consensus to adopt the document.
Timeline
--------
April 1: Sean and Joe announce WG Adoption Call
[ about 40 messages sent in the thread ]
April 15: Sean announces the Adoption Call passed.
[ another 50 messages are sent in the thread ]
April 18 to today: A chain of (attempted) Appeals by D. J. Bernstein to the
AD(s), IESG and IAB, parts of which are still in process.
Outcome
-------
30 people participated in the consensus call, 23 were in favour of
adoption, 6 against and 1 ambivalent (names included at the bottom of
this email).
In favour argument summary
While there is a lack of substantiating why adoption is desired - which
is typical - the big use case seems to be to support those parties relying
on NIST and FIPS for their security requirements. This encompasses much
more than just the US government as other certification bodies and other
national governments have come to rely on the outcome of the NIST
competition,
which was the only public multi-year post-quantum cryptography effort
to evaluate the security of proposed new post-quantum algorithms. It
was also argued pure PQ has less complexity.
Opposed argument summary
Most of the arguments against adoption are focused on the fact
that a failsafe is better than no failsafe, irrespective of which
post-quantum algorithm is used, and that the practical costs for hybrids
are negligible. It was also argued that having an RFC gives too much
promotion or sense of approval to a not recommended algorithm.
I have expanded some of the arguments and my interpretation
of the weight of these below.
Non-hybrid as "basic flaw"
The argument by some opponents that non-hybrids are a "basic flaw" seems
to miscategorize what a "basic flaw" is. There is currently no known
"basic flaw" against MLKEM. As was raised, it is rather odd to be
arguing we must immediately move to use post-quantum algorithms while
at the same time argue these might contain fundamental basic flaws.
As TLS (or IETF) is not phasing out all non-hybrid classics, I find
this argument not strong enough to override the consensus of allowing
non-hybrid standards from being defined, especially in light of the
strong consensus for marking these as "not recommended".
Non-hybrids are a future end goal
Additionally, since if/when we do end up in an era with a CRQC, we are
ultimately designing for a world where the classic components offer less
to no value. When and where to exactly draw the line of still using a
classic
component safeguard is speculation at best. Already supporting pure post
quantum algorithms now to gain experience while not recommending it at this
time seems a valid strategy for the future, allowing people and
organizations
their own timeline of deciding when/if to go from hybrid to pure PQ.
Added complexity of hybrids
There was some discussion on whether or not hybrids add more complexity, and
thus add risk, compared to non-hybrids. While arguments were made that
proper
classic algorithms add only a trivial amount of extra resources, it was also
pointed out that there is a cost of implementation, deployment and
maintenance.
Additionally, the existence of draft-ietf-tls-hybrid-design and the
extensive
discussions around "chempat" vs "xwing" vs "kitchensink" shows that there is
at least some complexity that is added by the hybrid solutions.
RFCs being interpreted as IETF recommendation
It seems there is disagreement about whether the existence of an RFC
itself qualifies as the IETF defacto "recommending" this in the view
of IETF outsiders/ implemeners whom do not take into account
any IANA registry RECOMMENDED setting or the Mandatory-To-Implement
(MTI) reommendations. This is an area where we recently found out there
is little consensus on an IETF wide crypto policy statement via an
RFC. The decision on whether an RFC adds value to a Code Point should
therefor be taken independently of any such notion of how outsiders might
interpret the existence of an RFC. In this case, while Section 3 could be
considered informative, I believe Section 4 and Section 5 are useful
(normative)
content that assists implementers. And people have proposed extending the
Security Considerations to more clearly state that this algorithm is not
recommended at this point in time. Without an RFC, these recommendations
cannot be published by the IETF in a way that implementers would be known
to consume.
Say no to Nation State algorithms
The history and birth of MLKEM from Kyber through a competition of the
international Cryptographic Community, organized through US NIST can
hardly be called or compared to unilateral dictated nation state algorithm
selection. There has been no other comparable public effort to gather
cryptographers and publicly discuss post-quantum crypto candidates in a
multi-years effort. In fact, other nation states are heavily relying on the
results produced by this competition. The use of MLKEM in the IETF will
not set a precedent for having to accept other nation state cryptography.
Not recommending pure PQ right now
There was a strong consensus that pure PQ should not be recommended at
this time, which is reflected in the document. There was some discussion
on RECOMMENDED N vs D, which is something that can be discussed in the
WG during the document's lifecycle before WGLC. It was further argued
that adopting and publishing this document gives the WG control over
the accompanying warning text, such as Security Considerations, that
can reflect the current consensus of not recommending pure MLKEM over
hybrid at publication time.
Conclusion
----------
The pure MLKEM code points exist. An international market segment that
wants to use pure MLKEM exists as can be seen by the consensus call
outcome along with existing implementations of the draft on mainstream
devices and software. There is a rough consensus to adopt the document
with a strong consensus for RECOMMENDED N and not MTI, which is
reflected in the draft. The reasons to not publish MLKEM as an RFC seem
more based on personal opinions of risk and trust not shared amongst all
participants as facts.
Based on the above, I believe the WG Chairs made the correct call that
there was rough consensus for adopting
draft-connolly-tls-mlkem-key-agreement
Paul Wouters
Security Area Director
Appendix
--------
Pro Adoption (23):
* Alicja Kario
* Andrei Popov
* David Adrian
* Filippo Valsorda
* Flo D
* Jan Schaumann
* John Mattson
* Joseph Birr-Pixton
* Kris Kwiatkowski
* Loganaden Velvindron
* Martin Thomson
* Quynh Dang
* Rebecca Guthrie
* Russ Housley
* Scott Fluhrer
* Sophie Schmieg
* Thom Wiggers
* Tirumal Reddy
* Uri Blumenthal
* Viktor Dukhovni
* Yaakov Stein
* Yaroslav Rosomakho
* Deirdre Connolly (author)
Against Adoption (6):
* Andrey Jivsov
* D. J. Bernstein
* Rich Salz
* Rob Sayre
* Stephen Farrell
* Sun Shuzhou
Ambivalent (1)
* Thomas Bellebaum (prefer not, but okay if we do)
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
