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

[Daniel Migault <[e-mail]>]

Thanks Tobias for proposing some text. I am fine with the text. I do not
think we need to specify the specific transforms
(ENCR_AES_GCM_8, ENCR_AES_GCM_16)  as we are not limited to these
transforms. If everyone is fine with the text and chairs agree to we could
upload a updated version.
Yours,
Daniel

On Wed, Apr 3, 2019 at 8:58 AM Tobias Guggemos <[e-mail]>
wrote:

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