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

[Daniel Migault <[e-mail]>]

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
>