HI Daniel,
I still think the “NOT RECOMMENDED” wording is a bit confusing. I’d suggest to change this para to be more explicit: As the IV must not repeat for one SA when Counter-Mode ciphers are used, Implicit IV as described in this document MUST NOT be used in setups with the chance that the Sequence Number overlaps for one SA. Multicast as described in [RFC5374], [RFC6407] and [I-D.yeung-g-ikev2] is a prominent example, where many senders share one secret and thus one SA. As such, Implicit IV may only be used with Multicast if some mechanisms are employed that prevent Sequence Number to overlap for one SA, otherwise Implicit IV MUST NOT be used with Multicast. Regards, Valery. From: [email protected] [mailto:[email protected]] On Behalf Of Daniel Migault Sent: Tuesday, June 26, 2018 9:11 PM To: Valery Smyslov Cc: Waltermire, David A. (Fed); IPsecME WG Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-implicit-iv-04 Hi Valery, Thanks for the feedback. Here are the update I propose. If that is fine for everyone, I will update the current draft and publish a new version. Yours, Daniel On Tue, Jun 26, 2018 at 9:22 AM, Valery Smyslov <[email protected]> wrote: Hi, I reviewed the draft and I believe it is almost ready. However, I think there still are few issues. 1. The last para of section 4 says: As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are used, Implicit IV as described in this document MUST NOT be used in setups with the chance that the Sequence Number overlaps for one SA. Multicast as described in [RFC5374], [RFC6407] and [I-D.yeung-g-ikev2] is a prominent example, where many senders share one secret and thus one SA. As such, it is NOT RECOMMENDED to use Implicit IV with Multicast. I have three problems with this para. First, I think that this para should be moved into the Security Considerations section. <mglt> I am fine having it in the security consideration. Anyone opposed ? </mglt> Second, using RFC 2119 word in the beginning ("As the IV MUST NOT repeat") seems to be wrong here, since it is not an imperative, it's an explanation here (because the preposition "As" is used; note that the draft has already stated that the nonce MUST NOT repeat in the beginning of Section 4). <mglt> I think that this address your purpose: OLD: As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are used, Implicit IV as described in this document MUST NOT be used in setups with the chance that the Sequence Number overlaps for one SA. NEW As the IV must not repeat for one SA when Counter-Mode ciphers are used, Implicit IV as described in this document MUST NOT be used in setups with the chance that the Sequence Number overlaps for one SA. And last (but not least), I have some trouble following this para, it seems to me that it is self-contradicting. First it says that IIV MUST NOT be used if there is a chance that SN repeats (which I fully agree with), then it says that multicast is a prominent example of this situation (i.e. the situation when SN may repeat, which I fully agree with too) and finally it concludes that for multicast IIV is NOT RECOMMENDED (i.e. it SHOULD NOT be used). In other words it is allowed to use IIV for multicast in some circumstances, which in my opinion contradicts with earlier MUST NOT. Either remove the last sentence, or give more explanation when it is possible to use IIV for multicast. <mglt> OK I see your point. The reason is mostly that we had a quite long explanation we removed because we went to the details of a solution we do not standardize. I suggest we simply mention that some means are deployed. OLD: Multicast as described in [RFC5374], [RFC6407] and [I-D.yeung-g-ikev2] is a prominent example, where many senders share one secret and thus one SA. As such, it is NOT RECOMMENDED to use Implicit IV with Multicast. NEW: Multicast as described in [RFC5374], [RFC6407] and [I-D.yeung-g-ikev2] is a prominent example, where many senders share one secret and thus one SA. As such, it is NOT RECOMMENDED to use Implicit IV with Multicast, unless deployment specific mechanisms prevent the IV to repeat are provided. </mglt> 2. The draft defines IIV for ESP only and forbids to use it for IKEv2. It was discussed and I believe it is right, but I'd like to see few words (presumably in the Security Considerations) why IIV in its current form cannot be used in IKEv2. Something along the lines: This document defines three new encryption transforms that use implicit IV. Unlike most encryption transforms defined to date, which can be used for both ESP and IKEv2, these transforms are defined for ESP only and cannot be used in IKEv2. The reason is that IKEv2 messages don't contain unique per-message value, that can be used for IV generation. The Message-ID field in IKEv2 header is somewhat counterpart of SN field in ESP header, but recent IKEv2 extensions ([RFC6311], [RFC7383]) do allow it to repeat, so there is no an easy way to derive unique IV from IKEv2 header fields. <mglt> I am fine adding the text in the draft. </mglt> Regards, Valery. > This message starts a working group last call (WGLC) on > draft-ietf-ipsecme-implicit-iv-04, which will conclude > on June 29, 2018 at UTC 23:59. Please review and provide feedback on the -04 > version > (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/). Please > indicate if you believe this draft is > ready for publication or if you have comments that must be addressed before > the draft progresses. > > Regards, > Dave > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
