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]
