[IPsec] Barry Leiba's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
Barry Leiba has entered the following ballot position for draft-ietf-ipsecme-qr-ikev2-10: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ -- COMMENT: -- Yes, an interesting document, and thanks for that. A few editorial comments: — Section 1 — to be quantum resistant, that is, invulnerable to an attacker with a quantum computer. “Invulnerable” isn’t the same as “not vulnerable”: it has a stronger connotation. You should probably use “not vulnerable” or “resistant” instead. By bringing post- quantum security to IKEv2, this note removes the need to use Make it “this document”, please. This document does not replace the authentication checks that the protocol does; instead, it is done as a parallel check. What’s the antecedent to “it”? Should “it is” instead be “they are”? — Section 3 — when the initiator believes it has a mandatory to use PPK You need hyphens in “mandatory-to-use”. — I also find it interesting that Alexey thought you needed to add a normative reference for “ASCII”, bit not for “base64”. Personally, I think both are sufficiently well known that you need neither. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
Hi Mirja, To try to answer your questions 1) You are right. This is mentioned in a paragraph below that reads [...] or continue without using the PPK (if the PPK was not configured as mandatory and the initiator included the NO_PPK_AUTH notification in the request). But for clarity we will slightly rephrase the sentence you pointed out to only if using PPKs for communication with this responder is optional for the initiator (based on the mandatory_or_not flag), then the initiator MAY include a notification NO_PPK_AUTH in the above message. 2) It is a little hard to include a time that would match all situations. It really depends on the server DoS protection policy and when it kicks on. The initiator cannot really know how fast is considered too fast for the responder so it has to make a conservative decision. Adding a " (e.g., seconds) " would probably suffice here. 3) Waiting for one or two RTTs is probably a good rule. The side-effect could be that the initiator stays waiting for responses for too long which delays the handshake. I am not sure we can mandate in absolute time because it depends on the relative distance between client and server. We can probably include " (e.g., one round-trip) " in the text. 4) I am not sure adding one more notification for downgrade detection adds much here. Remember IKEv2 has subsequent messages to do IKE_AUTH etc and we wanted to not introduce more significant deviations on IKEv2. If the PPK is optional for both peers then downgrade is possible but it is the cost of being flexible to allow some peers to use PPK and some to not. If any of the peers has PPK as mandatory then downgrade will be caught and rejected as explained in the Sec Considerations section, so I think we are OK there. Rgs, Panos -Original Message- From: IPsec On Behalf Of Mirja Kühlewind via Datatracker Sent: Tuesday, January 07, 2020 8:41 AM To: The IESG Cc: ipsec@ietf.org; ipsecme-cha...@ietf.org; david.walterm...@nist.gov; draft-ietf-ipsecme-qr-ik...@ietf.org Subject: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT) Mirja Kühlewind has entered the following ballot position for draft-ietf-ipsecme-qr-ikev2-10: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ -- COMMENT: -- 1) One small question on section 3: "if using PPKs for communication with this responder is optional for the initiator, then the initiator MAY include a notification NO_PPK_AUTH in the above message." This does mean that NO_PPK_AUTH notification should not be sent when the mandatory_or_not flag indicates that PPK is mandatory, right? Or is that a separate configuration? Would be good to clarify in the doc! 2) Section 6 says: "In this situation, it is RECOMMENDED that the initiator caches the negative result of the negotiation for some time and doesn't make attempts to create it again for some time," Would it be possible to give any hints about what "some time" means or at least the order of magnitude? Maybe it could be recommended to wait a couple of seconds? Or how long is it usually expected to take until the half-open connection will be expired? 3) Also here: "then the initiator doesn't abort the exchange immediately, but instead waits some time for more responses (possibly retransmitting the request)." How long should one wait? Probably 1-2 RTTs if the RTT is known or maybe there is some good max value like 500ms or 1s or more...? Is there any risk in waiting too long? 3) And one high-level comment (without knowing to much details about IKEv2): Would it be possible do a downgrade detection, meaning when non-PKK encryption is established the initiator would tell the responser again that it was initially requesting PKK, just to double-check...? ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Alexey Melnikov's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
Thanks Alexey. The text will now read [...] both the PPK and the PPK_ID strings be limited to the base64 character set, namely the 64 ASCII [RFC0020] characters 0-9, A-Z, a-z, + and /. -Original Message- From: IPsec On Behalf Of Alexey Melnikov via Datatracker Sent: Tuesday, January 07, 2020 1:16 PM To: The IESG Cc: ipsec@ietf.org; ipsecme-cha...@ietf.org; david.walterm...@nist.gov; draft-ietf-ipsecme-qr-ik...@ietf.org Subject: [IPsec] Alexey Melnikov's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT) Alexey Melnikov has entered the following ballot position for draft-ietf-ipsecme-qr-ikev2-10: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ -- COMMENT: -- Thank you for this document. One small suggestion below: 5.1. PPK_ID format o PPK_ID_FIXED (2) - in this case the format of the PPK_ID and the PPK are fixed octet strings; the remaining bytes of the PPK_ID are a configured value. We assume that there is a fixed mapping between PPK_ID and PPK, which is configured locally to both the initiator and the responder. The responder can use the PPK_ID to look up the corresponding PPK value. Not all implementations are able to configure arbitrary octet strings; to improve the potential interoperability, it is recommended that, in the PPK_ID_FIXED case, both the PPK and the PPK_ID strings be limited to the base64 character set, namely the 64 characters 0-9, A-Z, a-z, + and /. In order to avoid any doubt, I suggest you make it clear that you mean ASCII encoding here. For this you should add a normative reference to RFC 20 in the last quoted sentence. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Alexey Melnikov's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
Alexey Melnikov has entered the following ballot position for draft-ietf-ipsecme-qr-ikev2-10: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ -- COMMENT: -- Thank you for this document. One small suggestion below: 5.1. PPK_ID format o PPK_ID_FIXED (2) - in this case the format of the PPK_ID and the PPK are fixed octet strings; the remaining bytes of the PPK_ID are a configured value. We assume that there is a fixed mapping between PPK_ID and PPK, which is configured locally to both the initiator and the responder. The responder can use the PPK_ID to look up the corresponding PPK value. Not all implementations are able to configure arbitrary octet strings; to improve the potential interoperability, it is recommended that, in the PPK_ID_FIXED case, both the PPK and the PPK_ID strings be limited to the base64 character set, namely the 64 characters 0-9, A-Z, a-z, + and /. In order to avoid any doubt, I suggest you make it clear that you mean ASCII encoding here. For this you should add a normative reference to RFC 20 in the last quoted sentence. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-ipsecme-qr-ikev2-10: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ -- COMMENT: -- 1) One small question on section 3: "if using PPKs for communication with this responder is optional for the initiator, then the initiator MAY include a notification NO_PPK_AUTH in the above message." This does mean that NO_PPK_AUTH notification should not be sent when the mandatory_or_not flag indicates that PPK is mandatory, right? Or is that a separate configuration? Would be good to clarify in the doc! 2) Section 6 says: "In this situation, it is RECOMMENDED that the initiator caches the negative result of the negotiation for some time and doesn't make attempts to create it again for some time," Would it be possible to give any hints about what "some time" means or at least the order of magnitude? Maybe it could be recommended to wait a couple of seconds? Or how long is it usually expected to take until the half-open connection will be expired? 3) Also here: "then the initiator doesn't abort the exchange immediately, but instead waits some time for more responses (possibly retransmitting the request)." How long should one wait? Probably 1-2 RTTs if the RTT is known or maybe there is some good max value like 500ms or 1s or more...? Is there any risk in waiting too long? 3) And one high-level comment (without knowing to much details about IKEv2): Would it be possible do a downgrade detection, meaning when non-PKK encryption is established the initiator would tell the responser again that it was initially requesting PKK, just to double-check...? ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
