Mike Bishop has entered the following ballot position for draft-ietf-ipsecme-ikev2-qr-alt-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-qr-alt/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for working on this document. It's in good shape; I have a few minor issues and several nits that can be incorporated at the discretion of the author and the responsible AD. In Section 3.1, given the MUST abort, I'm guessing the "should" is not a SHOULD. Consider "should treat this as" => "treats this as" (or "MUST treat this as a fatal error and abort...") In Section 4, the terms "QR" and "CRQC" need to be introduced with an expansion on first use, or better yet, simply expanded and the abbreviation not used. ===NITS=== Section 1: "it is the IPsec traffic the one that mostly needs to be protected." => "it is the IPsec traffic that most needs to be protected." "This allows to leverage fresh" => Either "This allows implementations to leverage fresh" or "This allows the use of fresh" "The initiator that" => "An initiator that" CURRENT: If the responder is configured with one of the PPKs which IDs were sent by the initiator and this PPK matches the initiator's one (based on the information from the PPK Confirmation field), CONSIDER: If the responder supports any of the PPKs which the initiator proposed, based on the PPK ID and PPK Confirmation fields, "returns PPK identity" => "returns a PPK identity" CURRENT: If the responder does not have any of the PPKs which IDs were sent by the initiator or it has some of proposed PPKs, but their values mismatch the initiator's ones (based on the information from the PPK Confirmation field), and using PPK is mandatory for the responder, then it MUST return AUTHENTICATION_FAILED notification and abort creating the IKE SA. CONSIDER: If the responder cannot use any of the PPKs proposed by the initiator, based on the PPK ID and PPK Confirmation fields, it MAY return an AUTHENTICATION_FAILED notification and abort creating the IKE SA if configured to require PPK usage. CURRENT: If the responder does not have any of the PPKs which IDs were sent by the initiator or it has some of proposed PPKs, but their values mismatch the initiator's ones (based on the information from the PPK Confirmation field), and using PPK is optional for the responder, then it does not include any PPK_IDENTITY notification to the response. CONSIDER: If the responder cannot use any of the PPKs proposed by the initiator but it is not configured to require PPK usage, it does not include any PPK_IDENTITY notification to the response. "abort creating IKE SA" => "abort creating the IKE SA" "selects PPK" => "selects a PPK" Section 3.1.1: "applying PPK" => "applying the PPK" "with PPK" => "with the PPK" Section 3.2: "supports use PPKs" => "supports using PPKs" Similar language suggestions from Section 3.1. Section 3.2.1: "resulted" => "resulting" Section 4: - "Compared to use PPKs in IKE_AUTH this" => "Compared to using PPKs in IKE_AUTH, this" or "Compared to the use of PPKs in IKE_AUTH, this" - "since PPK is used in authentication too, that gives this exchange a QR protection even against active attacker." => "since the PPK is used in authentication too, this exchange is protected even against an active attacker." Throughout: "Note, that" => "Note that" _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
