Re: New confidentiality and integrity limits

Felix Günther <> Thu, 16 July 2020 06:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1D41F3A0FB7 for <>; Wed, 15 Jul 2020 23:47:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id flQv56cmHock for <>; Wed, 15 Jul 2020 23:47:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3F4213A0FB6 for <>; Wed, 15 Jul 2020 23:47:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 09AEC4F2007D for <>; Thu, 16 Jul 2020 08:47:48 +0200 (CEST)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 7F5824F20079 for <>; Thu, 16 Jul 2020 08:47:48 +0200 (CEST)
References: <> <> <> <> <> <> <> <> <>
From: =?UTF-8?Q?Felix_G=c3=bcnther?= <>
Autocrypt:; keydata= mQGiBE04qkIRBADtFenVz1DuqethtPkoKAazBeKjyrr5Znbi8mQT1gOrkuli6i0/umf2uJ9V uI6NgjR0uM68UFGIHZlAoWk5Nfo8BTkYsdXl4R08pePmwRwwtq9LALZrGkeLeQtOFdLJt7G2 iQgqq2XpZc9AXW3/+j0I6MmsWMQKCkCA1s6IRLtH+wCgk85oP1adRYaEpi82Z3oG7vztEOkE AMccj8RgnjWcbB13HxxRk2C/4mgLEmCBWO3nmcCPZP5t/5GZSe7Kt5HQoygjxxcro/2e+9wF YsYwLUpHKMOjyvtcU0jLtIv0m6I+GQ3HOz89erVpa7G7EUoEsbQ7FEuyW4mVEaQZ3XE1Mxvp /3Ca1rBJjoxXhxKaDJYWsc5fdO6RA/44xXLdiE2f6NDoTJY7Z97VXUnJskpDNnwePOJyX4GT DwII2kl6JSYOAmkcOpINOSVsS0XDLZpBuKqsibUF/t53BkNfR/aF/BzIUJ5dykqrHvi75aQb ltSum1+kIo8Q6ZI+MzAAwmbqLfuRHZP5y0fjxdHLhfMrvacrNHnaoUWrVbQoRmVsaXggR8O8 bnRoZXIgPG1haWxAZmVsaXhndWVudGhlci5pbmZvPoh8BBMRAgA8AhsjBgsJCAcDAgYVCAIJ CgsEFgIDAQIeAQIXgBYhBCuuSm95RkYbcAFhs1KvAgDT8XAOBQJdE93OAhkBAAoJEFKvAgDT 8XAOVSwAn0QmRYzMtqFZejCnMakizqsaWHJlAJ4jR3nDqw5h3Ct4Xyz1CEQrUdJgz7kEDQRN OKpCEBAA9TNoDOa0PVCAWvt9tw06MUw+D0PoAhkl1jlNEzeNatLDQqf6YehHOgtjpgA8tpul DJUq/o3NN15JsUB1el6oQje644owqhEFD8V02Ns3ZK6hGgBRGupp6RKwg70F4z4ukKwCS789 rZdwaq8t+X37NRUP41Y537kgfN2R1BFLB0A19Qb52nsaneBUSgGLXu39bxDrHounoLjMitJa 10ATRcuRny8eJzAuXI8lCURNjCPWJVjXN3gs+z6sA/ebr2inLQT66WIQZi5Q31BNyPGeaai+ 7t7IbpfkhqnbHATDq6vtM8lCem+rsYc3MtN1W4jQZ59ACI3ieu3MouMoN4W5mp0bjB6oNiO1 TTYD3ZUYBeV7ITX47lag7A9MPzBwbRGdetAN1yU5HDv7mgadei/oFlwC4/hD18kYjuHEUxKi CookZZaPQEMTKjBpHhrphSslTXl/tWmMJBoVsgedghWyf39o8ZOTBsQQ1wHwhO9Dc+fwT/Q2 Bw6jdZSzwQVJG13hg/uC6HqxhYfiKHtsiMuqnb5OIM0qkWa3Q/XtRclokk8elTjHYIIM+HBd i2xjys8D+1gVPI8s4NwPRAjc5m/kAXyzbrbg+p+ZVe3IJTE4M/heShLzsoFrZoroE2T38rvT Wsido/8zJZCxJ+JLAR8p8BYKYBJel/pHsvRFwSYbOEMAAwYP/j905vAZ/MJlLrElQ6eVwU2X IBhFmsOtQcVmh3CZw0QuXMA1AQsQe3KLLJSfBEP8Ljz8/Y9mPNu8wmvhw04Px0o7Ns6yOEuv v4CyQzaZwJGvn0lI4UajS7y4mgGFkd1AmPi1/4el9Yp4my88VlOcSe/macm4+MCIAMDegNLx JzErZgOMQJVdSz4rVYaWToTE/DVvRFkuEZgZNnvIv8G46OCZtnnRFv1XQDouxap2tO8yGBQ+ BxBZXqrXtyeVz1weOBIVHycUxi9kGRQ5M99NfrZuInR1382W9YYhqiVgvmvWEsLZFRoGrh8w 1yVkyxw6IGikWlkwq8TLGVlAiqA8AENZZ9bJJVOn57ld6Dvz8c8UvHpvSpUbt3Y3jf0GJbDn lj4v3ZrIxcI3RmUIGf0CQDSpqrUHppgKwiBPSLLRRQruGw7jzLpMqu7ar+2fhNQB3GLSmygi kdYXROfmIIq0J5g/rZLSFQ1GZmL3S8pqS9sJQh0KZEUE+1PtzAoYUYp9btR5Jo3pbyAn6M/g SNlSNDUwa2Eai6fy3fBu1KT1AYgntLzVyJr2Q/Wd85MjF/a9GI5X8lmnvPSAJ/ofSI/bRjLq yNj6frKLrztFV9ucWhKQoQd4iE9qe284KYqdQq4BZUhO4J2nl2rWbEquoFe9ACdIVBIuRoCH EUrreMG0tdymiEkEGBECAAkFAk04qkICGwwACgkQUq8CANPxcA6jYACfYd8EkV8G70iuPkyA HMZZ8W8lWUoAoJElB4EzU8opYiwQw02HRvW/qYuJ
Subject: Re: New confidentiality and integrity limits
Message-ID: <>
Date: Thu, 16 Jul 2020 08:47:48 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Jul 2020 06:49:02 -0000

Hi Watson,

Let me clarify that the multi-user setting does not mean that a forgery
attempt is made against all keys simultaneously -- this model still
counts "try to decrypt 1 ciphertext under 1 key" as 1 forgery attempt.
The important difference is that, for each attempt, you may try a
different key.

While the model is somewhat more general in allowing to go back and
forth between all keys, this of course also captures the QUIC setting
where only few keys are active at any point in time, and are phased
in/out sequentially. I am not aware of an intermediate model, but I
don't think the difference would be huge, plus I strongly agree with
Martin that this conservative over-approximation doesn't hurt much here.

So, the multi-user model is the closest analysis we have to answer the
question:  "What's the advantage of an adversary that tries to inject a
forgery *at some point* in a QUIC connection."
Single-user models cannot answer this question, as they only speak to
forgery attempts under one fixed key, hence don't capture key updates.

I hope this clarifies the need for multi-user bounds.


On 2020-07-16 06:58 +0200, Martin Thomson <> wrote:
> 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.