It should really mention the new exchange it introduces in the abstract. Sent using a virtual keyboard on a phone
> On Nov 30, 2022, at 03:32, 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? > >> 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). > >> 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? > > 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
