Re: [Lake] Discussion on IoT AEAD limits for AES_128_CCM_8

Martin Thomson <mt@lowentropy.net> Wed, 18 November 2020 11:56 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: lake@ietfa.amsl.com
Delivered-To: lake@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06F03A17F1 for <lake@ietfa.amsl.com>; Wed, 18 Nov 2020 03:56:52 -0800 (PST)
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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=lowentropy.net header.b=WwMewU2S; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lYMHqMkM
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 UsF1DSF1f72j for <lake@ietfa.amsl.com>; Wed, 18 Nov 2020 03:56:51 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59A8D3A17F0 for <lake@ietf.org>; Wed, 18 Nov 2020 03:56:51 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 734045C0143; Wed, 18 Nov 2020 06:56:50 -0500 (EST)
Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Wed, 18 Nov 2020 06:56:50 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=OwRbudyyK1qw2P9bAR2dfAZK5FriJQP yH8Tqv26xnDI=; b=WwMewU2SdNSUPfs1ygSovpFWpDHVs40euqM4rYrqgf4EchR L/GZCTJOnE4p3mnOrxR9cYyL/hC8JL6BBhu4vxSikK0mEZJBMig2aHzM+L+yBXEx CLQX1CuqIxetHRqI3qKTB6ryWxU5iCV8Kwy5iMkLT7+sCcEVkGTSxdLp/3jVKQNm EUJ5of5GBJFlQylN/NH4eHfyp5eWty2PjYffAH1zGrRBvNJ4mG87tYbAsv/5p1/w Ib/u+cGTiNPZ2Qv6f7JqqjKJeXIxmhgu/7ZR5ZHEu+R8nUoVZ5vCFhUxnYzTiGS+ CAIw1kAK4ONC90Fb7DdkdO6j4Tt72kaloeneRrg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=OwRbud yyK1qw2P9bAR2dfAZK5FriJQPyH8Tqv26xnDI=; b=lYMHqMkMxE0OqazIr/aGJA X55jhHY8TMso4fJzK6Me18B08Dtr7ydOoS0z0EItlJn2uH/MkK9mYRKtqwg3MkQX uImfgwJHc2alAmsKY1ugg/ViFpv+3vnqISjd7Xpna1/I/Vz9TnzPUa/cCeyGrhLt Fhgh6n/OknylLjn4SHLbIpcXRfjABubg8NmQmEdQ4Fm+vMdR2we6419fg29CiHL6 W4o90V76uC3n56hOQ6bRd2N7Zp0hMSPVuWMRG9IdBkCNpZoMeznZGC0L0o6vNyFY P8m5BIIoqtE2RNAw69yj19itifeAGmlcGI8N1vaoPXNJZCn1PrZhuvqvnhgQ4s7w ==
X-ME-Sender: <xms:AQy1X1ODoW51r1DTRMYbwHbspEBz-v0q5ffZjq0F1vcb62yeUupdQA> <xme:AQy1X3-YO4kyAFvhdEzUpfrzJwErcny0fI7jspPP_WI8Wl_ljyEvlLJjwXRcafLtA 2_FsLGE5rUCufz77E4>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefhedgfeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhepkeetueeikedtkeelfeekvefhkeffvedvvefgkefgleeugfdvjeej geffieegtdejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:AQy1X0Rg1qfeybCCUvyHqzSQVYj4k-SKdoedM8eeIlQqoXvBEbOCyA> <xmx:AQy1XxuBVwyIezELs3nbrBKU3yqKaM2AE2CHC8RoVYHXDI_db1tj9Q> <xmx:AQy1X9f-Z4qA6pdLSo8C1ix_wb2zSkLWJW29cIAG4F6jIL0C2Hi5OA> <xmx:Agy1Xzq8hA8b_V1uHaExRdpYdmXWGkZTAlSajehHDkEeZv-yI6kjbA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id AE4C1201E2; Wed, 18 Nov 2020 06:56:49 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3
Mime-Version: 1.0
Message-Id: <50ee8f5f-b4b7-4fc9-822b-ef1f2b4add19@www.fastmail.com>
In-Reply-To: <EB57AF37-7497-4DF7-9535-90C36FDACC43@ericsson.com>
References: <0EB305C3-1751-45AA-A240-C6A3135C09CC@ericsson.com> <e7ad2b16-c5b7-467e-9325-d7d9cccc9166@www.fastmail.com> <EB57AF37-7497-4DF7-9535-90C36FDACC43@ericsson.com>
Date: Wed, 18 Nov 2020 22:56:28 +1100
From: Martin Thomson <mt@lowentropy.net>
To: John Mattsson <john.mattsson@ericsson.com>, "lake@ietf.org" <lake@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/QUx-Q_c0ssZfrxQCz2TIgvuP_d4>
Subject: Re: [Lake] Discussion on IoT AEAD limits for AES_128_CCM_8
X-BeenThere: lake@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Lightweight Authenticated Key Exchange <lake.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lake>, <mailto:lake-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lake/>
List-Post: <mailto:lake@ietf.org>
List-Help: <mailto:lake-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lake>, <mailto:lake-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Nov 2020 11:56:53 -0000

On Wed, Nov 18, 2020, at 18:37, John Mattsson wrote:
> But I do not see why even 128 would be unacceptable. It is only a 
> denial-of-service problem if the endpoint becomes unavailable or have 
> to do a heavy key exchange/handshake.

The general rule here is that if v exceeds this value, the keys cannot be used without risking an unacceptable increase in the chance that the attacker is able to successfully create a forgery.  That means that 128 *unsuccessful* forgery attempts is enough to cause the keys - and therefore the connection, probably - to be unusable.  That's a fairly simple DoS to mount, even against a device that has very limited communication capabilities.

Now, as I said, maybe 2^-57 is too low for your use case.

> When the counter of failed decryption reaches v the endpoint can wait for a valid ciphertext, [...]

The problem is that the next ciphertext is now a forgery with a higher probability than you determined to be acceptable from the outset.  You can't even *try* to use the keys.  Unless you accept that higher risk.

You can, if you are able, try to rekey at this point.  However, you are now racing the attacker, because it is likely that your peer will be unable to read your messages too.  So even if you don't attempt to use your keys and you only use your write keys to try to force an update, you have no guarantee that your message will be readable to a peer in the same state you are in.

Put another way, you are effectively saying that you are using an unauthenticated message to determine when to rekey, which gives your attacker a relatively low cost control surface onto your app.

Maybe you can tolerate very low limits for forgeries if you are able to guarantee that your messages win races.  A lock step protocol might easily manage with this limit if the rekey cost is tolerably low.  But I would look instead at p and whether a looser target is better.