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