Re: New confidentiality and integrity limits

Lars Eggert <lars@eggert.org> Tue, 21 July 2020 06:50 UTC

Return-Path: <lars@eggert.org>
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 C26F33A0EE7 for <quic@ietfa.amsl.com>; Mon, 20 Jul 2020 23:50:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
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 izjmBpNEiBb7 for <quic@ietfa.amsl.com>; Mon, 20 Jul 2020 23:50:01 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [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 ietfa.amsl.com (Postfix) with ESMTPS id 1685A3A0E9E for <quic@ietf.org>; 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 mail.eggert.org (Postfix) with ESMTPSA id 4FB88650833; Tue, 21 Jul 2020 09:49:51 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; 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 <lars@eggert.org>
Message-Id: <04697AEF-461E-46C8-B1EC-B15D462B8B7E@eggert.org>
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.120.23.2.1\))
Subject: Re: New confidentiality and integrity limits
Date: Tue, 21 Jul 2020 09:49:51 +0300
In-Reply-To: <02f5d291-4b95-7f94-5028-c90f94bd5908@felixguenther.info>
Cc: quic@ietf.org
To: =?utf-8?Q?Felix_G=C3=BCnther?= <mail@felixguenther.info>
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> <19922b1a-a02c-46c9-b441-3806d3f77b89@www.fastmail.com> <02f5d291-4b95-7f94-5028-c90f94bd5908@felixguenther.info>
X-MailScanner-ID: 4FB88650833.A100A
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/mP10Rh4j7T8CyLlBnkA-dOFHEfU>
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: Tue, 21 Jul 2020 06:50:03 -0000

Thanks, Felix.

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

Thanks,
Lars

On 2020-7-16, at 9:47, Felix Günther <mail@felixguenther.info> 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 <mt@lowentropy.net> 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.
>> 
>