On Thu, 25 Sep 2025, Sophie Schmieg wrote:
So from a practical point of view, there is simply no guidance to give
implementers. Not only are such errors incredibly unlikely, they also behave
exactly the same
as corrupted ciphertexts, and your stack will handle those, since there is no
difference to the behavior in the case of ECDH.
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.
If someone can write up a better and shorter text, please send in your
proposed text.
Paul
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
