I would agree with not wanting to send the message that handshake failures are a practical concern, and thus the text should be changed. I do think it is likely that implementers who have a passing familiarity with ML-KEM will wonder whether they should be concerned about failure probability, and that some section of the document should at least mention the issue of failure probability and perhaps reassure developers that they do not have to worry about KEMs/hybrids with cryptographically small failure probability. Perhaps also a comment that the hybrid document is *only* concerned with KEMs that have a cryptographically small failure probability, and that other security issues may need to be considered for hybrids involving non-negligible failure probability.
That being said, I don't know enough about IETF process to know what the procedure is for making a change like this in the document at this stage. Douglas > On Sep 22, 2025, at 7:29 PM, Kris Kwiatkowski > <[email protected]> wrote: > > I agree with removing the section. ML-KEM failures are exceedingly rare, and > restating this risks suggesting handshake failures are a practical concern. I > doubt it makes sense to mention this in ML-KEM-specific drafts, and even less > so in a generic hybrid draft. > > > On 22/09/2025 20:03, Eric Rescorla 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] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> > _______________________________________________ > 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]
