responding to my own message … Hi! It now appears that we have consensus to remove the *Failures* paragraph from s4 of draft-ietf-tls-hybrid-design.
Authors: I have discussed this with Paul and the text will be removed via an RFC editor's instruction -- there is no action needed on your part to implement this change. Cheers, spt > On Oct 27, 2025, at 16:06, Sean Turner <[email protected]> wrote: > > > 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]
