Hi! It appears we have failed to reach consensus to make a change as a result of this comment. If you disagree with this, please indicate why (and provide some text) by 31 October 2025.
spt > On Sep 30, 2025, at 14:29, David Cooper <[email protected]> wrote: > > I don't see where > https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-16.html is > specific to ML-KEM. In fact, looking through the draft I believe the text > that I proposed is insufficient because it does not mention explicit > rejection. > > Section 2 states that the Decaps function outputs "in some cases a > distinguished error value." So, if that text is to remain, it seems that the > draft should specify what to do in the case that Decaps outputs an error > value. > > I agree with you that the draft should not be a cryptographical textbook. > There was just some concern by some that implementers would be confused if > they read about failures in ML-KEM and text didn't say how to handle them. I > was just proposing a rewording of the text that tries to clarify for > implementers that there is nothing they need to do in the case of ML-KEM (or > other KEMs that use implicit rejection). > > As this text is intended for implementers and is not a cryptographical > textbook, I was not trying to imply (despite another commenter's suggestion > to the contrary) that it has been proven that it is mathematically impossible > to distinguish one type of failure from another. This draft is not intended > for cryptographers and so "indistinguishable" is not to be interpreted in a > cryptographic sense. > > Similarly, I do not believe anything in my text is trying to address the > possibility that an implementer might try to deviate from the implementation > of the underlying KEM. The text essentially indicates that since the > underlying KEM always output a session key, no special processing is needed > to handle cases in which a failure occurs. There is no text mentioning that > the underlying decaps function includes a reencryption check, and that a > failure of that check could be used in some way, but that doing so would be > discouraged. So I do not understand why the other commenter suggested that my > proposed text seems to allow deviations from the correct implementation, but > then discourages doing so. > > On 9/29/25 15:52, Scott Fluhrer (sfluhrer) 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]> <mailto:[email protected]> >> Sent: Monday, September 29, 2025 4:07 PM >> To: Paul Wouters <[email protected]> <mailto:[email protected]> >> Cc: [email protected] <mailto:[email protected]> <[email protected]> <mailto:[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] <mailto:[email protected]> > To unsubscribe send an email to [email protected] <mailto:[email protected]>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
