Hello Valery, Thanks for your suggested text for the abstract, may I suggest a little more concise (albeit less precise) text for the 2nd paragraph (up to the authors of course):
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 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 against conventional (non-quantum) adversaries, performing multiple key exchanges with different post-quantum algorithms along with the classical key exchange algorithms addresses this concern, since the overall security is at least as strong as each individual primitive. Hope this helps -éric On 30/11/2022, 08:48, "iesg on behalf of Valery Smyslov" <iesg-boun...@ietf.org on behalf of s...@elvis.ru> wrote: Hi Éric, > Hello Valery, > > TL;DR: Thanks for your reply and your comments. I agree with them ;-) > > If you want a more detailed reply, then look for EV> below OK, I snipped the text where we have an agreement. > Regards > > -éric [snipped] > > The bullet 2) is a nice explanation about *why* there must be multiple key > > exchanges with different methods. Until reading that part, I was really > > wondering why this I-D was about the link with PQC and multiple key exchanges. > > Should this be mentioned in the abstract already ? > > I don't mind, but as far as I know, IESG wants abstract to be short :-) > If you (and other ADs) think it's a good idea, then we'll add this text. > > EV> I know about short abstract, but they should also give an idea of the content & purpose If it is OK with the IESG we'll extend the abstract with this text. It will look like: 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. Hope it's now clear and not *too* long :-) > > Should "FIPS" be prefixed by "USA" as in "USA FIPS" ? > > I don't know, rely on my co-authors (actually it seems that > this is a well-known organization outside USA, but formally you are right). > > EV> I live a in Federal state as well (Belgium), so while I understand that FIPS stands for the USA one, let's > be inclusive. Up to you and the authors. No problem, will change the text to: USA Federal Information Processing Standards (FIPS) compliance. IPsec is widely used in Federal Information Systems and FIPS certification is an important requirement. However, at the time of writing, none of the algorithms that is believed to be post-quantum is FIPS compliant yet. Nonetheless, it is possible to combine this post-quantum algorithm with a FIPS complaint key establishment method so that the overall design remains FIPS compliant [NISTPQCFAQ]. Is it OK that prefix "USA" is added once and not to every appearance of "FIPS" ? The updated PR is available at: https://github.com/post-quantum/ietf-pq-ikev2/pull/22 Regards, Valery. > > ## Notes > > > > This review is in the ["IETF Comments" Markdown format][ICMF], You can use the > > [`ietf-comments` tool][ICT] to automatically convert this review into > > individual GitHub issues. > > > > [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md > > [ICT]: https://github.com/mnot/ietf-comments > > > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec