Mike Bishop has entered the following ballot position for draft-ietf-ipsecme-ikev2-mlkem-08: 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-ipsecme-ikev2-mlkem/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # IESG review of draft-ietf-ipsecme-ikev2-mlkem-07 CC @MikeBishop ## Comments ### "Abstract", paragraph 1 ``` specifies how to use ML-KEM by itself or as an additional key exchange in IKEv2 along with a traditional key exchange. These ``` Given that both options are "in IKEv2", this could be reworded for clarity. Perhaps "specifies how to use ML-KEM as a key exchange in IKEv2, either by itself or alongside a traditional key exchange."? ### Section 2, paragraph 1 It might be worth being more explicit here that [RFC9370] already defines arbitrary "hybrid" key exchanges, so all that's needed is to have the PQ algorithm assigned a codepoint. ### Section 3, paragraph 7 ``` out-of-band that a responder supports ML-KEM, it SHOULD only include proposals for ML-KEM or abort the negotiation if the responder ``` This could be read as recommending only non-hybrid proposals, which I think is not the intent. ### Inclusive language Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term `man`; alternatives might be `individual`, `people`, `person` ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Typos #### Section 1, paragraph 1 ``` - communications in the future after a CRQC became available to them - which is also known as a 'harvest-now-decrypt-later' attack. Such - -------------- + communications in the future after a CRQC became available to them, + + ``` #### Section 1, paragraph 3 ``` - algorithms, another use of a PQ/T Hybrid key exchanges in IKEv2 is to - -- ``` ### Section 2.1, paragraph 8 ``` ciphertext size for this ML-KEM parameter may not push the UDP packet ``` Is this to be understood as "might not (but also might)" or as "cannot" / "do not"? ### Section 3, paragraph 6 Consider "IKEv2 downgrades are" or "IKEv2's vulnerability to downgrades is" ### Grammar/style #### Section 1.1, paragraph 3 ``` turn a distinguished error value. Instead it will always produce an ss value ^^^^^^^ ``` A comma may be missing after the conjunctive/linking adverb "Instead". #### Section 3, paragraph 7 ``` t an IKE_INTERMEDIATE exchange. Subsequently the peers can rekey the initial ^^^^^^^^^^^^ ``` A comma may be missing after the conjunctive/linking adverb "Subsequently". _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
