Hi, I agree that simply deleting the text is the way to go.
Cheers, - Ira On Tue, Oct 28, 2025 at 3:38 PM Watson Ladd <[email protected]> wrote: > Happy to delete if we can't find a better way to phrase it. > > On Tue, Oct 28, 2025, 12:13 PM Kris Kwiatkowski <kris= > [email protected]> wrote: > >> I also think simply deleting the text is the way to go. >> >> >> On October 28, 2025 6:38:55 PM GMT, Bas Westerbaan <bas= >> [email protected]> wrote: >> >>> I concur. >>> >>> On Tue, Oct 28, 2025 at 6:48 PM Eric Rescorla <[email protected]> wrote: >>> >>>> I concur. I actually had thought we had agreed that the current text >>>> shouldn't appear and then there was some attempt to converge on a >>>> replacement, but that >>>> didn't really work out, so we should just delete it and move forward. >>>> >>>> -Ekr >>>> >>>> >>>> On Tue, Oct 28, 2025 at 10:24 AM Christopher Patton < >>>> [email protected]> wrote: >>>> >>>>> 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] >>>>> >>>> _______________________________________________ >>>> 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
