Re: New confidentiality and integrity limits

Lars Eggert <> Tue, 21 July 2020 06:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C26F33A0EE7 for <>; Mon, 20 Jul 2020 23:50:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id izjmBpNEiBb7 for <>; Mon, 20 Jul 2020 23:50:01 -0700 (PDT)
Received: from ( [IPv6:2a00:ac00:0:35:211:32ff:fe22:186f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1685A3A0E9E for <>; Mon, 20 Jul 2020 23:50:01 -0700 (PDT)
Received: from [IPv6:2a00:ac00:0:35:e9f7:316e:5e24:9364] (unknown [IPv6:2a00:ac00:0:35:e9f7:316e:5e24:9364]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4FB88650833; Tue, 21 Jul 2020 09:49:51 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=dkim; t=1595314191; bh=hZcBl8Mo2Y+92e5U0GKGwug2iVvYbbC9mfPpaV3vwlI=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=zfApQKRhgDcnDDmLIKK+fqknyVf4V1y+CkzkJckcQTptjymaKH6UBdc8N1WCsyZCd TZ4QViBpamM6kc95kpLw07+qN+Xk2X9mnJ78w49/oBlbQkCa/A3wP+DFkHOlfLUJqh yHnzjkL5RMRNJZPkLPGvLftyeqJWyyXIMwdzpt7Y=
From: Lars Eggert <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_13C38EE8-85C9-4181-81D5-810FB6C1A20D"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Subject: Re: New confidentiality and integrity limits
Date: Tue, 21 Jul 2020 09:49:51 +0300
In-Reply-To: <>
To: =?utf-8?Q?Felix_G=C3=BCnther?= <>
References: <> <> <> <> <> <> <> <> <> <>
X-MailScanner-ID: 4FB88650833.A100A
X-MailScanner: Found to be clean
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: Tue, 21 Jul 2020 06:50:03 -0000

Thanks, Felix.

Watson, does this address your comments? (Chairs are trying to push #3788 to resolution.)


On 2020-7-16, at 9:47, Felix Günther <> wrote:
> 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.
> Cheers,
> Felix
> 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.