On Thu, Mar 27, 2025 at 10:10:49AM +0000, Sun Shuzhou wrote:
> I have read this draft and have two questions.
>
> 1. X25519MLKEM768 is the concatenation of ML-KEM and X25519. Why
> SecP256r1MLKEM768/SecP384r1MLKEM1024 use a different order? ML-KEM
> part comes after the EC share.
Inconsequential historical detail. The names are now in the IANA
registry and already supported in multiple deployed systems, so
not worth fixing. FWIW, the historical motivation is tangentially
related to the point in time validation status of various FIPS
algorithms, but this is no longer relevant.
> 2. In Section 3.1.3. Server share:
>
> When the SecP256r1MLKEM768 group is negotiated, ... The size of the
> server share is 1153 bytes (1088 bytes for the ML-KEM part and 65
> bytes for secp256r1).
>
> When the SecP384r1MLKEM1024 group is negotiated, ... The size of the
> server share is 1665 bytes (1568 bytes for the ML-KEM part and 97
> bytes for secp384r1)
Noting the sizes in an order that is different from the wire order is
not IMHO a significant issue, given explicit language defining the wire
order elsewhere, ... though of course switching the order of exposition,
just in case someone might somehow miss the definitive text, would be fine.
--
Viktor.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
