I also agree we should simply delete the text. It is irrelevant for ML-KEM. While the text says "if other algorithms are used", if we ever do consider an algorithm where this matters, we can always debate it then, with full context, and put it in *that* document, where it would be more likely to be read by implementers anyway.
PS: The formatting in that section is slightly odd. Should "Larger public keys and/or ciphertexts", "Duplication of key shares", and "Failures" (but delete that one) be subsections? On Tue, Oct 28, 2025 at 5:49 AM Filippo Valsorda <[email protected]> wrote: > 2025-10-28 05:29 GMT+01:00 Viktor Dukhovni <[email protected]>: > > > >> I think there is consensus that there is no advise to give to > implementers > > >> to handle these failure cases. While we could use that to justify > saying > > >> nothing, my own preference is to at least have a sentence explicitely > > >> saying that implementers should do nothing, in case implementers > become > > >> aware of these theortical failures and wrongly assume the > specification > > >> was not aware and thus "vulnerable" to these issues. > > >> > > >> Perhaps: > > >> > > >> Current: > > >> Some post-quantum key exchange algorithms, including ML-KEM > > >> [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. > > >> > > >> New: > > >> Some post-quantum key exchange algorithms, including ML-KEM > > >> [NIST-FIPS-203], have non-zero probability of failure, meaning > > >> two honest parties may derive different shared secrets. This > > >> would cause a handshake failure. As with other similar failures > > >> (such as bit corruptions), Clients MAY retry if a failure is > > >> encountered. Due to the negliable rate of occurances of these > > >> failure events, the lack of a known feasable method and the > > >> additional risk of introducing new attack vectors when attempting > > >> to handle these events, it is RECOMMENDED for implementers to > > >> not specifically handle post-quantum key exchange shared secrets > > >> failures, and rely on the pre-existing code paths that handle > > >> derivation failures. > > It was my impression that there was rough consensus to drop the original > text and say nothing instead, though the "New" text above is instead an > acceptable overly-elaborate way of saying "nothing to see here, move > along". > > > Yeah, it looks to me like there is no consensus on the original text, in > fact. Different people have different opinions on what to replace it with, > but that doesn't mean there is consensus on the original. I think the bar > to ship some text is WG consensus, not lack of consensus on alternatives. > Does anyone actually support shipping the original text? > > Were there any strong objections to saying nothing? All I could see were > "we could say nothing, or we could say [text]" which implies support for > saying nothing, as well. > _______________________________________________ > 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]
