To be clear, one document, draft-ietf-tls-hybrid-design-16 <https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/>, is currently in the editor's queue, and is fully generic in how to combine KEMs and elliptic curves— it is not specific to ML-KEM.
draft-ietf-tls-ecdhe-mlkem-01 <https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/> defines specific concrete instantiations of the generic hybrid construction above, and only uses ML-KEM in those. Any future instantiations of -hybrid-design may use other KEMs besides ML-KEM. On Mon, Sep 29, 2025 at 6:54 PM Scott Fluhrer (sfluhrer) <sfluhrer= [email protected]> wrote: > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
