Re: [auth48] AUTH48: RFC-to-be 9370 <draft-ietf-ipsecme-ikev2-multiple-ke-12> for your review

[CJ Tjhai <[e-mail]>]

Hi Megan,

I approve the publication of this draft.

Best regards,
CJ


On Fri, 31 Mar 2023 at 15:16, Megan Ferguson <[e-mail]> wrote:

> Valery,
>
> We have marked you and Roman as having approved at the AUTH48 status
> page.  We will await approvals from your coauthors prior to moving the
> document forward in the publication process.
>
> The AUTH48 status page is here:
> https://www.rfc-editor.org/authors/rfc9370-auth48diff.html
>
> Thank you.
>
> RFC Editor/mf
>
>
> > On Mar 30, 2023, at 8:36 PM, Valery Smyslov <[e-mail]> wrote:
> >
> > Hi Megan,
> >
> > I approve the publication. Thank you for your patience and cooperation.
> >
> > Regards,
> > Valery.
> >
> >> -----Original Message-----
> >> From: Megan Ferguson <[e-mail]>
> >> Sent: 30 марта 2023 г. 22:44
> >> To: Valery Smyslov <[e-mail]>; Roman Danyliw <[e-mail]>
> >> Cc: [e-mail]; [e-mail];
> [e-mail];
> >> [e-mail]; [e-mail]; [e-mail];
> >> [e-mail]; [e-mail]; ipsecme-
> >> [e-mail]; Tero Kivinen <[e-mail]>;
> [e-mail]
> >> Subject: Re: AUTH48: RFC-to-be 9370
> <draft-ietf-ipsecme-ikev2-multiple-ke-
> >> 12> for your review
> >>
> >> Valery,
> >>
> >> Thank you for sending this along.  We have incorporated this change
> into our
> >> files.
> >>
> >> Please review and confirm that the change appears as desired.
> >>
> >> The files have been posted here (please refresh):
> >> https://www.rfc-editor.org/authors/rfc9370.txt
> >> https://www.rfc-editor.org/authors/rfc9370.pdf
> >> https://www.rfc-editor.org/authors/rfc9370.html
> >> https://www.rfc-editor.org/authors/rfc9370.xml
> >>
> >> The relevant diff files have been posted here (please refresh):
> >> https://www.rfc-editor.org/authors/rfc9370-diff.html (comprehensive
> diff)
> >> https://www.rfc-editor.org/authors/rfc9370-rfcdiff.html (comprehensive
> >> rfcdiff) https://www.rfc-editor.org/authors/rfc9370-lastdiff.html
> (last version
> >> to this) https://www.rfc-editor.org/authors/rfc9370-lastrfcdiff.html
> (last
> >> version to this rfcdiff)
> >>
> >> The AUTH48 status page is here:
> >> https://www.rfc-editor.org/authors/rfc9370-auth48diff.html
> >>
> >> Thank you.
> >>
> >> RFC Editor/mf
> >>
> >>> On Mar 28, 2023, at 11:06 AM, Valery Smyslov <[e-mail]> wrote:
> >>>
> >>> Hi Megan,
> >>>
> >>> overall, the document looks good. We still have one (hopefully the
> last)
> >> minor change request:
> >>>
> >>> Section 2.2.1:
> >>> OLD:
> >>>  Below is an example of the SA payload in the initiator's IKE_SA_INIT
> >>>  request message.  Here, the abbreviation "ADDKEi" is used to denote
> >>>  the i-th ADDKE Transform Type defined in this document; the
> >>>  abbreviation "KE" is used for the Key Exchange transform, which this
> >>>  document renames from the Diffie-Hellman Group transform.
> >>>
> >>> NEW:
> >>>  Below is an example of the SA payload in the initiator's IKE_SA_INIT
> >>>  request message.  Here, the abbreviation "KE" is used for the Key
> Exchange
> >> transform, which this
> >>>  document renames from the Diffie-Hellman Group transform.
> >>>
> >>> This piece of text somehow escaped our attention last time, sorry.
> >>> With the introduction of all ADDKE Transform Types earlier in this
> >>> section, there is little sense to have the text describing again what
> >>> it means, we only need to describe the KE Transform Type.
> >>>
> >>> Thank you,
> >>> Valery.
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Megan Ferguson <[e-mail]>
> >>>> Sent: 28 марта 2023 г. 0:31
> >>>> To: Valery Smyslov <[e-mail]>; [e-mail]
> >>>> Cc: [e-mail]; [e-mail]; mt@post-
> >>>> quantum.com; [e-mail]; [e-mail];
> >>>> [e-mail]; [e-mail]; ipsecme-
> >>>> [e-mail]; Tero Kivinen <[e-mail]>; Roman Danyliw
> >>>> <[e-mail]>; [e-mail]
> >>>> Subject: Re: [AD] AUTH48: RFC-to-be 9370
> >>>> <draft-ietf-ipsecme-ikev2-multiple-
> >>>> ke-12> for your review
> >>>>
> >>>> Hi Valery and *AD,
> >>>>
> >>>> [*AD - please review and approve the changes highlighted in the
> following
> >> diff:
> >>>> https://www.rfc-editor.org/authors/rfc9370-ads-diff.html]
> >>>>
> >>>> Thank you for sending along the updated XML file.  Please review the
> >>>> new versions posted below.
> >>>>
> >>>> Please review carefully and let us know if any further changes are
> >>>> necessary as we do not make changes once the document is published as
> >> an RFC.
> >>>>
> >>>> The files have been posted here (please refresh):
> >>>> https://www.rfc-editor.org/authors/rfc9370.txt
> >>>> https://www.rfc-editor.org/authors/rfc9370.pdf
> >>>> https://www.rfc-editor.org/authors/rfc9370.html
> >>>> https://www.rfc-editor.org/authors/rfc9370.xml
> >>>>
> >>>> The relevant diff files have been posted here (please refresh):
> >>>> https://www.rfc-editor.org/authors/rfc9370-diff.html (comprehensive
> >>>> diff) https://www.rfc-editor.org/authors/rfc9370-rfcdiff.html
> >>>> (comprehensive
> >>>> rfcdiff)  https://www.rfc-editor.org/authors/rfc9370-lastdiff.html
> >>>> (last version to this)
> >>>> https://www.rfc-editor.org/authors/rfc9370-lastrfcdiff.html (last
> >>>> version to this rfcdiff)
> >>>>
> >>>> The AUTH48 status page is here:
> >>>> https://www.rfc-editor.org/authors/rfc9370-auth48diff.html
> >>>>
> >>>> Thank you.
> >>>>
> >>>> RFC Editor/mf
> >>>>
> >>>>> On Mar 24, 2023, at 10:10 PM, Valery Smyslov <[e-mail]> wrote:
> >>>>>
> >>>>> Hi Megan,
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Megan Ferguson <[e-mail]>
> >>>>>> Sent: 17 марта 2023 г. 6:47
> >>>>>> To: Valery Smyslov <[e-mail]>
> >>>>>> Cc: [e-mail]; [e-mail]; mt@post-
> >>>>>> quantum.com; [e-mail]; [e-mail];
> >>>>>> [e-mail]; [e-mail];
> >>>>>> ipsecme- [e-mail]; [e-mail]; [e-mail];
> >>>>>> [e-mail]; [e-mail]
> >>>>>> Subject: Re: AUTH48: RFC-to-be 9370
> >>>>>> <draft-ietf-ipsecme-ikev2-multiple-ke-
> >>>>>> 12> for your review
> >>>>>>
> >>>>>> Valery and *ADs,
> >>>>>>
> >>>>>> [*ADs - please review and approve the changes highlighted in the
> >>>>>> following
> >>>>>> diff:
> >>>>>>  https://www.rfc-editor.org/authors/rfc9370-lastdiff.html]
> >>>>>>
> >>>>>> We’ve made the updates as requested by the authors.
> >>>>>>
> >>>>>> Regarding this issue:
> >>>>>>>> [rfced] We have updated Table 1 as suggested in issue 32.  Would
> >>>>>>>> you like to add the short names anywhere else in the doc?
> >>>>>>>
> >>>>>>> Yes, please do it whenever Additional Key Exchange Types are
> >> mentioned.
> >>>>>>> Please use AKE* where no concrete type is mentioned.
> >>>>>>
> >>>>>> Please note that we’ve created a separate diff file containing the
> >>>>>> updates to “AKE*” to ensure we understood your intention.  Please
> >>>>>> see
> >>>>>> https://www.rfc- editor.org/authors/rfc9370-alternate-diff.html and
> >>>>>> let us know if the changes appear as you expected.  If so, we will
> >>>>>> adopt this
> >>>> file.
> >>>>>
> >>>>> We have some discussion among authors and come to the conclusion,
> >>>>> that first it is not a good idea to apply this diff, and mote
> >>>>> importantly, the abbreviation "AKE" is not a good one, since it may
> >>>>> be confused with widely used "Authenticated Key Exchange" meaning.
> >>>>>
> >>>>> After some internal discussion we decided, that it is better to use
> "ADDKE"
> >>>> instead.
> >>>>> Since there are too many places it is used in for OLD/NEW style
> >>>>> changes, we prepared an xml file based on your latest XML (attached).
> >>>>>
> >>>>> Can you please use it?
> >>>>>
> >>>>> The other updates look good.
> >>>>>
> >>>>> Regards,
> >>>>> Valery.
> >>>>>
> >>>>>> The other updates can be reviewed in the files below.  Please
> >>>>>> review carefully and let us know if any further changes are
> >>>>>> necessary as we do not make changes once the document is published
> as
> >> an RFC.
> >>>>>>
> >>>>>> The files have been posted here (please refresh):
> >>>>>> https://www.rfc-editor.org/authors/rfc9370.txt
> >>>>>> https://www.rfc-editor.org/authors/rfc9370.pdf
> >>>>>> https://www.rfc-editor.org/authors/rfc9370.html
> >>>>>> https://www.rfc-editor.org/authors/rfc9370.xml
> >>>>>>
> >>>>>> The relevant diff files have been posted here (please refresh):
> >>>>>> https://www.rfc-editor.org/authors/rfc9370-diff.html (comprehensive
> >>>>>> diff)  https://www.rfc-editor.org/authors/rfc9370-rfcdiff.html
> >>>>>> (comprehensive
> >>>>>> rfcdiff)
> >>>>>> https://www.rfc-editor.org/authors/rfc9370-lastdiff.html (last
> >>>>>> version to this)
> >>>>>> https://www.rfc-editor.org/authors/rfc9370-lastrfcdiff.html (last
> >>>>>> version to this rfcdiff)
> >>>>>>
> >>>>>> The AUTH48 status page is here:
> >>>>>> https://www.rfc-editor.org/authors/rfc9370-auth48diff.html
> >>>>>>
> >>>>>> Thank you.
> >>>>>>
> >>>>>> RFC Editor/mf
> >>>>>>
> >>>>>>> On Mar 9, 2023, at 10:36 AM, Valery Smyslov <[e-mail]> wrote:
> >>>>>>>
> >>>>>>>> Valery,
> >>>>>>>
> >>>>>>> Hi Megan,
> >>>>>>>
> >>>>>>> thank you, please, see inline.
> >>>>>>>
> >>>>>>>> Thank you for your reply and guidance.  We have updated the
> >>>>>>>> document as requested.  However, please note that we had some
> >>>>>>>> further comments/questions on your responses to our original
> >>>>>>>> queries marked with [rfced] below (other portions of your
> >>>>>>>> original message have been
> >>>>>> snipped).  We have also added 4 additional notes/comments below
> >>>>>> (marked a- d).
> >>>>>>>>
> >>>>>>>> Note that we will await resolution of each issue prior to moving
> >>>>>>>> the document forward in the publication process.
> >>>>>>>>
> >>>>>>>> a) Note - the following comment was left by the authors in the
> >>>>>>>> XML file.  Please confirm no further updates are necessary and
> >>>>>>>> that we may
> >>>>>> delete this comment from the file:
> >>>>>>>>
> >>>>>>>> <!--  Note that the negotiated transform types (the encryption
> >>>>>>>> type, integrity type, prf type) are not modified. (do we need to
> >>>>>>>> say this?) —>
> >>>>>>>
> >>>>>>> Please, delete this comment.
> >>>>>>>
> >>>>>>>> b) Please note that any updates to the IANA section will be
> >>>>>>>> communicated to IANA by the RPC once
> >>>>>>>> AUTH48 completes (all authors approve).
> >>>>>>>
> >>>>>>> OK, thank you for the information.
> >>>>>>>
> >>>>>>>> c) FYI - we have added an informative reference entry to RFC 8247
> >>>>>>>> to maintain a 1:1 relationship with citations in the document
> >>>>>>>> (see Section 3.1).  Please let us know any objections or if this
> >>>>>>>> document should
> >>>>>> be listed as normative.
> >>>>>>>
> >>>>>>> OK. There is no need to make this reference normative, please keep
> >>>>>>> it
> >>>>>> informative.
> >>>>>>>
> >>>>>>>> d) Please carefully review the text following Table 1 that
> >>>>>>>> describes the
> >>>>>> designated expert instructions.
> >>>>>>>> There has been a change from IKE to IKEv2.  We assume this is as
> >>>>>>>> intended (to match
> >>>>>>>> https://www.iana.org/assignments/ikev2-parameters/ikev2-
> >>>>>> parameters.xhtml#ikev2-parameters-3).  If not, please let us know
> >>>>>> if updates to the document or registry note are necessary.
> >>>>>>>
> >>>>>>> The text is correct. The change from "IKE" to "IKEv2" was intended.
> >>>>>>> The IANA page is for IKE version 2, so we think that these
> >>>>>>> instructions should
> >>>>>> also be for IKE version 2.
> >>>>>>>
> >>>>>>>> The files have been posted here (please refresh):
> >>>>>>>> https://www.rfc-editor.org/authors/rfc9370.txt
> >>>>>>>> https://www.rfc-editor.org/authors/rfc9370.pdf
> >>>>>>>> https://www.rfc-editor.org/authors/rfc9370.html
> >>>>>>>> https://www.rfc-editor.org/authors/rfc9370.xml
> >>>>>>>>
> >>>>>>>> The relevant diff files have been posted here (please refresh):
> >>>>>>>> https://www.rfc-editor.org/authors/rfc9370-diff.html
> >>>>>>>> (comprehensive diff)
> >>>>>>>> https://www.rfc-editor.org/authors/rfc9370-rfcdiff.html
> >>>>>>>> (comprehensive
> >>>>>> rfcdiff)
> >>>>>>>> https://www.rfc-editor.org/authors/rfc9370-auth48diff.html
> >>>>>>>> (AUTH48 changes only)
> >>>>>>>>
> >>>>>>>> The AUTH48 status page is here:
> >>>>>>>> https://www.rfc-editor.org/authors/rfc9370-auth48diff.html
> >>>>>>>>
> >>>>>>>> Please see further unresolved issues below marked with [rfced]:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Feb 28, 2023, at 7:00 AM, Valery Smyslov <[e-mail]>
> wrote:
> >>>>>>>>>
> >>>>>>>>> Hi RFC Editor,
> >>>>>>>>>
> >>>>>>>>>> Authors,
> >>>>>>>>>>
> >>>>>>>>>> While reviewing this document during AUTH48, please resolve (as
> >>>>>>>>>> necessary) the following questions, which are also in the XML
> file.
> >>>>>>>>>>
> >>>>>>>>>> 1) <!-- [rfced] Please note that the title of the document has
> >>>>>>>>>> been
> >>>>>> updated as follows:
> >>>>>>>>>>
> >>>>>>>>>> Abbreviations have been expanded per Section 3.6 of RFC 7322
> >>>>>>>>>> ("RFC Style Guide"). Please review.
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>> Multiple Key Exchanges in IKEv2
> >>>>>>>>>>
> >>>>>>>>>> Current:
> >>>>>>>>>> Multiple Key Exchanges in Internet Key Exchange Protocol
> >>>>>>>>>> Version
> >>>>>>>>>> 2
> >>>>>>>>>> (IKEv2)
> >>>>>>>>>> -->
> >>>>>>>>>
> >>>>>>>>> I have no problems with this title.
> >>>>>>>>>
> >>>>>>>>> Out of curiosity, one question for my education as non-native
> >> speaker:
> >>>>>>>>> in some RFCs with similar title structure (7427, 7634, 8784
> >>>>>>>>> etc.) "the" is used when referring to "Internet Key Exchange
> >> Protocol".
> >>>>>>>>> I wonder why it is not used here (again, no complaints, just for
> >>>>>>>>> my
> >>>>>> education)?
> >>>>>>>> [rfced] You are correct.  This is an oversight on our part. We
> >>>>>>>> have updated
> >>>>>> as you suggested.
> >>>>>>>
> >>>>>>> Thank you.
> >>>>>>>
> >>>>>>>> [snip]
> >>>>>>>>>
> >>>>>>>>>> 4) <!-- [rfced] The meaning of the term "(EC)DH" is not
> >>>>>>>>>> described in the  document until the Introduction.  May we
> >>>>>>>>>> update the Abstract as  follows to avoid its use before its
> >> explanation?
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>> 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 as well-studied
> >>>>>>>>>> as (EC)DH, 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.
> >>>>>>>>>>
> >>>>>>>>>> Perhaps:
> >>>>>>>>>> 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
> >>>>>>>>>> (ECDH) key exchange so that the resulting shared key is
> >>>>>>>>>> resistant against quantum-computer attacks.  There is currently
> >>>>>>>>>> no post-quantum key exchange that is as  well studied as ECDH.
> >>>>>>>>>> Therefore, 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.
> >>>>>>>>>> -->
> >>>>>>>>>
> >>>>>>>>> I believe the meaning of "(EC)DH" here is that either DH (based
> >>>>>>>>> on MODP groups) or ECDH (based on elliptic curve groups) may be
> >>>>>>>>> used, so the suggested text is not fully equivalent. If y
> >>>>>>>>>
> >>>>>>>>> PROPOSED TEXT:
> >>>>>>>>> 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 Diffie-Hellman (DH) or Elliptic Curve
> >>>>>>>>> Diffie-Hellman
> >>>>>>>>> (ECDH) key exchange so that the resulting shared key is
> >>>>>>>>> resistant against quantum-computer attacks.  There is currently
> >>>>>>>>> no post-quantum key exchange that is as well studied as DH and
> >> ECDH.
> >>>>>>>>> Therefore, 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.
> >>>>>>>>>
> >>>>>>>> [rfced] With the movement of this text from the Abstract to the
> >>>>>>>> Intro, the term “(EC)DH” will have been introduced before this
> >>>>>>>> occurrence - causing us to withdraw our previous question.
> >>>>>>>> Please let us
> >>>>>> know if you would still like to update to the proposed text or if
> >>>>>> this text may remain as it currently appears.
> >>>>>>>
> >>>>>>> Since use of “(EC)DH” is no more an issue, we think that the text
> >>>>>>> in
> >>>>>> Introduction can be further updated:
> >>>>>>>
> >>>>>>> CURRENT:
> >>>>>>> It is essential to have an 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 to quantum-computer attacks.
> >>>>>>>
> >>>>>>> PROPOSED:
> >>>>>>> It is essential to have an ability to perform one or more post-
> >>>>>>> quantum key exchanges in conjunction with an (EC)DH key exchange,
> >>>>>>> so
> >>>>>> that the resulting
> >>>>>>> shared key is resistant to quantum-computer attacks.
> >>>>>>>
> >>>>>>>> [snip]
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> 6) <!-- [rfced] Please clarify what "produces a piece of secret"
> >>>>>>>>>> means.  Would the suggested rephrase ("produces part of a
> >>>>>>>>>> shared
> >>>>>>>>>> secret") retain the original meaning?  Or would something else
> >>>>>>>>>> be  more accurate?
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>> 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.
> >>>>>>>>>>
> >>>>>>>>>> Suggested:
> >>>>>>>>>> Each exchange produces part of
> >>>>>>>>>> a shared secret, and then these parts are combined in such a
> >>>>>>>>>> way
> >>>>>>>>>> that:
> >>>>>>>>>>
> >>>>>>>>>> (a)  the completed final shared secret is computed from all of
> the
> >>>>>>>>>>    components of the 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 part of the component key exchange method is a
> >>>>>>>>>>    post-quantum algorithm, the final shared secret is
> post-quantum
> >>>>>>>>>>      secure.
> >>>>>>>>>> -->
> >>>>>>>>>
> >>>>>>>>> May I propose the following text:
> >>>>>>>>>
> >>>>>>>>> PROPOSED:
> >>>>>>>>> Each exchange produces some shared 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 shared secrets;
> >>>>>>>>>
> >>>>>>>>> (b) unless both peers support and agree to use the additional
> >>>>>>>>> key
> >>>>>> exchanges
> >>>>>>>>>   introduced in this specification, the final shared secret
> >>>>>>>>> equivalent to
> >>>>>> specified in [RFC7296]
> >>>>>>>>>   is obtained; and
> >>>>>>>>
> >>>>>>>> [rfced] The text in (b) may need some further updates.
> >>>>>>>> Specifically, what is the final shared secret equivalent to?
> >>>>>>>
> >>>>>>> Please, update  clause (b):
> >>>>>>>
> >>>>>>> CURRENT:
> >>>>>>> (b)  unless both peers support and agree to use the additional key
> >>>>>>>     exchanges introduced in this specification, the final shared
> >>>>>>>     secret equivalent to specified in [RFC7296] is obtained; and
> >>>>>>>
> >>>>>>> PROPOSED:
> >>>>>>> (b)  unless both peers support and agree to use the additional key
> >>>>>>>     exchanges introduced in this specification, the final shared
> >>>>>>>     secret equivalent to the shared secret as specified in
> >>>>>>> [RFC7296] is obtained; and
> >>>>>>>
> >>>>>>>>> (c)  if any part of the component key exchange method is a
> >>>>>>>>>  post-quantum algorithm, the final shared secret is post-quantum
> >>>>>>>>>  secure.
> >>>>>>>>>
> >>>>>>>>> So, my points here are. The word "part" implies (as it sounds to
> >>>>>>>>> me) that the result is simple concatenation (or something like
> >>>>>>>>> this), while in fact the way the individual shared secrets are
> >>>>>>>>> combined into a final shared secret is more complex. Then, in
> >>>>>>>>> the
> >>>>>>>>> (b) clause the point is that if this extension is not supported
> >>>>>>>>> , the result of combining a single (EC)DH key exchange into a
> >>>>>>>>> final shared secret is the same, as specified in RFC 7296. The
> (c) clause
> >> is fine.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> [snip]
> >>>>>>>>>
> >>>>>>>>>> 24) <!-- [rfced] The final "sentence" of this paragraph is a
> noun
> >> phrase.
> >>>>>>>>>> Please clarify and reword this text.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Original:
> >>>>>>>>>>  More importantly, fragmenting the messages in this way
> >>>>>>>>>>  may leave the system to be more prone to denial of service
> (DoS)
> >>>>>>>>>>  attacks.  By using IKE_INTERMEDIATE to transport the large
> post-
> >>>>>>>>>>  quantum key exchange payloads, and using the generic IKEv2
> >>>>>>>>>>  fragmentation protocol [RFC7383] solve the issue.
> >>>>>>>>>> -->
> >>>>>>>>>
> >>>>>>>>> PROPOSED:
> >>>>>>>>> More importantly, fragmenting the messages in this way may leave
> >>>>>>>>> the system to be more prone to denial of service (DoS) attacks.
> >>>>>>>>> Using IKE_INTERMEDIATE to transport the large post- quantum key
> >>>>>>>>> exchange payloads and using the generic IKEv2 fragmentation
> >>>>>>>>> protocol [RFC7383] solve the issue.
> >>>>>>>>>
> >>>>>>>> [rfced] FYI - We rewrote this text slightly as the original was
> >>>>>>>> tripping us up with the subject/verb agreement.  Please review
> >>>>>>>> the current
> >>>>>> text and let us know any objections.
> >>>>>>>
> >>>>>>> Please also add a reference to RFC 9242:
> >>>>>>>
> >>>>>>> CURRENT:
> >>>>>>>   More importantly, fragmenting the messages in this way
> >>>>>>>   may leave the system to be more prone to denial-of-service (DoS)
> >>>>>>>   attacks.  This issue can be solved using IKE_INTERMEDIATE to
> >>>>>>>   transport the large post-quantum key exchange payloads and using
> >>>>>>>   the generic IKEv2 fragmentation protocol [RFC7383].
> >>>>>>>
> >>>>>>> NEW:
> >>>>>>>   More importantly, fragmenting the messages in this way
> >>>>>>>   may leave the system to be more prone to denial-of-service (DoS)
> >>>>>>>   attacks.  This issue can be solved using IKE_INTERMEDIATE
> [RFC9242]
> >> to
> >>>>>>>   transport the large post-quantum key exchange payloads and using
> >>>>>>>   the generic IKEv2 fragmentation protocol [RFC7383].
> >>>>>>>
> >>>>>>>>>> 25) <!-- [rfced] Terminology: We had the following questions
> >>>>>>>>>> related to terminology that appeared throughout the text.
> >>>>>>>>>>
> >>>>>>>>>> a) The following terminology appears to be used inconsistently.
> >>>>>>>>>> Please review these occurrences and let us know if/how they may
> >>>>>>>>>> be made consistent.
> >>>>>>>>>>
> >>>>>>>>>> additional key exchange vs. Additional Key Exchange
> >>>>>>>>>
> >>>>>>>>> The intention was that "additional key exchange" is used to
> >>>>>>>>> describe the process of exchanging keys
> >>>>>>>> itself,
> >>>>>>>>> while "Additional Key Exchange" refers to transform name. Let us
> >>>>>>>>> know if
> >>>>>> they are used inconsistently.
> >>>>>>>>>
> >>>>>>>>>> Additional Key Exchange type vs. Additional Key Exchange
> >>>>>>>>>> Transform
> >>>>>> Type vs.
> >>>>>>>>>> Additional Key Exchange transforms
> >>>>>>>>>
> >>>>>>>>> These must be the same. Please replace "Additional Key Exchange
> >>>>>>>>> type" and "Additional Key Exchange
> >>>>>>>> transform"
> >>>>>>>>> with "Additional Key Exchange Transform Type".
> >>>>>>>>
> >>>>>>>> [rfced] Please review our updates to the above in the diff files
> >>>>>>>> and let us know if any further changes are necessary.  In the
> >>>>>>>> following instance,
> >>>>>> we were not sure if updates should be made:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Current:
> >>>>>>>> ...corresponding Additional Key Exchange(s) in the
> IKE_INTERMEDIATE
> >>>>>>>>       exchange(s) MUST NOT take place.
> >>>>>>>>
> >>>>>>>> Perhaps:
> >>>>>>>> ...corresponding Additional Key Exchange Transform Type(s) in the
> >>>>>> IKE_INTERMEDIATE
> >>>>>>>>       exchange(s) MUST NOT take place.
> >>>>>>>
> >>>>>>> The use of capitalized version here is wrong (our typo). Please
> >>>>>>> change the
> >>>>>> text as follows:
> >>>>>>>
> >>>>>>> CURRENT:
> >>>>>>> If the responder selects NONE for some Additional Key Exchange
> >>>>>>> Transform Types (provided they are proposed by the initiator),
> >>>>>>> then any corresponding Additional Key Exchanges in the
> >>>>>>> IKE_INTERMEDIATE exchange or exchanges MUST NOT take place.
> >>>>>>>
> >>>>>>> PROPOSED:
> >>>>>>> If the responder selects NONE for some Additional Key Exchange
> >>>>>>> Transform Types (provided they are proposed by the initiator),
> >>>>>>> then any corresponding additional key exchanges MUST NOT take
> >> place.
> >>>>>>>
> >>>>>>> (I also removed reference to IKE_INTERMEDIATE here, otherwise
> >>>>>>> there are too many instances of "exchange"; it's clear that
> >>>>>>> additional key exchanges are performed using IKE_INTERMEDIATE or
> >>>> IKE_FOLLOWUP_KE)
> >>>>>>>
> >>>>>>>>>> b)  Is it possible to update the expansions of "Key Exchange
> >>>>>>>>>> Method (KE)" to instead appear as "Key Exchange (KE) Method",
> >>>>>>>>>> with a 1:1 relationship between expansion and initialism?
> >>>>>>>>>
> >>>>>>>>> I don't think it is needed. The "KE" is not a true initialism,
> >>>>>>>>> it is just a short name for a Transform Type (e.g. another
> >>>>>>>>> transform type is
> >>>>>> "Encryption Algorithm (ENCR)", which is not an initialism at all).
> >>>>>>>>>
> >>>>>>>>> However, a good idea is to add these short names for the added
> >>>>>> "Additional Key Exchange *"
> >>>>>>>> Transform Types (see issue 32 below).
> >>>>>>>>
> >>>>>>>> [rfced] We have updated Table 1 as suggested in issue 32.  Would
> >>>>>>>> you like to add the short names anywhere else in the doc?
> >>>>>>>
> >>>>>>> Yes, please do it whenever Additional Key Exchange Types are
> >> mentioned.
> >>>>>>> Please use AKE* where no concrete type is mentioned.
> >>>>>>>
> >>>>>>>>>> c) Please review the use of the exchange and message names
> >>>>>>>>>> (e.g.,
> >>>>>>>>>> IKE_SA_INIT) throughout the document to ensure each name is
> >>>>>>>>>> followed by either "exchange" or "message" as
> >> appropriate/necessary.
> >>>>>>>>>>
> >>>>>>>>>> For instance:
> >>>>>>>>>> ...the standard IKE fragmentation mechanisms (which cannot be
> >>>>>>>>>> used in
> >>>>>>>>>> IKE_SA_INIT) to be available for the....
> >>>>>>>>>>
> >>>>>>>>>> This sentence is preceded by a sentence discussing IKE_SA_INIT
> >>>>>>>>>> messages and one discussing IKE_SA_INIT exchanges.  Will this
> >>>>>>>>>> be confusing to the reader?
> >>>>>>>>>
> >>>>>>>>> I agree that omitting "exchange" and "messages" here is some
> >>>>>>>>> kind of
> >>>>>> slang.
> >>>>>>>>> The text becomes less formal and more colloquial. I personally
> >>>>>>>>> don't think that readers will be confused, but I don't mind if
> >>>>>>>>> you add an appropriate trailer word when you think it is needed
> >>>>>>>>> (my co-authors may
> >>>>>> think differently).
> >>>>>>>>
> >>>>>>>> [rfced] If this is not a readability issue, then we are happy to
> >>>>>>>> leave the file as
> >>>>>> is.
> >>>>>>>
> >>>>>>> Thank you.
> >>>>>>>
> >>>>>>>> [snip]
> >>>>>>>>>
> >>>>>>>>> 28)
> >>>>>>>>> Section 1.2 In this text:
> >>>>>>>>>
> >>>>>>>>> ORIGINAL:
> >>>>>>>>> Note also that the proposed approach of performing multiple
> >>>>>>>>> successive key exchanges in such a way that resulting session
> >>>>>>>>> keys depend on all of them is not limited to only addressing the
> >>>>>>>>> threat of  quantum computer.
> >>>>>>>>>
> >>>>>>>>> CURRENT:
> >>>>>>>>> Note also that the proposed approach of performing multiple
> >>>>>>>>> successive key exchanges is such that the resulting session keys
> >>>>>>>>> depend on all of them and are not limited to only addressing the
> >>>>>>>>> threat of quantum computers.
> >>>>>>>>>
> >>>>>>>>> I think that the original meaning has been shifted.
> >>>>>>>>> The idea was that the way we get the session keys (so that they
> >>>>>>>>> depend on all key exchanges) is important. Perhaps:
> >>>>>>>>>
> >>>>>>>>> PROPOSED:
> >>>>>>>>> Note also that the proposed approach of performing multiple
> >>>>>>>>> successive key exchanges in a fashion, when the resulting
> >>>>>>>>> session keys  depend on all of them, is not limited to only
> >>>>>>>>> addressing the threat of quantum computers.
> >>>>>>>>>
> >>>>>>>>> Feel free to suggest better wording (I'm not sure "in a fashion "
> >>>>>>>>> is a good
> >>>>>> style).
> >>>>>>>>
> >>>>>>>> [rfced] We updated to use “in such a way”.  Please let us know if
> >>>>>>>> further
> >>>>>> updates are necessary.
> >>>>>>>
> >>>>>>> The current text is OK.
> >>>>>>>
> >>>>>>>
> >>>>>>> After having more discussion among the co-authors, we would like
> >>>>>>> to ask for some further update (the enumeration is continued):
> >>>>>>>
> >>>>>>> 33)
> >>>>>>> Please add the following keywords for the search (in addition to
> >>>>>>> already
> >>>>>> added ones):
> >>>>>>>
> >>>>>>> hybridization
> >>>>>>> hybrid key exchange
> >>>>>>> key encapsulation
> >>>>>>> quantum
> >>>>>>> quantum-safe
> >>>>>>> KEM
> >>>>>>> PQ
> >>>>>>>
> >>>>>>> 34)
> >>>>>>> Please update the text in Section 2.2.1 as follows:
> >>>>>>>
> >>>>>>> CURRENT:
> >>>>>>> Implementers may wish to consider a possible  defense technique
> >>>>>>> described in Section 2.4 of [RFC7296].
> >>>>>>>
> >>>>>>> PROPOSED:
> >>>>>>> Implementers may wish to consider strategies as described  in
> >>>>>>> [RFC7296] Section 2.4 to handle such attack.
> >>>>>>>
> >>>>>>> 35)
> >>>>>>> Please update the text in Section 2.2.2:
> >>>>>>>
> >>>>>>> CURRENT:
> >>>>>>> This message is protected with the current SK_er/  SK_ar keys.
> >>>>>>>
> >>>>>>> PROPOSED:
> >>>>>>> Similar to how the request is protected, this message is secured
> >>>>>>> with the
> >>>>>> current SK_er/
> >>>>>>> SK_ar keys.
> >>>>>>>
> >>>>>>> 36)
> >>>>>>> Please update the text in Section 4 as follows:
> >>>>>>>
> >>>>>>> CURRENT:
> >>>>>>> The main focus of this document is to prevent a passive attacker
> >>>>>>> from  performing a "harvest and decrypt" attack, i.e., attackers
> >>>>>>> that  record messages exchanged today and proceed to decrypt them
> >>>>>>> once they  own quantum computers.
> >>>>>>>
> >>>>>>> PROPOSED:
> >>>>>>> The main focus of this document is to prevent a passive attacker
> >>>>>>> from  performing a "harvest and decrypt" attack. In other words,
> >>>>>>> attackers that
> >>>>>> record
> >>>>>>> messages exchanged today and proceed to decrypt them once they
> >>>>>>> have
> >>>>>> access
> >>>>>>> to cryptographically-relevant quantum computers..
> >>>>>>>
> >>>>>>> 37)
> >>>>>>> Please add a caption to the figure in Appendix C.
> >>>>>>> The caption is:
> >>>>>>>
> >>>>>>>         "Example of how to fragment KE payload"
> >>>>>>>
> >>>>>>> This is the only figure that needs caption in our opinion.
> >>>>>>>
> >>>>>>> 38)
> >>>>>>> We noted, that when rendering pdf and html versions there is no
> >>>>>>> vertical padding after figures, but there is a one line padding
> before.
> >>>>>>> While this is not a critical issue, we wonder if this can be
> >>>>>>> solved somehow (i.e. to add a one line space after each figure)?
> >>>>>>>
> >>>>>>> We found that the following remedy works (not ideally), but
> >>>>>>> probably there
> >>>>>> are better ones?
> >>>>>>> The remedy:
> >>>>>>>
> >>>>>>> (a) avoid the use of CDATA tag if possible
> >>>>>>> (b) make sure the closing tag </artwork> is on a newline, in
> >>>>>>> particular if CDATA tag is used.
> >>>>>>>
> >>>>>>> With this remedy when the CDATA tag has to be used, there is now a
> >>>>>>> bigger than expected vertical space at the bottom of each artwork.
> >>>>>>> But we think this is better than having no vertical spacing at all.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Valery (for the authors).
> >>>>>>>
> >>>>>>>> [snip]
> >>>>>>>>
> >>>>>>>> Thank you.
> >>>>>>>>
> >>>>>>>> RFC Editor/mf=
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>> <rfc9370-addke.xml>
> >>>
> >>>
> >
>
>

-- 

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.