One thing to consider for the text for -hybrid-design is that while ML-KEM and many PQ KEMs are implicit-rejection and always return a pseudorandom value on decryption failure, during which TLS cannot detect a failure programmatically, some are not (they are explicit rejection) and may have a return code that can be caught and the protocol/application can change behavior on. This (implicit rejection) is considered a security win <https://pq-crystals.org/kyber/data/kyber-specification-round3-20210804.pdf>as failure to correctly interpret the return code as a code, but as a pseudorandom key, is insecure.
So, what happens explicitly in TLS 1.3 when the client and server do the whole handshake correctly but there is a decaps/decryption failure and the handshake secrets disagree? All the downstream secrets in the key schedule will disagree. How is this noticed in the protocol? Not as a ` handshake_failure <https://datatracker.ietf.org/doc/html/rfc8446#section-6.2>`, but I'm pretty sure with a `bad_record_mac <https://datatracker.ietf.org/doc/html/rfc8446#section-5.2>`. This does not seem incorrect. If we are cool with that then we can remove all mention of KEM failures and sleep well at night On Mon, Sep 22, 2025 at 3:04 PM Eric Rescorla <[email protected]> wrote: > Hi folks, > > I see that the hybrid doc continues to have this text: > > *Failures.* Some post-quantum key exchange algorithms, including ML-KEM [ > NIST-FIPS-203 > <https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-16.html#NIST-FIPS-203> > ], have non-zero probability of failure, meaning two honest parties may > derive different shared secrets. This would cause a handshake failure. > ML-KEM has a cryptographically small failure rate; if other algorithms are > used, implementers should be aware of the potential of handshake failure. > Clients MAY retry if a failure is encountered. > > There was extensive discussion about this for the pure ML-KEM draft, and > my sense was the sentiment was that this should not be discussed, at least > for ML-KEM. I think we should remove > this whole section. > > -Ekr > > _______________________________________________ > 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]
