Re: [Last-Call] Genart last call review of draft-ietf-ipsecme-ikev2-multiple-ke-07

[Russ Housley <[e-mail]>]

These changes resolve me comments.

Russ

> On Oct 21, 2022, at 2:48 AM, CJ Tjhai <cjt=[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/last-call