Strong agree. Failure probabilities lower than the chance of hardware failure can only be ignored. Anything else is needless complexity.
(I believe we’d also avoid handling the DSA signature failure case, if we were to write it up today.) 2025-09-22 21:03 GMT+02:00 Eric Rescorla <[email protected]>: > 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]
