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

["Valery Smyslov" <[e-mail]>]

Hi Daniel,

 


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.

          Yes.

 

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. 

 

          No, since you define your own transforms (with own code points) you don’t need to update those RFCs.

 

          Regards,

          Valery.

 

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…

 

 

 <https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-06#section-4> 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.

    
 

 <https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-06#section-5> 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 < <mailto:[e-mail]> [e-mail]> 
Gesendet: Mittwoch, 3. April 2019 09:13
An: 'Tobias Guggemos' < <mailto:[e-mail]> [e-mail]>; 'Daniel Migault' < <mailto:[e-mail]> [e-mail]>; 'Paul Wouters' < <mailto:[e-mail]> [e-mail]>
Cc: 'IPsecME WG' < <mailto:[e-mail]> [e-mail]>
Betreff: RE: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is missing

 

Hi Tobias,

 

From: Tobias Guggemos [ <mailto:[e-mail]> mailto:[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 < <mailto:[e-mail]> [e-mail]> Im Auftrag von Valery Smyslov
Gesendet: Mittwoch, 3. April 2019 08:05
An: 'Daniel Migault' < <mailto:[e-mail]> [e-mail]>; 'Paul Wouters' < <mailto:[e-mail]> [e-mail]>
Cc: 'IPsecME WG' < <mailto:[e-mail]> [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]> mailto:[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:

 


 <https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-06#section-2> 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.

 


 <https://tools.ietf.org/html/rfc4106#section-8.4> 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