Deb Cooley has entered the following ballot position for draft-ietf-tls-ecdhe-mlkem-03: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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). Section 5: I do agree with Gunter that the name of this section is less than descriptive. Section 5, FIPS compliance: Does the order that the shared secrets are combined matter? _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
