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 <[email protected]>
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:[email protected]]
> *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 <[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
