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

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Mon, 18 Jun 2018 13:39:12 +0000

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

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Mon, 18 Jun 2018 16:00:55 +0000

Please note, this is a follow-up to the previous WGLC. This is to confirm WG consensus on the draft before sending it forward to the IESG.

Thanks,
Dave

> -----Original Message-----
> From: Waltermire, David A. (Fed)
> Sent: Monday, June 18, 2018 9:39 AM
> To: IPsecME WG <[email-masked]>
> Subject: WGLC on draft-ietf-ipsecme-implicit-iv-04
> 
> 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

---

From: Daniel Migault <[email-masked]>
Date: Mon, 18 Jun 2018 12:17:58 -0400

as a co-author, I believe that all comments received so far have been
addressed and the resulting document is in good shape for the IESG.

Yours,
Daniel

On Mon, Jun 18, 2018 at 12:00 PM, Waltermire, David A. (Fed) <
[email-masked]> wrote:

> Please note, this is a follow-up to the previous WGLC. This is to confirm
> WG consensus on the draft before sending it forward to the IESG.
>
> Thanks,
> Dave
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: David Schinazi <[email-masked]>
Date: Mon, 18 Jun 2018 09:48:55 -0700

Hi,

I have read and reviewed the last few revisions of the draft and I believe it is ready for publication.
I also implemented Implicit IV for ChaCha20-Poly1305 and it was pretty straightforward.

Thanks,
David Schinazi

> On Jun 18, 2018, at 09:17, Daniel Migault <[email-masked]> wrote:
> 
> as a co-author, I believe that all comments received so far have been addressed and the resulting document is in good shape for the IESG. 
> 
> Yours, 
> Daniel
> 
> On Mon, Jun 18, 2018 at 12:00 PM, Waltermire, David A. (Fed) <[email-masked] <mailto:[email-masked]>> wrote:
> > To: IPsecME WG <[email-masked] <mailto:[email-masked]>>
> > (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ <https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/>). Please indicate
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>
>

---

From: "Tobias Guggemos" <[email-masked]>
Date: Fri, 22 Jun 2018 17:16:51 +0200

Regards, 
Tobias

-----Ursprüngliche Nachricht-----
Von: IPsec [mailto:[email-masked]] Im Auftrag von Waltermire, David
A. (Fed)
Gesendet: Montag, 18. Juni 2018 18:01
An: IPsecME WG <[email-masked]>
Betreff: Re: [IPsec] WGLC on draft-ietf-ipsecme-implicit-iv-04

Please note, this is a follow-up to the previous WGLC. This is to confirm WG
consensus on the draft before sending it forward to the IESG.

Thanks,
Dave

> 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.

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 26 Jun 2018 16:22:19 +0300

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.
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). 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.

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.

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
>

---

From: Daniel Migault <[email-masked]>
Date: Tue, 26 Jun 2018 14:10:51 -0400

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

> should be moved into the Security Considerations section.
<mglt>
I am fine having it in the security consideration. Anyone opposed ?
</mglt>

> 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),
> 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:

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>

>    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>

> draft-ietf-ipsecme-implicit-iv-04, which will conclude
> Please indicate if you believe this draft is

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 27 Jun 2018 10:26:51 +0300

HI Daniel,

I still think the “NOT RECOMMENDED” wording is a bit confusing.

I’d suggest to change this para to be more explicit:

   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-masked] [mailto:[email-masked]] 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-masked]> wrote:

Hi,

<mglt>

</mglt>

<mglt>

OLD:

NEW

<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:

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>

<mglt>

</mglt>

Regards,
Valery.

---

From: Daniel Migault <[email-masked]>
Date: Wed, 27 Jun 2018 11:46:42 -0400

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 <[email-masked]>
wrote:

> *From:* [email-masked] [mailto:[email-masked]] *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
>
>
>