I oppose publication of this draft as it currently stands.
We have a much larger corpus of information available that would be
quite relevant to the security section of this draft, yet almost
nothing is present to help inform the target audience despite noting
that "Implementers must evaluate their specific security, performance,
and operational constraints when deciding whether to deploy standalone
ML-KEM or a hybrid construction." Besides the reference to
NIST-SP-800-227, no further references on how to make this evaluation
are supplied, and that one doesn't cover the topics I bring up below.
This is a fundamental problem given how many informative references
are dedicated to promoting security bounds (looks like eight as of
draft-08.) Most of these are of minimal value to real-world
implementers; additional practical references would significantly
improve this situation. I cite a handful below, with some key quotes
from these documents; sufficient care should be taken to include
enough variety to assist the implementers making this decision with
practical information on how each listed criteria can be evaluated.
I do agree with some discussion in recent months that practical PQC
standards for TLS should be formalized, but the focus on standalone
ML-KEM as the current timely action-item seems counter to real-world
deployments [1]. Some have cited the need for advancing this current
draft to RFC: we have a draft for what the overwhelming majority of
practical TLS 1.3 servers & clients should be moving to, namely
draft-ietf-tls-ecdhe-mlkem. I do not understand the focus on
standalone ML-KEM when the clear use-case for PQC in TLS has for years
been hybrid designs, as shown by current actual use of PQ-ready
connections in TLS.
So what concrete things am I suggesting to change in this document?
Several suggestions are grouped below. Each may deserve its own future
thread on this list if there is interest in correcting these
fundamental problems. I'm strongly in favor of a pause in continued
last-calls to allow earnest discussion in the following areas:
First, pair down the eight references at the start of section 5
("Security Considerations") to the minimal set necessary. A sufficient
number of practical references and should be added to evaluate the
crucial security, performance, and operational constraints we're
asking implementers to review. Footnotes should be supplied to make
clear which evaluation criteria they apply to and offer practical
guidance.
Second, it appears no mention of the risks [3][4] implementers are
asked to weigh given a gap in ML-KEM's security could result in no
safety at all. This is a rather notable omission given that this
entire standard relies strictly on the lack of future breakthroughs.
This is even visible in another NIST document this past winter [5]
regarding Mosca's theorem; by applying this concept to the risk ML-KEM
is not as robust as required, we end up with what RFC9958 [6] terms
"harvest now, decrypt now", which exposes standalone ML-KEM users to
earlier data exposure, during a situation where ML-KEM is unsafe while
EC remains safe. We've seen this happen before [7], so this is more
than just a hypothetical.
Third, there seems to be no mention about the performance
implications, either in favor of standalone ML-KEM or evaluating
possible regression (a net-loss of performance,) which could be caused
by use of dual PQ-ready keyshares in a TLS handshake or costs of HRR
[2]. The current wording of the draft gives the implication a
significant reason to choose standalone ML-KEM is as a performance
boost, but some literature does not seem to suggest this has much
significant impact at all [8].
In combination, access to the above information may leave many
implementers wondering what benefit ML-KEM offers over hybrid
ML-KEM+EC if the former in practice has minimal-to-zero performance
improvement and risks complete prior session exposure if ML-KEM falls,
due to either spec or implementation flaws in younger, less-reviewed
new code. This would be a very reasonable question to ask, but without
the critical material to properly evaluate what implementers are asked
to do (indeed, the term used is what they "must" do) the current
wording puts the burden of tracking down a corpus of documents such as
cited in this opposition to every implementer.
If these issues are all suitably addressed with significant attention
to presenting correct and current information, I could move to a
neutral position on advancing this draft. Given its fundamental lack
of suitable information on these topics combined with asking
implementers to evaluate such criteria, I maintain my opposition
unless and until these can be addressed.
References:
[1] Cloudflare, "State of the post-quantum Internet in 2025"
https://blog.cloudflare.com/pq-2025
[2] Cloudflare
https://blog.cloudflare.com/post-quantum-to-origins
on keyshare size, "[an extra keyshare] becomes more problematic when
we want to send two post-quantum keyshares, as post-quantum keyshares
are much larger."
[3] NIST, IR-8545 "Status Report on 4th Round PQC Process"
https://csrc.nist.gov/pubs/ir/8545/final
"[..] NIST values having a variety of computational hardness
assumptions and aims to reduce the risk that a single cryptanalytic
breakthrough will leave no viable standard for key establishment."
[4] NIST, "NIST Selects HQC"
https://www.nist.gov/news-events/news/2025/03/nist-selects-hqc-fifth-algorithm-post-quantum-encryption
"HQC is based on different math than ML-KEM, which could be important
if a weakness were discovered in ML-KEM."
and, "it's essential to have a fallback in case ML-KEM proves to be
vulnerable" (quoting Dustin Moody)
[5] NIST, IR-8547, "Transition to PQC"
https://csrc.nist.gov/pubs/ir/8547/ipd
[6] RFC9958, "PQC for Engineers"
https://datatracker.ietf.org/doc/rfc9958
Sec. 13: "neither the traditional algorithms nor the post-quantum
algorithms are fully trusted to protect data for the required
lifetimes."
Sec. 13.1: "If the PQ portion were to have a flaw, [a PQ/T hybrid]
prevents immediate decryption ('harvest now, decrypt now')."
[7] Cloudflare, "The TLS Post-Quantum Experiment"
https://blog.cloudflare.com/the-tls-post-quantum-experiment
[8] "Layered Performance Analysis of TLS 1.3 Handshakes"
https://arxiv.org/pdf/2603.11006v1
--
Josh Cepek
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
