Re: [IPsec] Comments about draft-ietf-ipsecme-implicit-iv-02

Tero Kivinen <kivinen@iki.fi> Thu, 10 May 2018 14:53 UTC

Return-Path: <kivinen@iki.fi>
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 962C5124205; Thu, 10 May 2018 07:53:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level:
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, 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 a71waFGun4NB; Thu, 10 May 2018 07:53:38 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A56FB1241FC; Thu, 10 May 2018 07:53:37 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w4AErW7I008929 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 10 May 2018 17:53:32 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w4AErVkf012952; Thu, 10 May 2018 17:53:31 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-ID: <23284.23787.935682.175733@fireball.acr.fi>
Date: Thu, 10 May 2018 17:53:31 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: IPsecME WG <ipsec@ietf.org>, draft-ietf-ipsecme-implicit-iv@ietf.org
In-Reply-To: <CADZyTkmO32wVS7MoP=RsnH5KAZ68yMBCw0WT5vhmGziuDA6s1Q@mail.gmail.com>
References: <23239.54227.814560.228778@fireball.acr.fi> <CADZyTkmO32wVS7MoP=RsnH5KAZ68yMBCw0WT5vhmGziuDA6s1Q@mail.gmail.com>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 2 min
X-Total-Time: 2 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/M0QzXnJV3plWWZzyzQfGb3Y4viU>
Subject: Re: [IPsec] Comments about draft-ietf-ipsecme-implicit-iv-02
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 10 May 2018 14:53:41 -0000

Daniel Migault writes:
> another alternative could be:
> 
> As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are
>    used, Implicit IV as described in this document MUST NOT be used in
>    setups with the chance that the Sequence Number overlaps for one SA.
>    Multicast as described in [RFC5374], [RFC6407] and
>    [I-D.yeung-g-ikev2] is a prominent example, where many senders share
>    one secret and thus one SA.  As
>    such, it is NOT RECOMMENDED to use Implicit IV with Multicast.

I would actually prefer to this. I think it is better to say don't do
it, than provide ways it could be done before saying don't do it....

I.e., if someone is interested in this then we need to write new
specification that will specify how it is done, so there is no point
of speculating here what it could be.
-- 
kivinen@iki.fi