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]>
*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]
