Correct and reasonable. I see no reason not to have an RFC that specifies ML-KEM, especially when it's already RECOMMENDED=N. Based on the heat of this discussion, one would think the controversy was whether it should be Y rather than N, but alas.
On Fri, Apr 10, 2026 at 2:03 PM Deirdre Connolly <[email protected]> wrote: > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
