Those two references were removed in version -16: https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-hybrid-design-15&url2=draft-ietf-tls-hybrid-design-16&difftype=--html
On Tue, Sep 23, 2025 at 9:21 AM Simon Josefsson <simon= [email protected]> wrote: > 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] > > > _______________________________________________ > 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]
