I agree with Sophie. The proposed text says that a failure results in
the parties deriving different shared secrets. So, it seems to be only
discussing KEMs that use implicit rejection. (With explicit rejection,
the recipient would receive a failure indication rather than deriving a
different shared secret.) In the case of implicit rejection, the failure
would be indistinguishable from one caused by a corrupted ciphertext.
So, it seems incorrect to RECOMMEND against trying to specifically
handle such failures when it should be impossible for implementations to
attempt to handle such failures differently from other failures.
How about this as possible new text:
Some post-quantum key-exchange algorithms, including ML-KEM
[NIST-FIPS-203], have a very small, but non-zero, probability of
failure. This means that in theory the parties to the key exchange
could derive different shared secrets even if both parties perform
the algorithm correctly and no data is modified in transit. Such
failures would be indistinguishable from other occurrences that
would result in the client and server not deriving the same shared
secrets (e.g., random bit corruptions, computation errors, malicious
modification of data in transit) and so would be handled in the same
way.
On 9/26/25 06:38, Paul Wouters wrote:
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]
