Mike,
I appreciate the comparison you're drawing, and while I can only
meaningfully answer for my stated concerns with the standalone ML-KEM,
I can point to the key differences I see between them. For the short
highlights, jump to each of the numbered labels below. My answers are
a bit long-winded, but given how important I think your comparison is,
I wanted to explore the reasoning in the hope you (and others) may
find it useful.
RFC9850 (SSLKEYLOGFILE) dedicates a good deal of the section on
security to not only explaining the broad risk (the hopefully obvious
one: allows session decryption) with key file access, but explains
exactly what surrounding information the TLS session may carry
including references to other standards documents.
Some readers new to the concept who are interested in using fairly
typical use-case such as curl + packet-viewer (tcpdump, Wireshark,
etc) may not have considered surrounding issues including exposure of
binding or application-specific payloads. Listing these adjacent areas
of impact allows an implementer to be aware and do any of:
a. accept the risk
b. read more about the risk to make an informed choice
c. reject the risk and alter the system they design or how its operated
That last point is not necessarily to avoid the interface, but might
include operating on dummy data so risk of sensitive content is
removed, or placing storage of key and/or capture material in a
stronger environment (filesystem, access controls, sandboxed OS).
These examples are meant to show how reasonable choices require that
initial understanding that one action (log the session key for payload
viewing) may unintentionally expose something not intended
(longer-lived application context sensitive long after the rest of the
payload.)
In RFC9850, enough prose and references are supplied that there it is
unlikely someone could make the choice and not be aware of the risk,
and can easily find further reading if it's required.
How about standalone ML-KEM as of draft-08? This looks very different
to me. I categorize these below with some explanation; more details
can be seen in my opposition reply earlier on-list.
1. No clear and direct statement of the issue.
For starters, the security section of solo ML-KEM is exceptionally
small by contrast. If there was a more obvious statement that didn't
require similar understanding I could understand that, but the choice
of standalone is probably wrong for most typical uses of TLS today;
this is why rollout is using the (also still draft) X25519MLKEM and
before that X25519Kyber768Draft00.
It's not like there's a lack of stated risk here, including by
multiple NIST documents (my earlier post cites several.) The risk that
ML-KEM is found to be weaker at (or broken) in the future or that an
implementation thereof has a flaw, may result in zero protection; this
means exposure of data then, and if EC remains unbroken, this has been
an avoidable exposure. Perhaps an implementer accepts that risk, but
not having stated it is already a clear problem if RFC9850 is the
comparison.
2. Disproportionate focus on solo ML-KEM analysis
For all the references (a group of 5, then 3 more a moment later) in
the current draft listing various security evaluations, only 1
(SP-800-227) is given under the Security section, and that one
primarily only mentions side-channels and mention of 'approved'
environments. There isn't a lack of suitable reference material or
reason to be very clear about loss of traditional protection.
Sure, this protection vanishes once CRQCs exist, but they don't today.
If a flawed implementation is used tomorrow, that's presumably years
of confidentiality that would be none at all.
Despite this lack of explanation, somehow the FO-Transform rejection
gets a citation (not referenced in a footnote) and this is really just
an internal primitive of ML-KEM; an implementer doesn't need to know
that to decide if solo or hybrid is reasonable any more than they need
to know the G, H & J functions are based on Keccak. Those who do need
this level of internal detail will find them in FIPS-203 already.
3. No mention of existing hedging on ML-KEM's long term viability
Sure, ML-KEM has lasted longer than SIKE. And SIKE lasted longer than
those knocked out earlier in the PQC competition. All algorithms shown
to have weaknesses aren't weakened until the issues are uncovered. And
implementations are much newer, and lots of new code in various forms
is naturally less mature. Some of it is very likely not used in a
'FIPS approved' method either (eg: libssl could be built with FIPS,
but often isn't in many real-world deployments: it's not "approved" in
the language of SP-800-227.)
NIST's own documents makes this clear (see citations in my earlier
list post) and we even have an upcoming PQ-safe KEM as an
alternative/backup now: HQC. We didn't do this with SHA1, or SHA2, or
SHA3, or AES, or P-{256,384,521}, so what makes ML-KEM different?
There is a focus on a backup to switch to (that's good, if we need it)
but ignores that this still exposes communication that would have
remained safe as long as EC is unbroken.
4. No mention of performance or operational concerns
The implementer is tasked with (the draft specifies "must") reviewing
security, performance, & operational concerns. Multiple academic
literature exists to quantify this, although this is still a somewhat
new area of academic interest. Micro-benchmarks and focus on how many
more CPU cycles or microseconds used are typically the wrong focus
anyway. If margins are that close for typical client/server TLS
use-cases, odds are good the wrong hardware is being used.
I'm willing to acknowledge that very specialized use-cases may exist
where the margins are so small that the risk of exposure if ML-KEM
falls (and we all scramble for one of the backups) is worth taking.
This is simply not going to be the case with the majority of cases,
and supplying clear reasons including noting the near-identical
high-level cost-envelopes for real-world servers supporting many
connections is very useful information. I'm effectively making the
argument that one should have to justify giving up the traditional
protection.
Note that this is not served by the =N recommendation the IANA
codepoint list. That's one piece of information, while we're asking
implementers to be aware of more nuance. RFC9850 gets this right; solo
ML-KEM should too.
5. Closing thoughts
To your point about "people are going to implement it anyway", sure,
but the goal should be to make sure they understand the landscape
fully while they do it. Other much less useful codepoints exist too,
such as 0x0016 (secp256k1.)
Ignoring the lack of PQC protection, would it be reasonable to assume
that someone has probably done this and that makes it OK to advance as
a formal RFC without mentioning the problems with this approach? Would
it be OK if this same curve was used with ML-KEM in a hybrid for TLS?
This particular curve may feel an absurd comparison to some, but
projects have seen requests for this kind of thing [1].
Guidance and messaging is important, and I really feel the current
information about solo ML-KEM doesn't supply anywhere near the kind of
practical detail and references RFC9850 does by contrast. Most of my
current opposition is centered around this.
Thanks again for the line of discussion & questions Mike; I hope to
read others' thoughtful responses to these as well.
References:
[1] OpenSSL GitHub Issue #15675
https://github.com/openssl/openssl/issues/15675
--
Josh
On Wed, Jul 8, 2026 at 8:12 AM Mike Shaver <[email protected]> wrote:
>
> (Apologies if this has been raised in the WGLC thread; I tried to catch up
> there, but there is...a lot.)
>
> I'm curious how the list feels about similarities between the decision to
> standardize SSLKEYLOGFILE and the choice ahead of the IETF regarding
> standalone ML-KEM.
>
> As I recall and understand the consensus, the decision was taken to specify
> SSLKEYLOGFILE (albeit as informational) was taken
>
> - in spite of the fact that SSLKEYLOGFILE can be used in ways that harm
> confidentiality
> - because people are going to implement it anyway
> - so those systems might as well be interoperable
> - and the RFC can provide guidance on how to avoid some security risks
>
> At the time there was concern that publishing such a specification would be
> taken as IETF endorsement of the practice of adding silent facilities that
> compromise key security. The consensus that emerged, though, was that such a
> possibility was outweighed by the utility of having interoperable
> implementations.
>
> Is the decision about ML-KEM not of a very similar shape? Standalone ML-KEM
> is *going* to happen, as evidenced by even just the statements of intent made
> in the WGLC thread. The IETF can help it happen interoperably with some
> guidance, or not.
>
> It seems like consensus has been somewhat more difficult to determine for
> standalone ML-KEM than it was for SSLKEYLOGFILE, and I'm interested to hear
> from people who were for SSLKEYLOGFILE but who are against standalone ML-KEM:
> how do these situations differ? What underlying principles are guiding your
> position?
>
> Thanks,
>
> Mike
>
> _______________________________________________
> 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]
