Hi all,
Well... at the time of this email, the GH Repo appears to have 5 PRs and
all of them touch Security Considerations, so I don't think it makes much
sense to submit a 6th (!) competing PR. However, I have attempted to
synthesize PR #14 [0] and #22 [1] alongside feedback from this thread
anyway, which I offer below.
It largely retains Rich Salz's rework [0], while referencing Nadim's
analysis alongside the supporting text Usama suggested from [1]. My
revision includes a dedicated subsection highlighting the use of ML-KEM in
PQ/T hybrids, referencing Nadim's work while retaining Rich's original
final sentence, which leaves the choice of "mechanism(s) to support" to
developers and deployers.
---
# Security Considerations {#security-considerations}
{{NIST-SP-800-227}} includes guidelines and requirements for
implementations on using KEMs securely. Implementers are encouraged to use
implementations resistant to side-channel attacks, especially those that
can be applied by remote attackers.
TLS 1.3's key schedule commits to the ML-KEM encapsulation key and the
ciphertext since the `key_exchange` field of the `key_share` extension is
populated with those values, which are included as part of the handshake
messages. This provides resilience against re-encapsulation attacks against
KEMs used for key establishment {{CDM23}}.
## Use of ML-KEM in PQ/T hybrids
This document defines standalone ML-KEM key establishment for TLS 1.3. A
PQ/T hybrid combines a post-quantum algorithm such as ML-KEM with a
traditional algorithm such as Elliptic Curve Diffie-Hellman (ECDH), e.g.,
{{ECDHE-MLKEM}}.
Independent machine-checked symbolic analysis using ProVerif [REF] shows
that hybrid mechanisms provide security as long as at least one of the
component algorithms remains unbroken. The same symbolic analysis also
demonstrated that a compromise of the key exchange also compromises
handshake authentication, not just confidentiality.
Those developing or deploying TLS 1.3 with either encapsulation method will
have to determine the security and operational considerations when choosing
which mechanism(s) to support.
---
Cheers,
Nathanael
[0] https://github.com/tlswg/draft-ietf-tls-mlkem/pull/14
[1] https://github.com/tlswg/draft-ietf-tls-mlkem/pull/22
On Sun, 7 Jun 2026 at 21:47, Andrew Lee <[email protected]> wrote:
> On Sun, Jun 7, 2026 at 8:32 PM Peter Gutmann <[email protected]>
> wrote:
>
>> Hybrids are useful if you've got people clamoring for PQC but don't want
>> to
>> take the risk of committing to something that we have almost no deployment
>> experience with compared to the 30-50 years of practical experience with
>> conventional PKC algorithms.
>
>
> Exactly this.
>
> Further, standard setting should take into consideration the state of our
> current reality as opposed to a future goal not yet reached. Secondly,
> layering three schemes doesn't provide any benefit; in this case, ML-DSA is
> young with strong potential, whereas Ed25519 etc. are mature and battle
> tested. There's a purpose for layering these two since, luckily in this
> case, you do get the best of both worlds. It's the same reason you wouldn't
> launch and start using Daemon N+1 into a live userbase on day 1: the live
> userbase isn't the beta test network.
>
> The rust ML-DSA crate's '<' vs '<=' bug was committed initially as a fix,
> this year. Unfortunately, it led to signature malleability. Luckily, again,
> this was only an implementation flaw but said flaw undiscovered would make
> it unusable for verification/authentication. Even if an implementation flaw
> exists, Ed25519 keeps things from crashing out so to speak.
>
> In terms of audits, I agree it's not the IETF's mandate to police wild
> code, but standard setting, again, should take into consideration the state
> of implementations out there and their hardening, or lack thereof.
>
> _______________________________________________
> 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]
