These changes resolve me comments. Russ
> On Oct 21, 2022, at 2:48 AM, CJ Tjhai <cjt=40post-quantum....@dmarc.ietf.org> > wrote: > > Hi Russ, > > Many thanks for the review of our document. Please see our comments inline > below. The updated version of the draft is available here: > https://github.com/post-quantum/ietf-pq-ikev2/blob/master/draft-ietf-ipsecme-ikev2-multiple-ke-00.xml > > <https://github.com/post-quantum/ietf-pq-ikev2/blob/master/draft-ietf-ipsecme-ikev2-multiple-ke-00.xml> > > Best regards, > CJ and Valery > > On Fri, 14 Oct 2022 at 20:24, Russ Housley via Datatracker <nore...@ietf.org > <mailto:nore...@ietf.org>> wrote: > Reviewer: Russ Housley > Review result: Almost Ready > > [ snip ] > > Minor Concerns: > > Section 1.2 says: > > The secrets established from each key exchange are combined in a way > such that should the post-quantum secrets not be present, the derived > shared secret is equivalent to that of the standard IKEv2; on the > other hand, a post-quantum shared secret is obtained if both > classical and post-quantum key exchange data are present. > > What is "post-quantum key exchange data"? > > I am not sure what this is is really trying to tell me. I think it is > trying to make three points. First, the shared secret is based on all of > the key exchange mechanisms that are employed. Second, when one > traditional key exchange mechanism is employed, the result is compatible > with IKEv2 as it is used today. Third, the result is post-quantum safe, > when classical and a post-quantum key exchange mechanisms are used > together. Please reword to be more clear. Further, I suggest that > the discussion of Child SAs be in a separate paragraph. > > > We have changed that paragraph to the following: > > IKE peers perform multiple successive key exchanges to establish an > IKE Security Association (SA). Each exchange produces a piece of > secret and these secrets are combined in a way such that: > > (a) the final shared secret is computed from all of the component > key exchange secret; > > (b) the shared secret as specified in [RFC7296] is obtained unless > both peers support and agree to use the additional key exchanges > introduced in this specification; and > > (c) if any of the component key exchange method is a post-quantum > algorithm, the final shared secret is post-quantum secure. > > > Section 1.2 says: > > The IKE SK_* values are updated after each exchange, and so > the final IKE SA keys depend on all the key exchanges, hence they are > secure if any of the key exchanges are secure. > > I wondered what was meant by "secure", then I learned the answer in > Section 2. I think a forward pointer will help future readers. > > > Yep, good idea. We have added a forward pointer to Section 3.2.2. > > Section 3.1 says: > > Note that this document assumes, that each key exchange method > requires one round trip and consumes exactly one IKE_INTERMEDIATE > exchange. This assumption is valid for all classic key exchange > methods defined so far and for all post-quantum methods currently > known. For hypothetical future key exchange methods requiring > multiple round trips to complete, a separate document should define > how such methods are split into several IKE_INTERMEDIATE exchanges. > > I suggest this go much earlier in Section 3.1. It really is a very > basic design constraint. > > > Agreed. We have moved this paragraph further up in Section 3.1. > > > Nits: > > Section 3.1: s/IKE; however, that can/IKE; however, IKE_INIT messages can/ > > Section 3.2.2 says: > > (derived from the previous IKE_INTERMEDIATE > exchange, or the IKE_SA_INIT if there have not already been any > IKE_INTERMEDIATE exchanges) > > I suggest: > > (derived IKE_SA_INIT for the first use of IKE_INTERMEDIATE, > otherwise from the previous IKE_INTERMEDIATE exchange) > > > Thanks, we have changed them accordingly. > > > Note: > > I did not review the Appendix. > > > > > PQ Solutions Limited (trading as ‘Post-Quantum’) is a private limited company > incorporated in England and Wales with registered number 06808505. > > This email is meant only for the intended recipient. If you have received > this email in error, any review, use, dissemination, distribution, or copying > of this email is strictly prohibited. Please notify us immediately of the > error by return email and please delete this message from your system. Thank > you in advance for your cooperation. > > For more information about Post-Quantum, please visit www.post-quantum.com > <http://www.post-quantum.com/>. > > In the course of our business relationship, we may collect, store and > transfer information about you. Please see our privacy notice at > www.post-quantum.com/privacy-policy/ > <http://www.post-quantum.com/privacy-policy/> to learn about how we use this > information. > -- > last-call mailing list > last-c...@ietf.org > https://www.ietf.org/mailman/listinfo/last-call
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
