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

Tero Kivinen <kivinen@iki.fi> Mon, 02 November 2020 14:00 UTC

Return-Path: <kivinen@iki.fi>
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 D496F3A104D; Mon, 2 Nov 2020 06:00:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.346
X-Spam-Level:
X-Spam-Status: No, score=-2.346 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, NICE_REPLY_A=-0.247, 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=iki.fi
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 KKgDmJwe8Y54; Mon, 2 Nov 2020 06:00:21 -0800 (PST)
Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (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 739EF3A1043; Mon, 2 Nov 2020 06:00:20 -0800 (PST)
Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 625871B00436; Mon, 2 Nov 2020 16:00:16 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1604325616; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Lq/Tef95HcyYd4M0uRjuEfNR8qm4oEbq3byN1NiTE7Q=; b=t/zuzX7lMOWQO1+JQtsd0uncExwkLoDf5KWw3K94LfzyEW57OzYTWvcuq5faF/IfWqzpSL BT1juCeBMYhQp5fhgPcT0es5zbIDsGOC6OuJN49HQOSQBWIW1RTeudZ6et7J82T4gQJfXS 5R2LkI9Pr4vctXIQ076pq2YtLa10J13J3O95DJCztjTYEHvVtxu+F8YTUCCuy2xCGfnLkC iHWUO7tox70WZVAm2C/skFoAmV8bqyni+nESUYvhbyzjo8GO8NWkWvbARor+reth4roAVH b060XUntfZ81DbHKSoSwQbb14PcNF/VY/PP+NViOyG2aFkOxiSAcAbgOGpPOxQ==
Received: by fireball.acr.fi (Postfix, from userid 15204) id 087E925C11F3; Mon, 2 Nov 2020 16:00:16 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-ID: <24480.4335.981375.920639@fireball.acr.fi>
Date: Mon, 02 Nov 2020 16:00:15 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Daniel Migault <mglt.ietf@gmail.com>
Cc: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>, "ipsec@ietf.org" <ipsec@ietf.org>, lwip@ietf.org
In-Reply-To: <CADZyTkmTr3jna3_=j__s=yYw4PXJ6mrO7hoNp=Zp+Are56Y8EA@mail.gmail.com>
References: <MN2PR11MB3871D71922DC05E087BDF992C1C40@MN2PR11MB3871.namprd11.prod.outlook.com> <CADZyTkn-sn9Txfj9R9j8o97jKwrkcRWkfLrvsu4WkZ-WHkVNKA@mail.gmail.com> <24476.26053.16496.150596@fireball.acr.fi> <CADZyTkmTr3jna3_=j__s=yYw4PXJ6mrO7hoNp=Zp+Are56Y8EA@mail.gmail.com>
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 4 min
X-Total-Time: 3 min
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1604325616; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Lq/Tef95HcyYd4M0uRjuEfNR8qm4oEbq3byN1NiTE7Q=; b=YoOqaY3ZAm8J+T3TcLxUL9vVZZsfQ8Nru2eWNWQ2DsRtmNNzLM0FSISq8BIoOrhY4eP95J XZ5OFz/SDqITDLzltbnBrQZ+AGGKEVNzQDQoz1wD5dZcJ/SH5QpKTogKYUKveTO4Pjrzr7 xY6Ah2/Af0KtSGB9fWSWGSqvpl5TkOZkVzY3hW7HDYbAuoR5O3N98PIKkGk3kMXvagcKtR RvAFwxapvm24ZD3wSYc++es0Au0pTs+iojm3rehtY5NPAkBVJcVpVVDsmCwmEHLlAhKmhZ BG74sAm+9oMaZaVelK2+MV177THOUZjaiI7LPmBgpvxwpi0KyvKzDro+2WkdsQ==
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi
ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1604325616; a=rsa-sha256; cv=none; b=lyJ7lYdoQQU1RnOlAgIlSZ6oVRAknUVMe3H11ebZKkOAguXm0csiqUXvvE1qMWd3HWmUsR YG0eTBTqgi0TNdS73li6QWXZhgczQ08sUxQNWlfGW3cu+9/I94b987+NBHn8BMiLQmDkq/ VZNsGtYZQhdyXEdt/jt4yeOFKdxWvfb9snQuPeAB9QYwdsViHT9HhXdZiQNrHe3rbJiZP+ gl+2E/7SgsUzF/e7PCw6muXVEnmFolYwB29GtHvdZPvQppYY/g09kZR+GjiM7kin8TRsCs 2V0iCVLM71TAgLwKoaJy2VqP5P6DloNiMeL8Ty2fOypiPgFSXTO5O2SO54duiA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/lwip/Shf2oUKvtIsb0uzY2zRwuBurm58>
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: Mon, 02 Nov 2020 14:00:24 -0000

Daniel Migault writes:
> <mglt>
> Correct. it must be a  MUST. I also explicitly added that condition on nonce
> and counter needs to remain valid. The new text is as follows:
> 
> When such mechanisms cannot be implemented and the session key is, for
> example, provisioned, the nodes MUST ensure that keys are not used beyond
> their life time and that the appropriate use of the key remains across reboots
> - e.g. conditions on counters and nonces remains valid.
> 
> </mglt> 

Looks ok. 

>     Normally you use just counter, and encrypt it with secret key. The IV
>     in CBC does not be random, it needs to be unpredictable and it should
>     not be direct counter or other source with low Hamming distance
>     between successive IVs.
>    
>     Actually the problem with old way of CBC mode was that the IV was
>     random, but predictable as implementations used last block of previous
>     packet. If attacker does not know the key you are using to encrypt the
>     counter to generate IVs, the IVs will be unpredictable and random.
> 
> <mglt>
> Thanks for the information. What I was wondering then, is for which reason
> can't we consider this as a random generator - of a limited lifetime. 
> </mglt> 

That method is very common piece used when you are making random
number generator. It is for example part of the NIST AES Counter mode
based generator, but to properly make random number generator out of
that need bit more stuff around it. For example you need to make sure
it is rekeyed before the counter rolls over, and of course it is only
as secure as the random secret key you are using to seed it etc.

See NIST SP 800-90A REv 1 [1] CTR_DRBG description for more
information.

[1] https://csrc.nist.gov/publications/detail/sp/800-90a/rev-1/final
-- 
kivinen@iki.fi