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

[Daniel Migault]

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 
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:* mglt.i...@gmail.com [mailto:mglt.i...@gmail.com] *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 
> 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.
>
> 
>
> I am fine having it in the security consideration. Anyone opposed ?
>
> 
>
>
>
> 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).
>
>
>
> 
>
> 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.
>
> 
>
> 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

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

[Valery Smyslov]

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: mglt.i...@gmail.com [mailto:mglt.i...@gmail.com] 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  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.



I am fine having it in the security consideration. Anyone opposed ?



 

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

 



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.



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.



 


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 cou

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

[Daniel Migault]

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

I am fine having it in the security consideration. Anyone opposed ?


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



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

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.




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


I am fine adding the text in the draft.


>
> 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
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> 

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

[Valery Smyslov]

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
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Tobias Guggemos]

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. 

Regards, 
Tobias

-Ursprüngliche Nachricht-
Von: IPsec [mailto:ipsec-boun...@ietf.org] Im Auftrag von Waltermire, David
A. (Fed)
Gesendet: Montag, 18. Juni 2018 18:01
An: IPsecME WG 
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

> -Original Message-
> From: Waltermire, David A. (Fed)
> Sent: Monday, June 18, 2018 9:39 AM
> To: IPsecME WG 
> 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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[David Schinazi]

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  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) 
> mailto:david.walterm...@nist.gov>> 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
> 
> > -Original Message-
> > From: Waltermire, David A. (Fed)
> > Sent: Monday, June 18, 2018 9:39 AM
> > To: IPsecME WG mailto:ipsec@ietf.org>>
> > 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
> 
> ___
> IPsec mailing list
> IPsec@ietf.org 
> https://www.ietf.org/mailman/listinfo/ipsec 
> 
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Daniel Migault]

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) <
david.walterm...@nist.gov> 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
>
> > -Original Message-
> > From: Waltermire, David A. (Fed)
> > Sent: Monday, June 18, 2018 9:39 AM
> > To: IPsecME WG 
> > 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
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Waltermire, David A. (Fed)]

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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Waltermire, David A. (Fed)]

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
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec