Here is what is currently on #main of the repo:
```
# Security Considerations {#security-considerations}
This document defines standalone ML-KEM key establishment for TLS 1.3.
Hybrid key establishment mechanisms, which support combining a post-quantum
algorithm with a traditional algorithm such as ECDH, are supported
generically via {{HYBRID}} with some concrete definitions in
{{ECDHE-MLKEM}}. Hybrid mechanisms provide security as long as at least one
of the component algorithms remains unbroken, such as combining
quantum-resistant and traditional cryptographic assumptions. Standalone
ML-KEM relies on lattice-based and hash function cryptographic assumptions
for its security. Proponents of hybrid PQ/T key establishment generally
consider it a conservative approach to deployment of newer post-quantum
schemes alongside older traditional schemes, retaining at least the security
currently offered by traditional algorithms.
The main security property for KEMs is indistinguishability under adaptive
chosen ciphertext attack (IND-CCA), which means that shared secret values
should be indistinguishable from random strings even given the ability to
have other arbitrary ciphertexts decapsulated. IND-CCA corresponds to
security against an active attacker, and the public encapsulation key /
secret decapsulation key pair can be treated as a long-term key or reused in
generic usage. ML-KEM satisfies IND-CCA security in the random oracle model
{{KYBERV}} via a variant of the Fujisaki-Okamoto (FO) transform
{{FO}}{{HHK}}. Use of KEMs for key agreement in TLS 1.3 has been analyzed
and
discussed in multiple settings and security models {{DOWLING}} {{KEMTLS}}
{{HV22}} {{CHSW22}} {{CZCJWH25}} {{ZJZ24}}: ML-KEM's IND-CCA security
exceeds
the requirements for ephemeral key establishment and secure in case of reuse
{{GHS25}} {{RFC8446bis}}.
{{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 as 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}}.
```
On Fri, Apr 10, 2026, 10:30 AM Nico Williams <[email protected]> wrote:
> On Fri, Apr 10, 2026 at 10:04:08AM -0700, Eric Rescorla wrote:
> > > > is more secure
> > >
> > > is a point of debate. The text on #main currently does not state as
> fact
> > > one side as more secure than the other
> >
> > As Deirdre says, this is contested.
>
> There is no doubt that hybrids are at least as secure as their
> individual components. And they are more secure than one of their
> individual components -- the point is that we don't necessarily know
> which of those components is weaker.
>
> I propose we phrase it in that way then:
>
> - hybrids at least as secure as their most secure component
>
> (certainly when the hybrid is designed correctly, and the claim does
> need some analysis, but I think no one disputes that a well-designed
> hybrid _can be_ t least as secure as...)
>
> - hybrids therefore are more secure than their least secure component
>
> - we don't know which component is weakest or which is strongest
>
> The last point is about the biggest points of contention:
>
> - Are CRQCs coming? Some say never.
>
> - Are any PQC algorigthms known-weak to NSA and/or other TLAs? Some
> say the risk is high of that.
>
> So don't make a statement either way, just say that one can be presumed
> weaked than the other but we don't yet know which.
>
> > [...]
> >
> > As I said, my preference is for hybrids, but I think trying to produce
> > some text that will achieve consensus that says, in essence, "hybrids
> > are better" is quite challenging and probably not worth the effort.
> > Rather, I think we should just encode it in the Recommended=Y field
> > and leave it at that.
>
> Certainly we need at least one algorithm with PQC as a component, or
> pure PQC, with Recommended=Y. At this point a pure PQC algo will not
> get Recommended=Y, so...
>
> Nico
> --
>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
