Re: [Lwip] Review of draft-ietf-lwig-minimal-esp-00

Daniel Migault <> Sun, 01 November 2020 20:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 843183A0E82; Sun, 1 Nov 2020 12:40:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KcMJNdfqMd60; Sun, 1 Nov 2020 12:40:36 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::92c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B0B33A0E81; Sun, 1 Nov 2020 12:40:36 -0800 (PST)
Received: by with SMTP id q20so3366780uar.7; Sun, 01 Nov 2020 12:40:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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$> <> <>
In-Reply-To: <>
From: Daniel Migault <>
Date: Sun, 01 Nov 2020 15:40:24 -0500
Message-ID: <>
To: Tero Kivinen <>
Cc: Valery Smyslov <>, IPsecME WG <>,, Tobias Guggemos <>
Content-Type: multipart/alternative; boundary="00000000000043e49005b311a4a1"
Archived-At: <>
Subject: Re: [Lwip] Review of draft-ietf-lwig-minimal-esp-00
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Lightweight IP stack. Official mailing list for IETF LWIG Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 01 Nov 2020 20:40:38 -0000

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.


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.

> --

Daniel Migault