Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is missing
Daniel Migault <daniel.migault@ericsson.com> Wed, 03 April 2019 15:43 UTC
Return-Path: <mglt.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 DE81112011E for <ipsec@ietfa.amsl.com>; Wed, 3 Apr 2019 08:43:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.647
X-Spam-Level:
X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 XEQv_xFbbbRT for <ipsec@ietfa.amsl.com>; Wed, 3 Apr 2019 08:43:20 -0700 (PDT)
Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) (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 8EAC612010F for <ipsec@ietf.org>; Wed, 3 Apr 2019 08:43:19 -0700 (PDT)
Received: by mail-lf1-f44.google.com with SMTP id b7so12058976lfg.9 for <ipsec@ietf.org>; Wed, 03 Apr 2019 08:43:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/lBWZJzt6Z1CmXBpCRdhR5DnIZSuuJHtppAqUmKc3eo=; b=eiakt2SRtf2b2LbEVg5UVC9XimZhHIOZffi21DcY/dLp33kqM6WDDqCRYVqOvA7rpo 7QcdASbM9mGJ0K+aIuiZXScylMdhSXaRH7z78oXLsGCMPmlt+KYTad0PR7aLvyjt1tdH 8pnyGv23NrZPDZZsQRSbpl7Ljo4ZO8RF7+LBHDEChlW41jjcKX8ixgpFyEp4LEL1Iceo 23YN+vNci3l/eBGuGwscMyqQYoWci1Hg/kiiqyqfRWjx0DKwjaNGDKsqf/w+rO3wHS4J F03VFF/ZelczYC/fa09Un30VRYkEW8I5YD0gmDpp7v9eP/z+4PTe8YJjj8rSi7n9NRol AR/g==
X-Gm-Message-State: APjAAAUNPpKq7g1ft/tXDCqSm+lLfK94F+0naHo/p1vYYz92GTbkXkvj hpwrr7Ou/89srruLJpfKjOQl+o8r1c5tlwVDD8Q=
X-Google-Smtp-Source: APXvYqwFgqWpbWCRUpxoR14zbs7+CUQVVi7MDaURIabZLICFxsmVtETJm4N14lEwhMIHYL2vc3iQK+lMlo7rbvFRbtc=
X-Received: by 2002:ac2:54b0:: with SMTP id w16mr251617lfk.138.1554306197468; Wed, 03 Apr 2019 08:43:17 -0700 (PDT)
MIME-Version: 1.0
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> <024a01d4ea1f$dccf35c0$966da140$@gmail.com>
In-Reply-To: <024a01d4ea1f$dccf35c0$966da140$@gmail.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Wed, 03 Apr 2019 11:43:05 -0400
Message-ID: <CADZyTkkN98mL2+s94bwKx0b2EbWMM6L37nHXLTZmeEQgWi6dUQ@mail.gmail.com>
To: Valery Smyslov <smyslov.ietf@gmail.com>
Cc: Tobias Guggemos <guggemos@nm.ifi.lmu.de>, Paul Wouters <paul@nohats.ca>, IPsecME WG <ipsec@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c5bb4e0585a21ca4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/CYVc-WmVt4dJkeRFOtmbgF5YESo>
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 15:43:24 -0000
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 <smyslov.ietf@gmail.com> 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: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… > > > > > > 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], [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. > > > > > > 5 > <https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-06#section-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 > <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 > <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: > > > *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 > > _______________________________________________ > 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