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
- [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key l… Valery Smyslov
- Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - k… Paul Wouters
- Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - k… Daniel Migault
- Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - k… Valery Smyslov
- Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - k… Valery Smyslov
- Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - k… Tobias Guggemos
- Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - k… Valery Smyslov
- Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - k… Valery Smyslov
- Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - k… Tobias Guggemos
- Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - k… Daniel Migault
- Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - k… Valery Smyslov
- Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - k… Daniel Migault
- Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - k… Valery Smyslov
- Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - k… Daniel Migault
- Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - k… Valery Smyslov
- Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - k… Tero Kivinen
- Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - k… Daniel Migault