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 <[email protected]> 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 <[email protected]> > *Gesendet:* Mittwoch, 3. April 2019 09:13 > *An:* 'Tobias Guggemos' <[email protected]>; 'Daniel Migault' < > [email protected]>; 'Paul Wouters' <[email protected]> > *Cc:* 'IPsecME WG' <[email protected]> > *Betreff:* RE: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is > missing > > > > Hi Tobias, > > > > *From:* Tobias Guggemos [mailto:[email protected] > <[email protected]>] > *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 <[email protected]> *Im Auftrag von *Valery Smyslov > *Gesendet:* Mittwoch, 3. April 2019 08:05 > *An:* 'Daniel Migault' <[email protected]>; 'Paul Wouters' < > [email protected]> > *Cc:* 'IPsecME WG' <[email protected]> > *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:[email protected] > <[email protected]>] > *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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
