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

"Valery Smyslov" <smyslov.ietf@gmail.com> Wed, 03 April 2019 13:27 UTC

Return-Path: <smyslov.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DB31200F4 for <ipsec@ietfa.amsl.com>; Wed, 3 Apr 2019 06:27:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.402
X-Spam-Level: *
X-Spam-Status: No, score=1.402 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_JQ-GCNvIzG for <ipsec@ietfa.amsl.com>; Wed, 3 Apr 2019 06:27:04 -0700 (PDT)
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEDB6120046 for <ipsec@ietf.org>; Wed, 3 Apr 2019 06:27:03 -0700 (PDT)
Received: by mail-wm1-x330.google.com with SMTP id n25so8217746wmk.4 for <ipsec@ietf.org>; Wed, 03 Apr 2019 06:27:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=zC7jMeZ3/VwBRE83+0ronrEhoYKMCnyHZTZcrsWSur8=; b=GO2cm0tgAGJNwsmjG5EG4LyYeV9JCxt9DfyODu+Pn5BdzcRw6Nd34HwGU8gs3v9bIG IEKN+oS8dkzRzorefJPk8R1edYNZrh2tNbvqRgmpGbUmja58fTI2JO3xdxfUWuaSpwrJ uqBClv1P3/qsZ5hhsw88lxSb5mui3FXVhxjTmkxICL7xQ1eFOh/s1irxlu/YEO6aGUXp 8VsZUhVcSj/ShBVDfRj2VahPwKeDNDZehnVqFap6T8MmLSUFSUlSI/tqmM3Vfs31pOcA TCAyZ5aBvowPnshZHEOwxmCZ+dxdP4qO2o4z7yTkajRvPPESykY6Efsh9+1oPq3FkMzp 3/0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=zC7jMeZ3/VwBRE83+0ronrEhoYKMCnyHZTZcrsWSur8=; b=bfA16GQxn+kHKpOuCwCLsGjovUu9nHTAlVbx8LaznIZqI0IVCW4cfe2lCFLuoIhtRp lwU/cS/SBzSh51l6nNe/64U6iFDwdZA2K45srMSpTWi7hk8wLEcxYMKxBAb56MAR8RNa vcl3r8pdvoucNiHz2bXLygHmxa7U2Q9S1Oo/gKlMdFqVLxZFrBWRh9Abad22Tpq6euh8 HkVWWfx2WThGe9ioRozBXW0C1Gp21K6ZTQ3hBxhqSzQygU2D7LWOfsZLJnaJWmIpwMrQ PPQpJVQN0VuU9rUVFnIyxu8vISAPt0dwYJkzsOGJPUcU3QCOSiGS52UewQ0qrjYO4cDC m+Pg==
X-Gm-Message-State: APjAAAVf2AtSQSyV75EGqJwQ2dE42wCZwxdn/LRghjT4bEKPlkHYUdOG 1dlHAR1jKelCRu8Yz+x0gA2NQ0Vk
X-Google-Smtp-Source: APXvYqz01RNFM2ajRO53JvVu1bfqSNyKj+ofcweLAixJ+rJjVSZBvx8cbMLEGUC7kUxRmXyK9jJTPg==
X-Received: by 2002:a1c:2087:: with SMTP id g129mr29865wmg.114.1554297567182; Wed, 03 Apr 2019 06:19:27 -0700 (PDT)
Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id v184sm34774285wma.6.2019.04.03.06.19.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 03 Apr 2019 06:19:26 -0700 (PDT)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: 'Tobias Guggemos' <guggemos@nm.ifi.lmu.de>, 'Daniel Migault' <daniel.migault@ericsson.com>, 'Paul Wouters' <paul@nohats.ca>
Cc: 'IPsecME WG' <ipsec@ietf.org>
References: <010501d4e961$ddae8a90$990b9fb0$@gmail.com> <alpine.LRH.2.21.1904021250150.14241@bofh.nohats.ca> <CADZyTknc_aDoNqrXE2vt1k6sA-rW+yx4uk2QpcS8kF3MMEq5pg@mail.gmail.com> <018301d4e9e3$31b831f0$952895d0$@gmail.com> <003701d4e9eb$a810d9d0$f8328d70$@nm.ifi.lmu.de> <01ce01d4e9ec$b4415080$1cc3f180$@gmail.com> <005a01d4ea1c$e25e9420$a71bbc60$@nm.ifi.lmu.de>
In-Reply-To: <005a01d4ea1c$e25e9420$a71bbc60$@nm.ifi.lmu.de>
Date: Wed, 03 Apr 2019 16:19:25 +0300
Message-ID: <024a01d4ea1f$dccf35c0$966da140$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_024B_01D4EA39.02228840"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQH2Bk3AMgto0NN/T2TCjcWtr4PQxgGM/hO3Aj4WHpsCnMvTzAIYWFTwAk8MdXACFVq3kaWBCONA
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/3GL7EAeGVi683h_45PuVIHA2l9s>
Subject: Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is missing
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2019 13:27:07 -0000

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:guggemos@nm.ifi.lmu.de] 
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 <smyslov.ietf@gmail.com> 
Gesendet: Mittwoch, 3. April 2019 09:13
An: 'Tobias Guggemos' <guggemos@nm.ifi.lmu.de>; 'Daniel Migault' <daniel.migault@ericsson.com>; 'Paul Wouters' <paul@nohats.ca>
Cc: 'IPsecME WG' <ipsec@ietf.org>
Betreff: RE: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is missing

 

Hi Tobias,

 

From: Tobias Guggemos [mailto:guggemos@nm.ifi.lmu.de] 
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 <ipsec-bounces@ietf.org> Im Auftrag von Valery Smyslov
Gesendet: Mittwoch, 3. April 2019 08:05
An: 'Daniel Migault' <daniel.migault@ericsson.com>; 'Paul Wouters' <paul@nohats.ca>
Cc: 'IPsecME WG' <ipsec@ietf.org>
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: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