Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is missing

[Daniel Migault <[e-mail]>]

So the becomes:4
<https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-06#section-4>.
Implicit IV

   [...]

   o  Extended Sequence Number: the 8 byte Extended Sequence Number of

      the Security Association.  The 4 byte low order bytes are carried

      in the ESP packet.



+  This document solely defines the IV generation of the algorithms defined

+  in [RFC4106] for AES-GCM, [RFC4309] for AES-CCM and [RFC7634] for
ChaCha20-Poly1305.

+  Any other aspect (including using the Key Length attribute) of applying
those ciphers with the new

+  Transform Types defined in this document MUST be taken from the

+  documents defining the use of the algorithms in ESP.

One additional question came to my mind on whether we update the RFC
mentioned above or not.  We could consider our document as an alternate
mechanism to generate the IV of the existing RFC.

Yours,
Daniel

On Wed, Apr 3, 2019 at 11:47 AM Valery Smyslov <[e-mail]>
wrote:

> Fine, thank you!
>
>
>
> Nit:
>
> s/including the Key Length/including using the Key Length attribute
>
>
>
>
>
>
>
> *From:* Daniel Migault [mailto:[e-mail]]
> *Sent:* Wednesday, April 03, 2019 6:43 PM
> *To:* Valery Smyslov
> *Cc:* Tobias Guggemos; Paul Wouters; IPsecME WG
> *Subject:* Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is
> missing
>
>
> Hi, So the text could be:4
> <https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-06#section-4>.
> Implicit IV
>
>    [...]
>
>    o  Extended Sequence Number: the 8 byte Extended Sequence Number of
>
>       the Security Association.  The 4 byte low order bytes are carried
>
>       in the ESP packet.
>
>
>
> +  This document solely defines the IV generation of the algorithms defined
>
> +  in [RFC4106] for AES-GCM, [RFC4309] for AES-CCM and [RFC7634] for
> ChaCha20-Poly1305.
>
> +  Any other aspect (including the Key Length) of applying those ciphers
> with the new
>
> +  Transform Types defined in this document MUST be taken from the
>
> +  documents defining the use of the algorithms in ESP.
>
>
>
> Do we agree ?
>
> Yours,
>
> Daniel
>
>
>
> On Wed, Apr 3, 2019 at 9:27 AM Valery Smyslov <[e-mail]>
> wrote:
>
> Hi Tobias,
>
>
>
> I think that with your added text to Section 4, the text about
>
> Key Length attributes in Section 5 becomes unnecessary (since
>
> “all other aspects” includes Key Length too). But it won’t harm.
>
>
>
> And I’m not sure it’s worth to mention “any future algorithms using this
>
> mechanism”. Your draft defines exactly 3 new transforms, if some
>
> future algorithm will be defined using IIV, a new RFC will be needed anyway
>
> to allocate new code point (strictly speaking with Expert Review
> allocation policy
>
> you can allocate code points without any document describing their use,
>
> but I don’t think it’s a good practice). So, I’d rather to remove this
> part.
>
>
>
> Otherwise my comment is addressed.
>
>
>
> Thank you,
>
> Valery.
>
>
>
>
>
> *From:* Tobias Guggemos [mailto:[e-mail]]
> *Sent:* Wednesday, April 03, 2019 3:58 PM
> *To:* 'Valery Smyslov'; 'Daniel Migault'; 'Paul Wouters'
> *Cc:* 'IPsecME WG'
> *Subject:* AW: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is
> missing
>
>
>
> Hey Valery,
>
> >OK. And please add some words that all other aspects
>
> >of applying theses transforms must be taken from
>
> >the relevant RFCs (explicitly cite which).
>
>
>
> Do you think the following addresses the comment? I’m not sure if section
> 5 is the right place for it…
>
>
>
>
>
> 4
> <https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-06#section-4>.
> Implicit IV
>
>    [...]
>
>    o  Extended Sequence Number: the 8 byte Extended Sequence Number of
>
>       the Security Association.  The 4 byte low order bytes are carried
>
>       in the ESP packet.
>
>
>
> +  This document solely defines the IV generation of the algorithms defined
>
> +  in [RFC4106], [RFC4309], [RFC7634] or any future algorithms using this
>
> +  mechanism. Any other aspect of applying those ciphers with the new
>
> +  Transform Types defined in this document MUST be taken from the
>
> +  documents defining the use of the algorithms in ESP.
>
>
>
>
>
> 5
> <https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-06#section-5>.
> Initiator Behavior
>
>
>
>    An initiator supporting this feature SHOULD propose implicit IV
>
>    algorithms in the Transform Type 1 (Encryption Algorithm)
>
>    Substructure of the Proposal Substructure inside the SA Payload.
>
> +  The attributes of this Transform Type MUST be equal to the ones defined
>
> +  by the originating algorithms, e.g. key length for AES-CCM [RFC 4106]
> and
>
> +  AES-GCM [RFC 4309].
>
>    To
>
>    facilitate backward compatibility with non-supporting peers the
>
>    initiator SHOULD also include those same algorithms without Implicit
>
>    IV (IIV) as separate transforms.
>
>
>
> Regards
>
> Tobias
>
>
>
>
>
> *Von:* Valery Smyslov <[e-mail]>
> *Gesendet:* Mittwoch, 3. April 2019 09:13
> *An:* 'Tobias Guggemos' <[e-mail]>; 'Daniel Migault' <
> [e-mail]>; 'Paul Wouters' <[e-mail]>
> *Cc:* 'IPsecME WG' <[e-mail]>
> *Betreff:* RE: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is
> missing
>
>
>
> Hi Tobias,
>
>
>
> *From:* Tobias Guggemos [mailto:[e-mail]
> <[e-mail]>]
> *Sent:* Wednesday, April 03, 2019 10:06 AM
> *To:* 'Valery Smyslov'; 'Daniel Migault'; 'Paul Wouters'
> *Cc:* 'IPsecME WG'
> *Subject:* AW: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is
> missing
>
>
>
> Hey,
>
> I’d prefer not having the key length explicitly defined in this document.
>
> I think, this document should be able to define Implicit IV for any cipher
> being appropriate to use it.
>
> Currently, that’s AES GCM, CCM and Chacha, but I’d like not to see another
> document defining the same for every other cipher which might come along.
>
>
>
> If this is a formal requirement, can we add a text that the Implicit IV is
> negotiated the same way as the underlying cipher, with references to the
> currently defined ones?
>
> e.g.
>
>
>
> 5.  Initiator Behavior
>
>
>
>    An initiator supporting this feature SHOULD propose implicit IV
>
>    algorithms in the Transform Type 1 (Encryption Algorithm)
>
>    Substructure of the Proposal Substructure inside the SA Payload.
>
> + The attributes of this Transform Type MUST be equal to the ones defined
>
> + by the originating algorithms, e.g. key length for AES-CCM [RFC 4106] and
>
> + AES-GCM [RFC 4309]
>
>
>
>           OK. And please add some words that all other aspects
>
>           of applying theses transforms must be taken from
>
>           the relevant RFCs (explicitly cite which).
>
>
>
>    To
>
>    facilitate backward compatibility with non-supporting peers the
>
>    initiator SHOULD also include those same algorithms without Implicit
>
>    IV (IIV) as separate transforms.
>
>
>
> >Or alternatively, as I already suggested, you can define default key
> length and make
>
> >Key Length attribute optional – it will allow to save a couple of bytes
> for most common cases.
>
> I like this idea, but I don’t think this draft is the right place to do
> it.
>
> Maybe an new draft, defining default values for some ciphers, which
> explicitly allows to omit them in the proposal?
>
>
>
>           Works for me.
>
>
>
>           Regards,
>
>           Valery.
>
>
>
> Regards
>
> Tobias
>
>
>
> *Von:* IPsec <[e-mail]> *Im Auftrag von *Valery Smyslov
> *Gesendet:* Mittwoch, 3. April 2019 08:05
> *An:* 'Daniel Migault' <[e-mail]>; 'Paul Wouters' <
> [e-mail]>
> *Cc:* 'IPsecME WG' <[e-mail]>
> *Betreff:* Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is
> missing
>
>
>
> Hi Daniel,
>
>
>
> I understand that the draft is only focused on the IV, but since it
> defines new transforms,
>
> it formally must address key length issue for AES. You can either
> copy-paste text from RFC 4106 (or 4309),
>
> or add text referencing Section 8.4 of RFC 4106 for GCM and Section 7.4 of
> RFC 4309 for CCM.
>
> Or alternatively, as I already suggested, you can define default key
> length and make
>
> Key Length attribute optional – it will allow to save a couple of bytes
> for most common cases.
>
>
>
> In any cases, I prefer not to put this into Introduction, but instead add
> a new section,
>
> as it is done in all other transform-defining RFCs.
>
>
>
> Regards,
>
> Valery.
>
>
>
>
>
> *From:* Daniel Migault [mailto:[e-mail]
> <[e-mail]>]
> *Sent:* Tuesday, April 02, 2019 9:41 PM
> *To:* Paul Wouters
> *Cc:* Valery Smyslov; IPsecME WG
> *Subject:* Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is
> missing
>
>
>
> Hi,
>
>
>
> Thanks Valery for your comment. My reading of the draft is that it only
> focuses on the generation of the nonce and leave the remaining to 4306 [1].
> The use of a code points different from 4306 is to indicate the implicit IV
> - as opposed to a new transform. In this case, the negotiation of the key
> length is left to 4306.  I am inclined to think this is not necessary to
> discuss the key length attribute in this draft, but I would like to see
> what the other think.
>
>
>
> That said, if people strongly think that should be added, I would add the
> text from 4306 mentioned below[2].
>
>
>
> Yours,
>
> Daniel
>
>
>
> [1] The text of the implicit draft:
>
>
> 2
> <https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-06#section-2>.
> Introduction
>
>
>
>
>
>    Counter-based AES modes of operation such as AES-CTR ([RFC3686 <https://tools.ietf.org/html/rfc3686>]),
>
>    AES-CCM ([RFC4309 <https://tools.ietf.org/html/rfc4309>]), and AES-GCM ([RFC4106 <https://tools.ietf.org/html/rfc4106>]) require the
>
>    specification of an nonce for each ESP packet.  The same applies for
>
>    ChaCha20-Poly1305 ([RFC7634 <https://tools.ietf.org/html/rfc7634>]).  Currently this nonce is sent in each
>
>    ESP packet ([RFC4303 <https://tools.ietf.org/html/rfc4303>]).  This practice is designated in this document
>
>    as "explicit nonce".
>
> [...]
>
>    This document defines how to compute the nonce locally when it is
>
>    implicit.  It also specifies how peers agree with the Internet Key
>
>    Exchange version 2 (IKEv2 - [RFC7296 <https://tools.ietf.org/html/rfc7296>]) on using an implicit IV versus
>
>    an explicit IV.
>
>
>
> [2] the text on key length of RFC 4306.
>
>
> 8.4 <https://tools.ietf.org/html/rfc4106#section-8.4>.  Key Length
> Attribute
>
>
>
>
>
>    Because the AES supports three key lengths, the Key Length attribute
>
>    MUST be specified in the IKE Phase 2 exchange [RFC2407 <https://tools.ietf.org/html/rfc2407>].  The Key
>
>    Length attribute MUST have a value of 128, 192, or 256.
>
>
>
>
>
>
>
> On Tue, Apr 2, 2019 at 12:52 PM Paul Wouters <[e-mail]> wrote:
>
> On Tue, 2 Apr 2019, Valery Smyslov wrote:
>
> > and define a default key length for the case when it is absent (e.g. 256
> bits).
>
> Do not do this. There are broken implementations and interop issues on
> this already by broken clients who don't send or omit to send KEY_LENGTH
> (old versions of us included).
>
> > It'll allow us to save few bytes by omitting attribute for most common
> cases.
>
> Not worth it.
>
> Paul
>
> _______________________________________________
> 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
>