Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06

In any case I’d like to see an explicit text in the draft saying that

this document only redefines how IV is generated and (non) transmitted,

all the other aspects of applying these transforms are defined

in the relevant RFCs:

ENCR_AES_CCM_8_IIV – from RFC 4309 (for ENCR_AES_GCM_8)

ENCR_AES_GCM_16_IIV – from RFC 4106 (for ENCR_AES_GCM_16)

ENCR_CHACHA20_POLY1305_IIV – from RFC 7634

This is probably obvious, but I prefer to explicitly state this, since it’s a technical

document and it should not leave a space for ambiguity.

Regards,

Valery.

From: Valery Smyslov [mailto:smyslov.ietf@gmail.com] 
Sent: Wednesday, April 03, 2019 9:05 AM
To: 'Daniel Migault'; 'Paul Wouters'
Cc: 'IPsecME WG'
Subject: 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:daniel.migault@ericsson.com] 
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 <paul@nohats.ca> 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
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec