TL;DR: Yes, thank you, all of your changes look great too me... On Wed, Nov 30, 2022 at 3:31 AM, Valery Smyslov <[email protected]> wrote:
> Hi Warren, > > thank you for your comments. Please see inline. > > -----Original Message----- > From: Warren Kumari via Datatracker [mailto:[email protected]] Sent: > Wednesday, November 30, 2022 1:19 AM > To: The IESG > Cc: [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; [email protected] > Subject: Warren Kumari's No Objection on > draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT) > > Warren Kumari has entered the following ballot position for > draft-ietf-ipsecme-ikev2-multiple-ke-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/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-multiple-ke/ > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for writing this document (and also making it easy for someone > like me to understand :-)) Also thanks to Geoff Huston for his DNSDOR > review > (https://datatracker.ietf.org/doc/ > review-ietf-ipsecme-ikev2-multiple-ke-07-dnsdir-lc-huston-2022-10- 10/) > > I have a few non-blocking comments -- feel free to address them or not. > > I think that moving Section 2, Bullet 2 towards to top of the document > would help the reader better understand why this document exists... > > Éric has suggested to put this or similar text to the Abstract, so it is > now there. The Abstract now is: > > This document describes how to extend the Internet Key Exchange Protocol > Version 2 (IKEv2) to allow multiple key exchanges to take place while > computing a shared secret during a Security Association (SA) setup. > > The primary application of this feature in IKEv2 is the ability to perform > one or more post-quantum key exchanges in conjunction with the classical > (Elliptic Curve) Diffie-Hellman (EC)DH key exchange, so that the resulting > shared key is resistant against quantum computer attacks. Since there is > currently no post-quantum key exchange that is trusted at the level that > (EC)DH is trusted for against conventional (non-quantum) adversaries, > performing multiple key exchanges with different post-quantum algorithms > along with the well-established classical key exchange algorithms addresses > this concern, since the overall security is at least as strong as each > individual primitive. > > Another possible application for this extension is the ability to combine > several key exchanges in situations when no single key exchange algorithm > is trusted by both initiator and responder. > > This document updates RFC7296 by renaming a transform type 4 from > "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renaming a > field in the Key Exchange Payload from "Diffie-Hellman Group Num" to "Key > Exchange Method". It also renames an IANA registry for this transform type > from "Transform Type 4 - Diffie-Hellman Group Transform IDs" to > "Transform Type 4 - Key Exchange Method Transform IDs". These changes > generalize key exchange algorithms that can be used in IKEv2. > > Is it OK? > Yes, thank you! > 1: "While solving such a problem remains difficult with current computing > power, it is believed that general purpose quantum computers will be able > to solve this problem, implying that the security of IKEv2 is compromised." > > 'solving such a problem remains difficult with current computing power' > implies that they *can* be solved with current computing power, while 'it > is *believed* that general purpose quantum computers will be able to solve > this problem' implies that quantum only *might* be able to solve > them...this makes it sound like quantum machines are less of a concern than > current ones :-). Perhaps > 'general purpose quantum computers will *easily* be able to solve this > problem'? Or 'solving such a problem is infeasible with current computing > power'? (handwaving away trivial parameters) My suggestion isn't great, but > hopefully I've managed to explain my concern? > > I see your point. I would use one of your suggestions, unless my > co-authors disagree: > > While solving such > a problem remains infeasible with current computing power, it is believed > that general purpose quantum computers will be able to solve this problem, > implying that the security of IKEv2 is compromised. > > (I don't like "easily", since it's very subjective). > Awesome, thank you. > 2: Design Criteria - 3) Focus on post-quantum confidentiality. I > understand what this is trying to say, but it feels very disjointed. I > don't really have any suggested test to fix it, but just dropping the last > sentence > (or folding it into an earlier one) would make it much much easier to > read. > > What if we rewrite this para a bit? > > Focus on post-quantum confidentiality. A passive attacker can store all > monitored encrypted IPsec communication today and decrypt it once a > quantum computer is available in the future. This attack can have serious > consequences that won't be visible for years to come. On the other hand, an > attacker can only perform active attacks such as impersonation of the > communicating peers once a quantum computer is available, sometime in the > future. Thus, this specification focuses on confidentiality due to the > urgency of this problem and presents a defense against the serious attack > described above, but it does not address authentication since it is less > urgent at this stage. > > Is it better now? > Yup, I think so. Thank you again, W > The updated PR is available at: > https://github.com/post-quantum/ietf-pq-ikev2/pull/22 > > Regards, > Valery. >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
