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?
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
