When ML-KEM decaps runs into a decapsulation failure, it doesn't return an "error flag" to the application (TLS).
Instead, it will return a random-looking "shared secret", which is independent of the real shared secret. That way, both sides will use their shared secrets, which are unrelated, and the protocol will fail. It was designed specifically so the application (TLS) will not have to worry about it. And, there's nothing to be said in the draft, because TLS cannot realize that something happened until the symmetric keys don't match. That said, the probability of a "decapsulation failure" for a record that wasn't modified in the middle is so tiny (< 2**-138) that it will almost certainly never happen anywhere at any time. This can be seen by considering the number of TLS key exchanges that are likely to happen for the lifetime of this protocol - if we assume that every device in the world (circa 2**40 I believe) renegotiate using the protocol a million times a second (2**20 - I didn't think IOT devices were that fast), and the protocol is used for over 100 years (2**32 seconds), even that unrealistic numbers gives only a product of 2**92 negotiations, and so that gives a probability of less than 2*-46, that is, one in 70 trillion, that some exchange somewhere in that 100 years will encounter a "decapsulation failure" event. Hence, I agree with EKR that the WG can ignore the possibility. ________________________________ From: Simon Josefsson <[email protected]> Sent: Tuesday, September 23, 2025 7:00 AM To: Eric Rescorla <[email protected]> Cc: <[email protected]> <[email protected]> Subject: [TLS] Re: ML-KEM failures I tend to agree with everyone else here, but to offer another viewpoint for consideration: What's the implementer guidance on how to implement this, if the draft is silent on this topic? Is this "undefined behaviour"? Would it help to say that the handshake MUST fail in this situation, rather than imply anything about retry? Otherwise, depending on choice of undefined behaviour, you could actually get a successful handshake. I don't think that's what you had in mind, since you said this will lead to a handshake failure. But if the draft is silent on this, anything could happen. So maybe simply saying that this MUST lead to a handshake failure is worth doing, otherwise it won't necessarily lead to a failure as you suggest. To see what I mean, consider an implementation that converts from a low-level MLKEM library (that do return the potential FAIL case) to a TLS wrapper that doesn't handle failure: void derive_secret(char *secret, size_t len) { bool ok; char tmp[SZ]; memset(tmp, 42, SZ); ok = mlkem(tmp); /* won't touch tmp buffer on !ok */ memcpy (secret, tmp, SZ); } On MLKEM failure, and if the two peers used similar code, this would end up using an all-42 shared secret, and the handshake may succeed. Unless I'm missing something else here? /Simon Eric Rescorla <[email protected]> writes: > Hi folks, > > I see that the hybrid doc continues to have this text: > > *Failures.* Some post-quantum key exchange algorithms, including ML-KEM [ > NIST-FIPS-203 > <https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-16.html#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. > > There was extensive discussion about this for the pure ML-KEM draft, and my > sense was the sentiment was that this should not be discussed, at least for > ML-KEM. I think we should remove > this whole section. > > -Ekr > _______________________________________________ > 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]
