Thank you Scott, I think your observation takes care of my concern, assuming implementers implement ML-KEM as described in NIST-FIPS-203 which is merely an Informational Rereference. Would it make sense to make the meaning of "ML-KEM" in the spec more normative? For example, add something like "The security of this construct depends on the secure implementation of ML-KEM as described in [NIST-FIPS-203]." to imply that we want implementers to follow that spec, and not some other spec for ML-KEM (including earlier papers on CRYSTALS-KYBER).
The document have two Normative References that I don't see any
normative use of, could these papers be downgraded to Informational?
These seems to be background reading, not essential to implementers.
[FO]
Fujisaki, E. and T. Okamoto, "Secure Integration of Asymmetric and
Symmetric Encryption Schemes", Springer Science and Business Media LLC, Journal
of Cryptology vol. 26, no. 1, pp. 80-101, DOI 10.1007/s00145-011-9114-1,
December 2011, <https://doi.org/10.1007/s00145-011-9114-1>.
[HHK]
Hofheinz, D., Hövelmanns, K., and E. Kiltz, "A Modular Analysis of the
Fujisaki-Okamoto Transformation", Springer International Publishing, Lecture
Notes in Computer Science pp. 341-371, DOI 10.1007/978-3-319-70500-2_12, ISBN
["9783319704999", "9783319705002"], 2017,
<https://doi.org/10.1007/978-3-319-70500-2_12>.
/Simon
"Scott Fluhrer (sfluhrer)" <[email protected]> writes:
> 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]
>
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
