| These changes resolve me comments.
Russ
Hi Russ,
Best regards, CJ and Valery On Fri, 14 Oct 2022 at 20:24, Russ Housley via Datatracker < noreply@xxxxxxxx> 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.
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/ to learn about how we use this information.-- last-call mailing list last-call@xxxxxxxxhttps://www.ietf.org/mailman/listinfo/last-call
|
