I believe I have said this before, I'll reiterate The goal of the RFC text should be to give implementors instructions on how to implement the protocol. Advice that we give should be actionable; that is, something that they can implement.
The suggested text is not that. It essentially says "the system might fail, and there's nothing you can do about it". While technically true, there is only a tiny probability of it ever happening anywhere in the world, for the lifetime of TLS 1.3, between two honest parties and uncorrupted communication. Again, I wouldn't mention it - why mention something that, in practical terms, is not a concern at all? And, while I'm ranting, what's with this "it seems to be only discussing KEMs that use implicit rejection". Of course it is - this draft is specific to ML-KEM. Referring to other KEMs should be out of scope. This draft should not be a cryptographical textbook - instead, it should be an instruction manual on how to implement the protocol correctly and securely. ________________________________ From: David Cooper <[email protected]> Sent: Monday, September 29, 2025 4:07 PM To: Paul Wouters <[email protected]> Cc: [email protected] <[email protected]> Subject: [TLS] Re: ML-KEM failures 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]
