Re: [IPsec] WGLC on draft-ietf-ipsecme-implicit-iv-04

[Daniel Migault <[e-mail]>]

Thanks for your comments Valery. The new version [1] has teh two paragraphs
in the security consideration.
Yours,
Daniel

[1] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/

On Wed, Jun 27, 2018 at 3:26 AM, Valery Smyslov <[e-mail]>
wrote:

> 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:* [e-mail] [mailto:[e-mail]] *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 <[e-mail]>
> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ipsec
>
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
>
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>