I like this text, but s/negliable/negligible.
-----Original Message-----
From: Paul Wouters <[email protected]>
Sent: Friday, September 26, 2025 9:38 AM
To: Sophie Schmieg <[email protected]>
Cc: [email protected]
Subject: [EXTERNAL] [TLS] Re: ML-KEM failures
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
content is safe.
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]
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
