Re: [Lwip] [IPsec] Comments on draft-ietf-lwig-minimal-esp-00

Daniel Migault <> Mon, 22 July 2019 03:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4F0FB12007C; Sun, 21 Jul 2019 20:24:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.557
X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id stVaAJcMpm0T; Sun, 21 Jul 2019 20:24:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 26E45120033; Sun, 21 Jul 2019 20:24:51 -0700 (PDT)
Received: by with SMTP id a186so23535565vsd.7; Sun, 21 Jul 2019 20:24:51 -0700 (PDT)
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=4BwM7RWsHoJWdFflkc9UlEs+ZhgVaaIP0PvRqluxjLA=; b=J4sDEYucQUOBGB4v+HsWI878eT8mNTwalWPNxKZzy3aDn+0aHZQyzhxDojuO55ObX7 JVTkXSaLKKzHkamzuSR7joUrho5bb1DmLdnXI83ocMmO2WC1r+GFRGxzPy4VoA1OuSBt VHyTgLEMY8gU1rVUXvfUA+N3zr+VXWgJbOf/63+x62Nc5/+Z+/BXXPkuWQDRJZbADNZu iDOmL1Hj50XNkzWipWKvJFw0o1Lw/HqjSjLZTV09NUiYom1TR/w5o8zRum1PlwzorhuP PV8PD/uvzZPd9gygxtsFblxLb6RwMrJf6PZGEqrRATG0s2VGrve8cHVsxRlpv/G6JCT+ aZ2A==
X-Gm-Message-State: APjAAAV/et5GL8IF9e1ryBFaiZcY92OES2kZuj+wL+3gnwHSrg+1Ib8R iUWkwOz82ZnoNFhck4+7bGcskP49PzDtPK6NH84=
X-Google-Smtp-Source: APXvYqwagejKyh6LV/GgCi1rHBHWQBYBZH3izZyv2jSJMr3EoLZN86wOt2llAqKkvNoOSemT5WsybIBtbw5oi0Op41c=
X-Received: by 2002:a67:f998:: with SMTP id b24mr41029185vsq.180.1563765889951; Sun, 21 Jul 2019 20:24:49 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Daniel Migault <>
Date: Sun, 21 Jul 2019 23:24:39 -0400
Message-ID: <>
To: "Scott Fluhrer (sfluhrer)" <>,
Cc: "" <>
Content-Type: multipart/alternative; boundary="00000000000061ed73058e3c9e11"
Archived-At: <>
Subject: Re: [Lwip] [IPsec] Comments on 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: Mon, 22 Jul 2019 03:24:54 -0000

Thanks Scott for the comment. I will address them tomorrow, I am just
sharing the review to the lwig list.

On Sun, Jul 21, 2019 at 8:17 PM Scott Fluhrer (sfluhrer) <>

> Comments:
>    - I have issues with the draft’s emphasis on fixed SPI values.  One
>    reason for the SPI value is to handle key updates cleanly; during the
>    transition, the SPI can be used to indicate whether the packet was
>    encrypted with the previous set of key or the new ones.  As we really don’t
>    want to discourage rekeying I would suggest that, instead of talking so
>    much about fixed SPIs, you instead address how to do nonrandom SPIs (for
>    example, by having the top 3 bytes of the inbound SPI being the SAD entry,
>    and the lower byte being the rekey index).
>    - “Values 0-255 SHOULD NOT be used.”; shouldn’t that be MUST NOT?  Can
>    you think of an advantage a device might have for using a SPI in that
>    region?
> The use of fix SPI MUST NOT be considered as a way to avoid strong random
> generators.  Such generator will be required in order to provide strong
> cryptographic protection”; actually, if the IPsec implementation doesn’t
> actually generate its own keys (that is, it relies on an external service
> to provide them), and the transform itself doesn’t require random data (CBC
> can be implemented securely without one), then the IPsec implementation
> doesn’t actually need an CSPRNG.
>    - SN based on clocks; one issue that is not addressed is that standard
>    receivers are tuned for an increment of one-per-packet; if the sender uses
>    increments significantly larger than that, and packets are reordered, the
>    receiver is more likely to reject valid packets because they fell outside
>    the window.
>    - One issue you do not address (but I believe you should) is the fact
>    that some cryptographical transforms are more resilient for key reuse (e.g.
>    because you use a fixed key, and don’t change it after a reboot) than
>    others.  In particular, both GCM and ChaCha20-Poly1305 have real problems
>    when that happens, and should be avoided.
> Typos:
>    - a random SPI may consume to much -> too much
>    - fix SPI -> fixed SPI
>    - can be alleviate -> can be alleviated
>    - algorythm -> algorithm
>    -
> _______________________________________________
> IPsec mailing list