Re: [Lwip] [IPsec] Comments on draft-ietf-lwig-minimal-esp-00
Daniel Migault <mglt.ietf@gmail.com> Thu, 29 October 2020 02:49 UTC
Return-Path: <mglt.ietf@gmail.com>
X-Original-To: lwip@ietfa.amsl.com
Delivered-To: lwip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692383A0975; Wed, 28 Oct 2020 19:49:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, URIBL_BLOCKED=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 NVmGsZrQ9dzQ; Wed, 28 Oct 2020 19:49:28 -0700 (PDT)
Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (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 211313A0969; Wed, 28 Oct 2020 19:49:28 -0700 (PDT)
Received: by mail-vk1-xa2d.google.com with SMTP id k125so385773vka.11; Wed, 28 Oct 2020 19:49:28 -0700 (PDT)
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=sruJXpzaeu5Gm29mz4gUEGcFTVmjlsXsZSgjPuQiQL8=; b=FPv+1kkKlRE6TluPJBYwYe+r8Q+ZlvaV0Eqt/VCJS7vmb8vzmHqdMCH2yqCC7i0zch MJKH3Ec5qJgZsrLVwyulLlBE2iu6UN9NfveDEDuWe53QmltpOJ7EDRCBYyywTC4zSijm wIWjuaTKn4TkN68zU+B5R5jVq9sYWZ+UErXYTY4f7fY/9Whyo1vKtRcWPlHAzUjTSKLM wp7rJNe6f7so5/6JwS0vgckySDY5P2rlNi/Px+uyqD76NeuACKdxOIukl2nger7OiY+O i50cdaAKsnCok7N41ZpdsZvWEyBcpP1NCMQZdjzgUfQGxX7WQ3XGC7b1Gr820f/hSbDV 9H7g==
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=sruJXpzaeu5Gm29mz4gUEGcFTVmjlsXsZSgjPuQiQL8=; b=LXz0xwaxbbTpOZBNJFicXqvS2k8EvZwJXdrTYLLwIQgTFIuwd3Ld7BhvLQV4sKeQxW y/jEPPYY1UWriznIMcmS6T44J96h38gZrBgLnlHur3guLJyr1vevpjnbebOLhl2fQMS5 EScjq3GVjBrhiG6ivYQEqwy/PQRrqpqdJ0KTap+gLybdaa23p07uBhqw+SVc3leSxDBy tr1BtQlALOPoL/d0EwQBMpyA8bPdZnXZqeVbvH/7dFo2XuJGOSj9iz3q8AMrV2tjdhW0 FI5BWZ2uMkgAcui3wOAPldzmoJBbltWAHkzG/k/eQRZObpuDYvCgK7EcJDEMqyYwxvtV aGbA==
X-Gm-Message-State: AOAM531ZR6dGECNWnA5cdq/zEWuhpBF3G+KLr1JBt8nXE2Oc7pxdJTjm u5j0sEaB2t7tNQF0ClPYc02Bec33lL2ZTwMwDck=
X-Google-Smtp-Source: ABdhPJwfLXt8jJ2L2S2bR00wntjrLO+4PRHd52tc0xhB4BPzutS+iXHwe07BT0LmGHrepa0lwpAzphQerNpIo38NaD4=
X-Received: by 2002:a1f:4189:: with SMTP id o131mr1834695vka.6.1603939766917; Wed, 28 Oct 2020 19:49:26 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR11MB3871D71922DC05E087BDF992C1C40@MN2PR11MB3871.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB3871D71922DC05E087BDF992C1C40@MN2PR11MB3871.namprd11.prod.outlook.com>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Wed, 28 Oct 2020 22:49:15 -0400
Message-ID: <CADZyTkn-sn9Txfj9R9j8o97jKwrkcRWkfLrvsu4WkZ-WHkVNKA@mail.gmail.com>
To: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, lwip@ietf.org
Content-Type: multipart/alternative; boundary="0000000000000c5d3905b2c6543f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lwip/dF3eZXG8GTV-o7aH4BnFk2zlR6c>
Subject: Re: [Lwip] [IPsec] Comments on draft-ietf-lwig-minimal-esp-00
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Lightweight IP stack. Official mailing list for IETF LWIG Working Group." <lwip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lwip>, <mailto:lwip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lwip/>
List-Post: <mailto:lwip@ietf.org>
List-Help: <mailto:lwip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lwip>, <mailto:lwip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Oct 2020 02:49:31 -0000
Hi Scott, Thank you very much for the review. The review was extremely useful and I believe the text has been updated accordingly. Please find below more details on the updates. Yours, Daniel On Sun, Jul 21, 2019 at 8:17 PM Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com> wrote: > 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). > > <mglt> Thanks, the use of a fixed SPI is an extreme case, we may have focused a bit too much. We now provide more generic text where the number of SPIs could be limited but not necessarily limited to 1. We also include the ability to handle rekey to be considered when limiting the number of SPIs. I found this idea very nice thanks! In addition, to the SPI section we also re-inforced the need to manage the keys in the security consideration section and the necessity to rekey. Here is the current text: SPI section has been updated as follows: """ However, for some constrained nodes, generating and handling 32 bit random SPI may consume too much resource, in which case SPI can be generated using predictable functions or end up in a using a subset of the possible values for SPI. In fact, the SPI does not necessarily need to be randomly generated. A node provisioned with keys by a third party - e.g. that does not generate them - and that uses a transform that does not needs random data may not have such random generators. However, non random SPI and restricting their possible values MAY lead to privacy and security concerns. As a result, this alternative should be considered for devices that would be strongly impacted by the generation of a random SPI and after understanding the privacy and security impact of generating non random SPI. When a constrained node limits the number of possible SPIs this limit should both consider the number of inbound SAs - possibly per IP addresses - as well as the ability for the node to rekey. SPI can typically be used to proceed to clean key update and the SPI value may be used to indicate which key is being used. This can typically be implemented by a SPI being encoded with the SAD entry on a subset of bytes (for example 3 bytes), while the remaining byte is left to indicate the rekey index. """ The security consideration has been updated as follows: """ The security of a communication provided by ESP is closely related to the security associated to the management of that key. This usually include mechanisms to prevent a nonce to repeat for example. When a node is provisioned with a session key that is used across reboot, the implementer MUST ensure that the mechanisms put in place remain valid across reboot as well. It is RECOMMENDED to use ESP in conjunction of key management protocols such as for example IKEv2 [RFC7296] or minimal IKEv2 [RFC7815]. Such mechanisms are responsible to negotiate fresh session keys as well as prevent a session key being use beyond its life time. When such mechanisms cannot be implemented and the session key is, for example, provisioned, the nodes SHOULD ensure that keys are not used beyond their life time and that the appropriated use of the key remains across reboots. When a node generates its key or when random value such as nonces are generated, the random generation MUST follow [RFC4086]. """ </mglt> > > - > - “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? > > <mglt> We mentioned SHOULD NOT in order to preserve the future usage - if ever these values would be allocated. MUST NOT seems more appropriated and we did not have any other reasons for a SHOULD NOT. This has been changed into the new version. </mglt> > > - > > 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. > <mglt> The current text presented it in another way. The former text seems to explain that random was necessary for the generation of SPI. The current text has been updated to explain that we may have nodes without random generators. I am wondering how the IV is generated with CBC without random generator. </mglt> > > - 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. > > <mglt> We have added this. As suggested by Valery, we also added some text regarding ESN in the case clock is being used for SN. </mglt> > > - > - 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. > > <mglt> This is correct we added some text and recommended that in these cases AES-GCN-SIV may be used. The following text has been added in the Cryptographic suite section. """ 2. Resilience to nonce re-use: Some transforms -including AES-GCM - are very sensitive to nonce collision with a given key. While the generation of the nonce may prevent such collision during a session, the mechanisms are unlikely to provide such protection across reboot. This causes an issue for devices that are configured with a key. When the key is likely to be re-used across reboots, it is RECOMMENDED to consider transforms that are nonce misuse resistant such as AES-GCM-SIV for example[RFC8452] """ </mglt> > > - > > > Typos: > > - a random SPI may consume to much -> too much > - fix SPI -> fixed SPI > - can be alleviate -> can be alleviated > - algorythm -> algorithm > - > > <mglt> fixed </mglt> > > - > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Daniel Migault Ericsson
- Re: [Lwip] [IPsec] Comments on draft-ietf-lwig-mi… Daniel Migault
- Re: [Lwip] [IPsec] Comments on draft-ietf-lwig-mi… Daniel Migault
- Re: [Lwip] [IPsec] Comments on draft-ietf-lwig-mi… Tero Kivinen
- Re: [Lwip] [IPsec] Comments on draft-ietf-lwig-mi… Daniel Migault
- Re: [Lwip] [IPsec] Comments on draft-ietf-lwig-mi… Tero Kivinen
- Re: [Lwip] [IPsec] Comments on draft-ietf-lwig-mi… Daniel Migault