Greetings tls-chairs and hello to other TLS-related folks,
On 6/24/26 17:00, Joseph Salowey via Datatracker wrote:
This message initiates a new Working Group Last Call for draft-ietf-
tls-mlkem[1], which defines standalone ML-KEM key establishment for
TLS 1.3. The main question before the working group is: "Should the
working group publish a document specifying stand alone ML-KEM?".
I do not support the publication of this document.
If
there is rough consensus then we will push to refine and publish the
document; otherwise, we will stop discussing the draft and not
progress it. Please respond to this call indicating whether you
support publishing a document specifying a stand alone ML-KEM.
Please refrain from further discussion on this topic as most
arguments have been discussed multiple times.
Why are we holding this consensus call now?
>
> Significant developments have occurred both within this document and
> in the broader TLS ecosystem to address the concerns raised in the
> last WGLC. Therefore, the third consensus call is warranted. We ask
> the working group to consider document publication in light of these
> recent changes:
>
Unfortunately, the reasons listed do not address several of my concerns.
One of my primary concerns is the intentional removal by NIST of the
hash call over the `m` value in FIPS 203 for ML-KEM before it is used
internally by ML-KEM.Encaps(). Please consult Appendix C and
specifically the third bullet point of C.1 on page 47 of FIPS 203 [0]
for NIST's disclosure about this matter. The developments listed by Joe
and Sean below do not mitigate the risk introduced by this change to
Kyber as part of standardizing ML-KEM.
To Nadim and Usama's credit: I found their formal modeling to be useful.
When I last looked at the (symbolic) models, I understood that they did
not model the RNG covert channel leakage concerns. This makes sense as
it is internal to one part of ML-KEM, and the carrier of the covert
channel is not directly visible on the wire as the covert channel itself
is encrypted (e.g., the ciphertext is visible on the wire, but the
covert channel encoded through `m` is not directly modeled as such).
This is an unfortunate gap with symbolic models generally where
cryptographic primitives are considered perfect as it makes some
internal issues invisible. It is not a problem with their work; it is a
problem with the primitive itself and the abstraction of symbolic models.
Additionally the security considerations of the draft document in question:
- do not mention outstanding technical concerns in the NIST process
- do not link to the official comments in the NIST process
- do not mention outstanding technical concerns in IETF discussions
- do not give sufficient warning to those who are not cryptographers
- do not give sufficient warning to cryptographic protocol engineers
- do not mention the FIPS 203 requirement for NIST-approved randomness
generation
The last item is especially relevant - do endorsers of this non-hybrid
ML-KEM draft all use ML-KEM only with NIST-approved randomness
generation sources? Do they realize that this requirement is part of the
security analysis? Again, hashing of `m` was removed intentionally and
it is explained as part of the third bullet point of Appendix C in C.1
on page 47 of FIPS 203 [0] for NIST's disclosure: "As this standard
requires the use of NIST-approved randomness generation, this step is
unnecessary and is not performed in ML-KEM." The security considerations
of this document most certainly do not state that a NIST-approved
randomness source is _required_. Nor do they explain that the removal of
the hashing is considered secure only if that _required_ NIST-approved
randomness source is used. The draft does not raise this clear and
serious warning.
The introduction by NIST of a covert channel in the design of Kyber as
part of standardizing ML-KEM may lead to serious problems with TLS 1.3.
No draft should promote ML-KEM without closing this covert channel.
Instead, this draft implicitly relies on a NIST-approved randomness
source as the mitigation for that covert channel. This is uncomfortably
similar to how Dual_EC_DRBG, once NIST-approved, ended up being used in
the real world despite being suitable for such covert channels.
Ideally, I suggest closing the covert channel in the draft because doing
so is trivial. This is separate from hedging with a hybrid construction.
Relatedly, TLS 1.3 should also not reveal system randomness directly to
the wire as several TLS implementations do today.
Taken together, an adversary with a carefully placed kleptographic RNG
backdoor will not even need an Extended Random draft this time around.
I note that NIST did not engage with many of the official 2023 comments
[1]. That limited engagement is concerning in light of NIST’s later
disclosures about Dual_EC_DRBG, including its own email disclosure [2]
between Don Johnson and John Kelsey. Dual_EC_DRBG also remains present
in at least one widely deployed cryptographic library.
For example, Bouncy Castle still contains a DualECSP800DRBG
implementation [3][4] whose default P-256 Q point matches the
(backdoored) value listed in the now-withdrawn NIST SP 800-90A Appendix
A.1.1 [5, page 77].
As the IETF takes no stance on the validity of patent claims, I propose
a simple compromise to move the document along: in the next iteration of
the draft, I would like to see the IETF require any ML-KEM
implementation to hash `m` as Kyber did, and to state explicitly that
relying on a NIST-approved randomness source is not an adequate
mitigation for this concern. If reliance on NIST-approved randomness
generation is retained, it should at least be explicitly required rather
than implicitly endorsed by being buried deep within a comment in an
appendix to FIPS 203. Such changes are interoperable even if other
ML-KEM implementations do not make them. Hashing destroys the structure
needed to exploit Dual_EC_DRBG and other similar kleptographic
constructions.
The draft could also encourage a similar strategy for all random bytes
fields in TLS 1.3 that currently come directly from the system but that
change is a better fit for a different draft. I would want to see
changes made to ML-KEM and TLS 1.3 before I would feel confident that
TLS 1.3 with ML-KEM was providing protection against serious large-scale
adversaries.
I have additional technical concerns as well as some additional
technical mitigations. I am happy to share draft analysis and code with
interested participants.
Kind regards,
Jacob Appelbaum
[0] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf
[1]
https://csrc.nist.gov/files/pubs/fips/203/ipd/docs/fips-203-initial-public-comments-2023.pdf
[2]
https://csrc.nist.gov/CSRC/media/Projects/Crypto-Standards-Development-Process/documents/Email_Oct%2027%202004%20Don%20Johnson%20to%20John%20Kelsey.pdf
[3]
https://downloads.bouncycastle.org/java/docs/bcprov-jdk14-javadoc/org/bouncycastle/crypto/prng/drbg/SP80090DRBG.html
[4]
https://raw.githubusercontent.com/bcgit/bc-java/main/core/src/main/java/org/bouncycastle/crypto/prng/drbg/DualECSP800DRBG.java
[5]
https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-90a.pdf
- Promotion of Hybrids in draft-ietf-tls-ecdhe-mlkem: Following a
separate consensus call, the WG agreed to promote the X25519MLKEM768
hybrid group to Recommended: Y in the IANA registry. Consequently,
the IANA registry will reflect a clear community preference for a
hybrid because Recommended: Y clearly indicates this while the
standalone ML-KEM groups defined in this draft remain Recommended:
N. The updated security considerations in [1] reference the IANA
registry to emphasize this preference.
- Key Share Reuse Prohibited in draft-ietf-tls-rfc8446bis: The WG
recently reached consensus to explicitly prohibit key share reuse
across connections in TLS 1.3. The new text changes the guidance
from SHOULD NOT to a strict MUST NOT. This resolves the concerns
regarding static key reuse and its associated privacy and forward-
secrecy risks for ML-KEM.
- Nadim updated the ProVerif model of TLS 1.3 to evaluate KEM and
hybrid KEM groups in TLS 1.3. This supports other results which show
that KEMs are secure when used in TLS 1.3 and that hybrid groups are
secure even if one of the components is compromised.
- Liaisons: We received liaison statements from multiple SDOs
including O-RAN[2], IEEE 802.11[4] and from 3GPP[3] expressing
support for the publication of draft-ietf-tls-mlkem as an RFC as
they rely on the IETF to provide a stable normative reference.
Please note that a third-party IPR disclosure exists [5] against
this document regarding patents related to the underlying ML-KEM
algorithm. This IPR declaration has not changed since the last WGLC.
As a reminder, per BCP 79, the IETF takes no stance on the validity
of patent claims, and the working group may decide to proceed with a
technology despite IPR disclosures if it decides that such use is
warranted.
Conduct Reminder: Given the heated nature of previous discussions on
this topic, participants are strongly reminded to adhere to the IETF
Code of Conduct (BCP 54) and the TLS WG's Mail List Procedures. Keep
feedback professional, technical, and focused on the document's
text.
This working group last call will end on 2026-07-08.
Joe and Sean
[1] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ [2]
https://datatracker.ietf.org/liaison/2198/ [3] https://
datatracker.ietf.org/liaison/2151/ [4] https://datatracker.ietf.org/
liaison/2148/ [5] https://datatracker.ietf.org/ipr/search/?
submit=draft&id=draft-ietf-tls-mlkem
_______________________________________________ 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]
