Re: New confidentiality and integrity limits

Martin Thomson <mt@lowentropy.net> Thu, 16 July 2020 04:59 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6E23A0D3F for <quic@ietfa.amsl.com>; Wed, 15 Jul 2020 21:59:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 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_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=HSy9KkPk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=etbS/yPD
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 eMowBN9NbClv for <quic@ietfa.amsl.com>; Wed, 15 Jul 2020 21:59:00 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2553A0D3E for <quic@ietf.org>; Wed, 15 Jul 2020 21:59:00 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id BE7855C0144; Thu, 16 Jul 2020 00:58:59 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Thu, 16 Jul 2020 00:58:59 -0400
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=fm2; bh=vvLnez5CSHsKVZOAO8W5O7Kpbpuo7cn 40uCFxL4PArE=; b=HSy9KkPkCxEwz4vID7ykXoq2WTUeEbqUxcj6jPahuyzWf6t TaJu0pOMGsO1N7yfTOdvy5RqxtA2l/DelW9g9W0NLucehRAyY/hyxAOaKbQQSpjp xk5yQSaoRTUUsi5P6oeGaMtYCu85NUb/zwbFByUstw+DwdOMSLov2jCsSUF03a7T zsgxeEqGNYiMLWgoOoNuokOt8aRk2MQi2FttS3spa/QCHAme57MXRzN1Dt2N5UuJ NgUiqHzc+njChZyxSC277BGhrivYjgpX+hxS85tv+nks7C6pyffZ8Uu3gvvKJ/w1 Jed8UbSbl4K1segwLRqNeYD87S4gY469PAObJeQ==
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=fm3; bh=vvLnez 5CSHsKVZOAO8W5O7Kpbpuo7cn40uCFxL4PArE=; b=etbS/yPD+Ww4RnHdIrkvHv UwcNg7FOw2hBSjGOXJL69PD80ZC3cwyEDJmVhRFLOEvzS0033deQTX6FQ1BwBJN9 YX0xsHr2gdeTtthi+DXpVe36idj+yLpgF4rjTkZ2eOb53eOcO6f0OBsY23dcV1Gl jfkKY+1BmUmOEM34KCYc3nVrj3egGNiHt6XDG2PUQCNhQxzNLuEwr87hgfyPoaro EOf8yrmiqko/En2TJ7yzXd8B1hVxnuaFL3uyKlwlGWq9AWUMEAc/txdzn9FtffyI kuLW/LKPCPDagQNxt9o3UfAkxo2P1sgrMpH44ya0Bi2gmx4VdS3uvmAdZJ2cjCdQ ==
X-ME-Sender: <xms:k94PX628iFFfKXk4i_dfUOFC0tM9ON-5Brdg5D7MNeLfDC2CXYmQYg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfeefgdeklecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepkeetueeikedtkeelfeekve fhkeffvedvvefgkefgleeugfdvjeejgeffieegtdejnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:k94PX9HfLc4AEmf2cW66_gARc-eL_BtdvAhi-XMA6BPxCgyESDlREw> <xmx:k94PXy5qqoq3NKYBGQIahfgxdA1pM_LFqs_BDKi3yyfn2s8Ghw7wvg> <xmx:k94PX731PzHJhKg0cqsPUF3x41GI9vF-1ZBoPIDpvXqOhSGPJfRljQ> <xmx:k94PXxQwIbQRI8QDZ5qiaD1cyyb-80keSa4C9m6FfrzVecGeXy2vFg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 455B1E00DF; Thu, 16 Jul 2020 00:58:59 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-52-g083df19-fm-idx2020-20200715.003-g083df194
Mime-Version: 1.0
Message-Id: <19922b1a-a02c-46c9-b441-3806d3f77b89@www.fastmail.com>
In-Reply-To: <CACsn0c=HkByj0dkwfW+0=n9HzGZ0cZamot6N=AFks3wbnwnWXQ@mail.gmail.com>
References: <43bb1525-0afa-4c4e-a234-f6ccfacbdd29@www.fastmail.com> <a4d7e8cf-5879-6941-e059-5d2f3e67ae86@huitema.net> <58b40fc0-86ad-49e9-bc17-187c38e97f7a@www.fastmail.com> <1d543593-7abc-4a89-93c5-82c464492786@www.fastmail.com> <CACpbDccSB6H9AhmAinia7ojEg1VY-S=dF214wHvZcZkoiL-xFA@mail.gmail.com> <7d549475-249b-4674-9aa8-c2bf9953243b@www.fastmail.com> <CALGR9oaHQHJneN2edetGLcq4u4PNF0oAyq9PKc7ZVxz_pXTMGw@mail.gmail.com> <CACsn0c=HkByj0dkwfW+0=n9HzGZ0cZamot6N=AFks3wbnwnWXQ@mail.gmail.com>
Date: Thu, 16 Jul 2020 14:58:33 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: quic@ietf.org, =?UTF-8?Q?Felix_G=C3=BCnther?= <mail@felixguenther.info>
Subject: Re: New confidentiality and integrity limits
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/1eI0BJSTB9BDk_vQwYQHuNPX49M>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jul 2020 04:59:02 -0000

On Thu, Jul 16, 2020, at 11:40, Watson Ladd wrote:
> I do not believe the analysis is correct.
> 
> A forgery against a QUIC connection will be checked at one or at most
> two keys: the current one and the next one. It is not the case that a
> forgery will be attempted against all the keys simultaneously: it will
> have to be resent. Perhap I'm missing something about the setting here
> that makes this the multiuser and not the singleuser setting.

Thanks for checking Watson.

I had exactly the same thought, but was convinced by Felix that the analysis was based on a definition that only considers the number of encryption/verification queries in total. In particular, that the values in results are not limited in any way by which subset of the keys could be tried.

Incidentally, that also supports the view that there is degradation in the confidentiality advantage as you update to different keys.  I note that the PR does not acknowledge this, but maybe it should.

I confess that I'm still not completely confident that the multiuser setting is a good fit for our needs (or even that the threat model is the right one).  This is, in part of the reason you state: the mu setting assumes that the attacker has equal access to all "users" concurrently and the limited number of active keys would seem to make that difficult to exploit.  But I don't know how to prove that this is an acceptable assumption.

What I am confident about is that a conservative approach doesn't hurt a great deal here.  The calculated limits for GCM are high enough - even under the assumptions made - that you have serious problems if you hit them.