Valery, it works fine for me. Obtenir Outlook pour Android<https://aka.ms/AAb9ysg>
________________________________ De : Valery Smyslov <s...@elvis.ru> Envoyé : jeudi 1 décembre 2022, 12:25 À : Eric Vyncke (evyncke) <evyn...@cisco.com>; 'The IESG' <i...@ietf.org> Cc : draft-ietf-ipsecme-ikev2-multiple...@ietf.org <draft-ietf-ipsecme-ikev2-multiple...@ietf.org>; ipsecme-cha...@ietf.org <ipsecme-cha...@ietf.org>; ipsec@ietf.org <ipsec@ietf.org>; kivi...@iki.fi <kivi...@iki.fi>; charl...@computer.org <charl...@computer.org>; g...@apnic.net <g...@apnic.net> Objet : RE: Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT) Hi Éric, > -----Original Message----- > From: Eric Vyncke (evyncke) [mailto:evyn...@cisco.com] > Sent: Thursday, December 01, 2022 1:41 PM > To: Valery Smyslov; 'The IESG' > Cc: draft-ietf-ipsecme-ikev2-multiple...@ietf.org; ipsecme-cha...@ietf.org; > ipsec@ietf.org; > kivi...@iki.fi; charl...@computer.org; g...@apnic.net > Subject: Re: Éric Vyncke's No Objection on > draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT) > > 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. I think in this text an important consideration is missing - that we now have enough trust in (EC)DH against conventional computers, but we don't have this level of trust in most post-quantum algorithms (both against conventional and quantum adversaries). That's why we want to combine them. Ah, I can see now that the original text can be interpreted, that we don't trust post-quantum key exchange only against conventional adversaries... We can modify the text as follows (make it more concise, less precise, but still correct, IMHO): Since there is currently no post-quantum key exchange that is studied at the level that (EC)DH is studied, 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. Is it OK? Regards, Valery. > > 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