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>
Precedence: list

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.