[TLS] Re: Deb Cooley's No Objection on draft-ietf-tls-ecdhe-mlkem-03: (with COMMENT)

[Kris Kwiatkowski <[e-mail]>]

Hello,

Thank you Deb for the review. Please find my answers inline below:

> Thanks to Joe Salowey for the shepherd write up explanation of why the registry
> setting is what it is.
>
> Section 4.1, 4.2:  Please check the order and sizes of the client share and
> server shares.  It appears that they don't match between section 4.1 and 4.2.
> For example, for X25519MLKEM768 is 1184 bytes for the MLKEM portion of the
> client share, and 1088 bytes for the server share.  The order of the items in
> () for both the SecP/MLKEM groups are opposite between client share and server
> share (maybe this doesn't matter, but it certainly looks odd).

I have verified the sizes and confirmed that they are correct. Note that, unlike ECDH,
the ML-KEM client and server shares are not the same size: the client transmits a public key,
while the server returns a ciphertext, and these objects have different lengths. Consequently,
the sizes reported in Sections 4.1 and 4.2 are not equal.

The key and ciphertext sizes are derived from Table 3 in FIPS 203.

> Section 5:  I do agree with Gunter that the name of this section is less than
> descriptive.

As per previous email  - this is being addressed here:
https://github.com/tlswg/tls-ecdhe-mlkem/pull/61

Any feedback is more than welcome.

>
> Section 5, FIPS compliance:  Does the order that the shared secrets are
> combined matter?
>
Yes, the order of shares is swapped for X25519 and NIST curves, due to FIPS compliance.
The presentation I've done at IETF 121 provides more details.
- Video:https://youtu.be/46ItvWI_k4Y?list=PLC86T-6ZTP5iW_EW2fpjMvIhLb1uTEkMQ&t=7000
- Slides:https://datatracker.ietf.org/meeting/121/materials/slides-121-tls-post-quantum-hybrid-ecdhe-mlkem-key-agreement-for-tlsv13-00.pdf

As a side note - we know that NIST is planning to allow custom order (it was confirmed by NIST). But at the time of writing, this is not finalized yet.

Kind regards,
Kris