I'm also in favor of simply deleting the text. Chris P.
On Tue, Oct 28, 2025, 10:19 David Benjamin <[email protected]> wrote: > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
