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

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

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