[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)

[Nick Sullivan <[e-mail]>]

Hi Martin,

Short version: §7.2 and §7.3 aren't symmetric, and that's the root of this.

§7.2 (encapsulation key) is entirely a check on peer-supplied input (both
length and modulus), so a failure is illegal_parameter.

§7.3 (decapsulation input check) is not the mirror image. It bundles one
peer-input check (ciphertext length, the only check FIPS mandates on every
Decaps) with two local decapsulation-key checks (length and embedded hash)
that validate your own key, not anything from the peer. So effectively, to
run a §7.3 check that only fails on peer input, you run the length check
only. §7.3 does not expose this subcheck as separable.

So in this TLS flow, the server's §7.2 check of the client's pk and the
client's ciphertext-length check on the server's ct are peer-input checks,
and failure should be illegal_parameter. The §7.3 dk checks are different:
they are checks on the client's own decapsulation key, so they are local
assurance and should not be a per-Decaps peer-input alert path. With an
already-certified dk, §7.3 reduces to just checking the length and can only
fail with 'illegal parameter'. Bringing the whole §7.3 check into this
section duplicates work and risks conflating errors from a broken keygen
 (not illegal_parameter) and peer-supplied input issues (illegal_parameter).

#25 regresses in two places:
- It replaces §7.2 with a length check (illegal param), letting the other
part of  §7.2 (modulus check) fall through to internal error.
- It adds a wholesale §7.3 check after a length check that fully satisfies §7.3
given dk was generated by this party. This could be read as bringing back
the full validation of a validated dk for every call. (#24 does the same).

So my suggestion is that adding "encapsulation or" to the catch-all on line
245, from #24, is the only change needed. Internal Encap failures errors are
not yet addressed in this document. RNG, memory and other non-peer Encap
failures return internal_error, which is the right alert. (BoringSSL's
Encap can't even return an error; it treats RNG failure as fatal rather
than returnable, but that's a design choice, not a protocol imperative.)

Best,
Nick


On Thu, Jun 25, 2026 at 10:21 PM Martin Thomson <[e-mail]> wrote:

>
> On Fri, Jun 26, 2026, at 07:39, Nick Sullivan wrote:
> > Quick clarification of my last email. The points, briefly:
> > - Publish -08 as-is: ok
> > - Do not merge #25: it reroutes a failed Section 7.2 encapsulation-key
> > check from illegal_parameter to internal_error, away from -08 (and the
> > approved draft-ietf-tls-ecdhe-mlkem).
> > - Minor, non-blocking: probabilistic wording in Section 4.3, the DTLS
> > freshness clarification, and a note that implicit rejection is not an
> > error.
>
> Nick, that original mail was tl;dr.  I tried.  Are you suggesting that the
> draft is correct without changes?  Just because it works doesn't make it
> good.  A lot depends on how you intend to use this API, but I would greatly
> prefer that it be at least possible to only have to deal with APIs that
> take byte sequences.  (Unlike other uses of the same thing, there is no
> value to obtaining a checked value for multiple uses, because these are
> single-use items.)
>
> With that API, failing the checks in FIPS 203 will be indistinguishable
> from failing to gather entropy or actual cryptographic problems (which we
> generally want to hide; fault injection, etc...).
>
> The part where this gets weird for me is this (which both you and Bas say
> in different ways, I think):
>
> > First, the client need not repeat the decapsulation-key checks on every
> operation [...]
>
> I was not suggesting that the client check the key it made at all (unless
> I'm completely losing it).
>
> #25 says:
>
> > Prior to encapsulation, the server MUST perform the encapsulation key
> check
> > from Section 7.2 of {{FIPS203}}.
> > Prior to decapsulation, the client MUST perform the decapsulation input
> check
> > from Section 7.3 of {{FIPS203}}.
>
> Paraphrasing: "check the stuff you received from the other side before
> using it".  It says nothing of what each peer itself generates.
>
> What am I missing?
>