On Mon, Oct 27, 2025 at 04:06:35PM -0400, Sean Turner wrote:
> Hi! It appears we have failed to reach consensus to make a change as a
> result of this comment. If you disagree with this, please indicate why
> (and provide some text) by 31 October 2025.
That's seems to me to be unfortunate, because the original advice to the
implementor to "retry" in case of failure is unreasonable.
- It is unclear how the this sort of failure might be distinguished
from genuinely bad incoming ciphertext, or data corruption in
transit.
- The probability of algorithm failure appears to be far lower than
that of failure of the computer hardware on which the algorithm is
executed.
> >> 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".
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
