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

From: Daniel Migault <[email-masked]>
Date: Sun, 12 Nov 2017 09:03:25 -0500

Hi,

This is the text I propose to address Valery comment regarding the IANA
consideration section. Let me know if you have any comment on that.

Yours,
Daniel

8.  IANA Considerations

   AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to
   implement the implicit IV described in this document.  This section
   limits assignment of new code points to the recommended suites
   provided in [RFC8221], thus the new Transform Type 1 - Encryption
   Algorithm Transform IDs are as defined below:

   -  ENCR_AES_CCM_8_IIV

   -  ENCR_AES_GCM_16_IIV

   -  ENCR_CHACHA20_POLY1305_IIV

   [RFC8247] recommends the same suites for IKEv2.  However some IKEv2
   extensions such as [RFC6311] or [RFC7383] allow the Message ID to be
   re-initialized, which is incompatible with the uniqueness property of
   the nonce, and makes these suites highly insecure.  Given that the
   traffic associated to IKEv2 is expected to remain low compared to the
   ESP traffic, the suites defined in this document MUST NOT be used for
   IKEv2.  The IANA is expected to put "Not allowed" in the column
   "IKEv2 Reference" for these transforms.

On Mon, Oct 30, 2017 at 8:28 AM, Valery Smyslov <[email-masked]> wrote:

> Sorry, I made a typo (see below):
>
> > 2. IANA Considerations
> >
> >       AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to
> >       implement the implicit IV described in this document.  This section
> >       limits assignment of new code points to the recommended suites
> >       provided in [I-D.ietf-ipsecme-rfc4307bis] and
> >       [I-D.ietf-ipsecme-rfc7321bis], thus the new Transform Type 1 -
> >       Encryption Algorithm Transform IDs are as defined below:
> >
> >     The newly defined IIV transforms are not applicable for IKEv2
> (because there is no unique per message field;
> >     Message ID do can repeat, e.g. in case RFC6311 or RFC7383 is used).
> So, [I-D.ietf-ipsecme-rfc7321bis]
>
> [I-D.ietf-ipsecme-rfc4307bis] of course.
>
> >     (now RFC8247) must not be referenced here. Moreover, I'd like to
> express this prohibition
> >     more explicitly in IANA registry, instructing IANA to put "Not
> allowed" in the column "IKEv2 Reference"
> >     for these transforms:
>
> So, the correct text is:
>
>         AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to
>         implement the implicit IV described in this document.  This section
>         limits assignment of new code points to the recommended suites
>         provided in [I-D.ietf-ipsecme-rfc7321bis]. Note, that using
> implicit IV for these
>         algorithms is defined for ESP only and is not allowed for
> protecting
>         IKEv2 messages.
>
>         IANA is requested to add the following transforms to the Transform
> Type 1 -
>         Encryption Algorithm Transform IDs registry for IKEv2, setting
> "ESP Reference"
>         to this document and marking "IKEv2 Reference" as "Not allowed":
>
> Regards,
> Valery.
>
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Sun, 12 Nov 2017 17:51:34 +0300

Hi Daniel,

thank you for addressing that. I have no problems with your text.

There are two nits, however. First: in phrase ”allow the Message ID to be re-initialized”

I would use some other word instead of “re-initialized”, e.g. “reused”,

or “repeated”. And second: I would change “IANA is expected”

to “IANA is requested” or smth similar.

Regards,

Valery.

Hi, 

This is the text I propose to address Valery comment regarding the IANA consideration section. Let me know if you have any comment on that.

Yours, 

Daniel  

8.  IANA Considerations

   -  ENCR_AES_CCM_8_IIV

   -  ENCR_AES_GCM_16_IIV

Sorry, I made a typo (see below):

>     The newly defined IIV transforms are not applicable for IKEv2 (because there is no unique per message field;
>     Message ID do can repeat, e.g. in case RFC6311 or RFC7383 is used). So, [I-D.ietf-ipsecme-rfc7321bis]

>     (now RFC8247) must not be referenced here. Moreover, I'd like to express this prohibition
>     more explicitly in IANA registry, instructing IANA to put "Not allowed" in the column "IKEv2 Reference"
>     for these transforms:

So, the correct text is:

        AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to
        implement the implicit IV described in this document.  This section
        limits assignment of new code points to the recommended suites
        provided in [I-D.ietf-ipsecme-rfc7321bis]. Note, that using implicit IV for these
        algorithms is defined for ESP only and is not allowed for protecting
        IKEv2 messages.

        IANA is requested to add the following transforms to the Transform Type 1 -
        Encryption Algorithm Transform IDs registry for IKEv2, setting "ESP Reference"
        to this document and marking "IKEv2 Reference" as "Not allowed":

Regards,
Valery.

---

From: Daniel Migault <[email-masked]>
Date: Sun, 12 Nov 2017 18:35:16 -0500

Thanks for the feed back Valery. I am just waiting a bit in order to see if
there is a consensus in

a) not using suites that badly interfere with some extensions
vs
b) mentioning the suites must not be used wit these extensions.

a) is definitively safer, but we may need b) later as well.

Yours,
Daniel