If you have the bandwidth, I would recommend publishing a new draft. The pre-meeting publication cut off is on Oct 24. Having an up to date document is helpful going into the meeting.
Roman ________________________________ From: IPsec <ipsec-boun...@ietf.org> on behalf of CJ Tjhai <cjt=40post-quantum....@dmarc.ietf.org> Sent: Friday, October 21, 2022 3:08 AM To: Roman Danyliw <r...@cert.org> Cc: Tero Kivinen <kivi...@iki.fi>; Valery Smyslov <s...@elvis.ru>; ipsec@ietf.org <ipsec@ietf.org>; Valery Smyslov <smyslov.i...@gmail.com> Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-multiple-ke-06 Hi Roman, We have updated our draft to incorporate Russ' feedback and also changes from IANA review. it also includes the following changes following your suggestions. The updated draft is available here https://github.com/post-quantum/ietf-pq-ikev2/blob/master/draft-ietf-ipsecme-ikev2-multiple-ke-00.xml. Should we publish version 08 of the draft, or should we just wait for the end of IETF LC? Best wishes, CJ and Valery [snip] [Roman] Makes sense. Thanks. To prevent this from coming up during subsequent reviews. Please add a reference to that FAQ here. We have added the reference to NIST FAQs. [snip] [Roman] A recommended value would help if you are comfortable giving it, or explaining why it’s hard to give one. This is a common question that comes from transport review during IETC LC or IESG review. We added the following sentences: Note that due to various factors such as computational resource and key exchange algorithm used, it is not possible to give a normative guidance on how long this timeout period should be. In general, 5-20 seconds of waiting time should be appropriate in most cases. [snip] [Roman] Adding a bit of clarifying text like discussed here would be helpful – that the ordering does not matter. We added this text as suggested: The ordering of the additional key exchanges should not matter in general, as only the final shared secret is of interest. Nonetheless, because the strength of the running shared secret increases with every additional key exchange, an implementer may want to first perform the most secure method (in some metrics) and followed by less secure one(s). [Roman] Agreed. Consider if you need to talk about work that ISN’T done in this document here. To keep things on point, I would recommend deleting this text. We have removed the text as suggested. On Wed, 12 Oct 2022 at 20:18, Valery Smyslov <smyslov.i...@gmail.com<mailto:smyslov.i...@gmail.com>> wrote: Hi Tero, > Roman Danyliw writes: > > ** Section 3.2.4. > > > > The responder MUST handle this > > situation gracefully and delete the associated state if it does not > > receive the next expected IKE_FOLLOWUP_KE request after some > > reasonable period of time. > > > > Is there a guidance on the timeout value? > > > > IKEv2 traditionally does not mandate exact timeouts. For example, the > same > > situation happens if the initiator completes IKE_SA_INIT and never starts > > IKE_AUTH. The responder should eventually delete the incomplete IKE SA, > but > > RFC 7296 does not specify how long the waiting time is. > > > > FWIW, our implementations waits 5 seconds by default (which is > adjustable > > value). > > > > Do you think we should recommend (but not mandate) to wait for 5-10 > seconds? > > > > [Roman] A recommended value would help if you are comfortable giving > it, or > > explaining why it’s hard to give one. This is a common question that > comes > > from transport review during IETC LC or IESG review. > > Suitable values can be between few seconds up to few minutes. For > example timeout between IKE_SA_INIT and IKE_AUTH might require user > interaction, thus it might be up to minutes if PIN code to unlock user > auth device is required etc. > > Because the timeouts are so different depending on the environment and > usage scenario we do not give them in the IKEv2 document. With the IKE_FOLLOWUP_KE exchange user interaction is not a problem (it should not take place). However, since we are talking about PQ algorithms and some of them may be quite costly in terms of generating a key pair, the initiator may just be unable to provide data for the next IKE_FOLLOWUP_KE exchange quickly. So, while I think that several minutes is too long in this case, I agree that timeout values could be very different depending on the initiator's resources and on the algorithm employed. For this reason we didn't specify it. We can give a vague recommendation that waiting for 5-20 seconds can be appropriate in most situations, but definitely we don't want making these values normative. Regards, Valery. > -- > kivi...@iki.fi<mailto:kivi...@iki.fi> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org<mailto:IPsec@ietf.org> > https://www.ietf.org/mailman/listinfo/ipsec ________________________________ 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.
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
