I think there is still some value in saying something short, even if it is just to indicate that the decapsulation key checks are not generally needed:
Before using the client’s encapsulation key, the server MUST perform the type and modulus checks from Section 7.2 of [FIPS203]. Before using the server’s ciphertext, the client MUST perform the ciphertext type check from Section 7.3 of [FIPS 203]. It is not necessary for the client to perform the decapsulation key type or hash checks from Section 7.3 of [FIPS 203] on a decapsulation key that was validly generated by that client [NIST-SP-800-227]. This seems consistent with the point validation requirement for NIST curves in RFC8446. The error handling can probably be inferred. Peter From: Bas Westerbaan <[email protected]> Sent: 26 June 2026 09:27 To: Martin Thomson <[email protected]> Cc: [email protected]; [email protected]; tls-chairs <[email protected]> Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08) I'd be happy for the checks to be removed. On Fri, Jun 26, 2026 at 5:03 AM Martin Thomson <[email protected]<mailto:[email protected]>> wrote: On Fri, Jun 26, 2026, at 12:47, David Benjamin wrote: >> 2. (Decapsulation key type check) If dk is not a byte array of length >> 768𝑘+96 for the value of >> 𝑘 specified by the relevant parameter set, then input checking has failed. > > This is the *length of the private key*. That is (hehe) checking what > you generated. It is *not* what you received from the other side. I see, thanks for the explanation. I sort of assumed that FIPS 203 wouldn't be THAT silly. Bad assumption on my part. Given that any checking that exists is already implied by an invocation of Encaps/Decaps, would it be acceptable to simply remove the explicit pointer to the checks? I've suggested that on the PR: https://github.com/tlswg/draft-ietf-tls-mlkem/pull/25/changes#r3478889869
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
