From nobody Sun Nov 1 12:40:44 2020 Return-Path: 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 843183A0E82; Sun, 1 Nov 2020 12:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 KcMJNdfqMd60; Sun, 1 Nov 2020 12:40:36 -0800 (PST) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 3B0B33A0E81; Sun, 1 Nov 2020 12:40:36 -0800 (PST) Received: by mail-ua1-x92c.google.com with SMTP id q20so3366780uar.7; Sun, 01 Nov 2020 12:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b3JfN9GxneGFVjQZWVYq3/OgYnXhqc6VmSx5ec/GFf8=; b=b6jKrfEHS7eS1Uvjp1DWARgwJ55zlqFPedXL7W0MKhfq8gQfzzy8hJt06EMtycMHqr wo+IEY7LAixdI6j3V5KC2xbPivD0153jAluQl1Uf+atJbetfeqhjcjPOKuRM94RVv24U rXL1zI7QxCfCETShEeQ//ZYMjRQ5VC6t3uEoMM0uxwET1B1d3ZctPqZIi721UlqoKaIS GUxpwdXoWA7H1foRSBszhg2Vv+uD6PeB+b4pg5UVgz/WBc2wOjoKmKzS8goIykp73zyw UuteqbvoZX/bo31Krzz2RTN3+Fg32ksE6tk2C9ftEyPmZQCRJC8cb48k2VYoVZ0KglQC Gthg== 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=b3JfN9GxneGFVjQZWVYq3/OgYnXhqc6VmSx5ec/GFf8=; b=LhBsmDpaWa6dXCowT4hqA8K13Tifk8oTtWl7eowHz5YihZaikIvVBSmUtVySa0gVts USBavlcmtNmpSvkoReXfcAy57qPqIOt5k7LEedkGH4w2fNYO/ubESeNepoX3iY+8D7e+ OMMVg7q7x8DearBpGY8Zz/z7MCMXV+6+oLeE5u6cwXxEmg1Z9rZydr+6wJhETStdEWMA +iNmWoSoqoJhLIkfum34nmpbtunOIOYlzcnuXOmGgfjo084norFMn6QDbdVmu/QHg1Yn /spTinx02qcF3U55KQ12lRETDevok9PRM9kFWNLS2ExGtnN415dnLN1laUpVOxGhqRGW hoEg== X-Gm-Message-State: AOAM531CLoj6ivz4Nqb3VQ9n71UUbUVlqFb/aY/0dHA6c7h5mesz/Kj4 BDBX1Vo+fF07bp4AoM+q72Q6v53ON/QUA704Kgo= X-Google-Smtp-Source: ABdhPJyBE/MrRXEvWk1ZrRDH8bRkqOtHsT9Yl0bp8JLALb18Mjp26lsSxda+hKQaepIHQEW0NpobW57ulKufbxWDjtA= X-Received: by 2002:ab0:48ab:: with SMTP id x40mr6380938uac.68.1604263235280; Sun, 01 Nov 2020 12:40:35 -0800 (PST) MIME-Version: 1.0 References: <060501d5a9da$b8552490$28ff6db0$@gmail.com> <24476.26850.591422.567867@fireball.acr.fi> In-Reply-To: <24476.26850.591422.567867@fireball.acr.fi> From: Daniel Migault Date: Sun, 1 Nov 2020 15:40:24 -0500 Message-ID: To: Tero Kivinen Cc: Valery Smyslov , IPsecME WG , lwip@ietf.org, Tobias Guggemos Content-Type: multipart/alternative; boundary="00000000000043e49005b311a4a1" Archived-At: Subject: Re: [IPsec] [Lwip] Review of draft-ietf-lwig-minimal-esp-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2020 20:40:38 -0000 --00000000000043e49005b311a4a1 Content-Type: text/plain; charset="UTF-8" Hi Tero, Thanks for the comments. Please find below how I updated the text on my local copy and let me know if that addresses your concerns. Yours, Daniel On Fri, Oct 30, 2020 at 3:26 PM Tero Kivinen wrote: > Daniel Migault writes: > > value SN needs to be considered instead. Note that the limit of > > messages being sent is primary determined by the security associated > > to the key rather than the SN. The security of the key used to > > encrypt decreases with the each message being sent and a node MUST > > ensure the limit is not reached - even though the SN would permit it. > > In a constrained environment, it is likely that the implementation of > a > > rekey mechanism is preferred over the use of ESN. > > No. The security of the key does not decrease, but the ability for the > attacker to attack the key might incrase, and the value of attacking > that one key also increases when more data is encrypted with it. Also > with short block length algorithms there were stricter limits of data > that can be encrypted with one key. > Thanks. Here is the text I propose. The security of all data protected under a given key decreases slightly with each message and a node MUST ensure the limit is not reached - even though the SN would permit it. > -- > kivinen@iki.fi > -- Daniel Migault Ericsson --00000000000043e49005b311a4a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tero,=C2=A0

Thanks for th= e comments. Please find=C2=A0below how I updated the text on my local copy = and let me know if that addresses your concerns.=C2=A0

=
Yours,=C2=A0
Daniel

On Fri, Oct 30, 2020 at 3:26 PM Tero Kivinen <= ;kivinen@iki.fi> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">Daniel Migault writes:
> =C2=A0 =C2=A0value SN needs to be considered instead.=C2=A0 Note that = the limit of
> =C2=A0 =C2=A0messages being sent is primary determined by the security= associated
> =C2=A0 =C2=A0to the key rather than the SN.=C2=A0 The security of the = key used to
> =C2=A0 =C2=A0encrypt decreases with the each message being sent and a = node MUST
> =C2=A0 =C2=A0ensure the limit is not reached - even though the SN woul= d permit it.
> =C2=A0 =C2=A0In a constrained environment, it is likely that the imple= mentation of a
> =C2=A0 =C2=A0rekey mechanism is preferred over the use of ESN.

No. The security of the key does not decrease, but the ability for the
attacker to attack the key might incrase, and the value of attacking
that one key also increases when more data is encrypted with it. Also
with short block length algorithms there were stricter limits of data
that can be encrypted with one key.
<mglt>
=
Thanks. Here is the text I propose.=C2=A0
The security of al= l data protected under a given key decreases slightly with each message and= a node MUST ensure the limit is not reached - even though the SN would per= mit it.=C2=A0
</mglt>=C2=A0
--
kivinen@iki.fi


--
Daniel Migault
Ericsson
--00000000000043e49005b311a4a1--