Re: New confidentiality and integrity limits
Christopher Wood <caw@heapingbits.net> Thu, 25 June 2020 18:29 UTC
Return-Path: <caw@heapingbits.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 4404C3A0F87 for <quic@ietfa.amsl.com>; Thu, 25 Jun 2020 11:29:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=heapingbits.net header.b=faGApYsh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jKmPimP+
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 wwsZWHn1bGaQ for <quic@ietfa.amsl.com>; Thu, 25 Jun 2020 11:29:39 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F0EA3A0F67 for <quic@ietf.org>; Thu, 25 Jun 2020 11:29:34 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B750E5C0159; Thu, 25 Jun 2020 14:29:33 -0400 (EDT)
Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Thu, 25 Jun 2020 14:29:33 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=P4TmE sl1Mo2CA16Z7wzSFuo+tRioQhl2SovQLAtNXB4=; b=faGApYshCXddrUlYSX6W0 bajtfKRFfLHEPePfvEZ0fBY5L4mmc4PJtEXru/93qsauZ6itV6QArm1eA/daM0RI 47nJ/Y3K0yNUnP7EQLghstb0WVojDhs37+kom6L39CLvBbF30xF4RGcTMHVM85dQ 96J/xFQzS50LzVtbifh1hrxVxVXYng22rCnUNR8UwcTuCTJC27+CzY2IYGv13VvV yXwoEr2+V/JpAy0mCIMY1BC8HcFPmJFQdn1VkeGr7tGNRl7Js0Bkpg0gGfwpZY+m QAN2DC9iWwxlNmsSEAMFodCcyEljpJnrKjpVGvP8EJRtJYttaP69te85/LB/kylu A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding: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=P4TmEsl1Mo2CA16Z7wzSFuo+tRioQhl2SovQLAtNX B4=; b=jKmPimP+3aQyPTHPmivrrFXzvcUxePVmWIvg8CMUUPvNy8ueLnOrlBHk5 30BvA5vi02B/ECdnz0ARcAPh9i8al4lL1ZGMXiFr5wDOCj4lID7FZg7Mz/PGEpJ3 qu2aMsbl0OLXPjTh/IdN58EGJghBYWXsgXwxsvwGaWlz6C3kKxCec1GPkEFWitqP MsEvNCL47xHiWodHATo02U93HOAA3tzfD+bJg0QlRcc8ucxUge2Fw/EHZDHuqho7 0v+FxlaQG+l+oTJo+oMvoMIQXridqHvgY4cemQ038Kf1gW+P1xslieaeahajJJyS v7/3fFMbG0uXcMsI5LeM7nJUZLPjA==
X-ME-Sender: <xms:De30XjsyiTGeQ0TZZPfw3EdxO8uOxjrNE0xjz_qlO_IHMUTL0JHGGA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekledguddvjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdev hhhrihhsthhophhhvghrucghohhougdfuceotggrfieshhgvrghpihhnghgsihhtshdrnh gvtheqnecuggftrfgrthhtvghrnheptdeiveeivdevieeuleelgfekfefgffffudduvefg gfffleekgfduuefggfehgfdtnecuffhomhgrihhnpehgihhthhhusgdrrdgtohhmpdhgih hthhhusgdrtghomhdpihgrtghrrdhorhhgpdhsphhrihhnghgvrhdrtghomhdprhhhuhhl rdgrtgdruhhkpdhutghsugdrvgguuhdprggtmhdrohhrghenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhs rdhnvght
X-ME-Proxy: <xmx:De30XkeB5RrUgSdShjp85oJG8WYOt21BNsg_9lrXByR9gtVA4r6eIw> <xmx:De30XmwtslzI3z3_3-4QaDvZu2oagMoBzV52sk8jV95l_0vhVDMvdw> <xmx:De30XiPLH1lQc37Eg9jHcspCYLabKiXNQ1UL46fV4r_eQjRS5VIpdg> <xmx:De30XmKJuQxzsdW3gaSbliwN2F4tiR8rEkKPUjxYzyElSmS2EjYSqQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 423393C00A1; Thu, 25 Jun 2020 14:29:33 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-543-gda70334-fm-20200618.004-gda703345
Mime-Version: 1.0
Message-Id: <58b40fc0-86ad-49e9-bc17-187c38e97f7a@www.fastmail.com>
In-Reply-To: <a4d7e8cf-5879-6941-e059-5d2f3e67ae86@huitema.net>
References: <43bb1525-0afa-4c4e-a234-f6ccfacbdd29@www.fastmail.com> <a4d7e8cf-5879-6941-e059-5d2f3e67ae86@huitema.net>
Date: Thu, 25 Jun 2020 11:29:13 -0700
From: Christopher Wood <caw@heapingbits.net>
To: Christian Huitema <huitema@huitema.net>, quic@ietf.org
Subject: Re: New confidentiality and integrity limits
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/xem4LOPR5nrleKtEvt3-gEqjWLw>
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, 25 Jun 2020 18:29:43 -0000
Hi Christian, On Wed, Jun 24, 2020, at 6:10 PM, Christian Huitema wrote: > I would like to understand how exactly we should quantify the > multi-users set. You write that "Each key used throughout the duration > of a single connection is effectively a distinct user. This means that > the attacker’s probability of success against any key in a connection > must be considered across all keys." OK, but what about keys used in > different connections, such as multiple clients connecting to the same > server, or for that matter multiple clients connecting to different > servers? Is this because all the keys used in the same connection are > derived from the same master secret? In the multi-user setting, a user is effectively a distinct key. Thus, the set of users is all keys used across all connections. (Key updates give what is effectively a new independent key, so they introduce new "users" into the system.) > If derivation from the same master secret is the issue, that means that > the protection offered by the key update function is seriously limited. > Otherwise, the keys used at different epochs would effectively be > independent. Obviously, we cannot design a new update function that > would somehow incorporate more entropy, at least not for QUIC V1. Does > that mean that the update mechanism is not very useful? Is it insecure > for applications to maintain long connections and rely on key update? > Should application rely instead on splitting the workload onto several > QUIC connection, each with its own master secret? For confidentiality, the important bit is to keep the amount of data encrypted per key "reasonably low." Running a key update before the limits are reached helps drive down the adversary's advantage. So, it's fine to maintain a long-lived connection provided the confidentiality limits are not violated and endpoints update frequently. As Martin noted, for the integrity limit, the story is slightly different. Key updates do not help there. Best, Chris > > -- Christian huitema > > On 6/24/2020 4:47 PM, Christopher Wood wrote: > > Hi folks, > > > > I'm following up here based on an issue and proposed PR I just filed against against draft-ietf-quic-tls. > > > > Issue #3788: New confidentiality and integrity limits [https://github..com/quicwg/base-drafts/issues/3788 > > PR: https://github.com/quicwg/base-drafts/pull/3789 > > > > TL;DR: We propose changing per-key limits to per-connection limits, with different margins. > > > > Ongoing analysis efforts with Jean Paul Degabriele, Felix Günther, Kenny Paterson, and Martin Thomson revealed that QUIC should consider changing its confidentiality and integrity limits to account for multi-user security settings. As some background, the existing limits in draft-ietf-quic-tls apply to a single key. They are derived from several existing analyses in the literature, including [1], [2], [3], and [4]. Concretely, they seek to bound an attacker’s advantage in breaking the security guarantees of the AEAD algorithm for a specific key in question. When a Key Update occurs, endpoints receive a new key, which resets the encryption and forgery attempt counters for this new key. > > > > This analysis fails to account for settings in which there are multiple, independent users of an AEAD algorithm, each with their own unique key. In these so-called “multi-user” settings, the attacker is allowed to perform some amount of offline work to help accelerate any attack on the AEAD algorithm. However, rather than target a single user’s specific key, they are tasked with distinguishing all traffic (under all keys) from an equal amount of random bits. In the public-key setting, Bellare et al. [5] prove that the success probability in attacking one of the many independent users (or keys) is bounded by the success probability of attacking a single user (or key) multiplied by the number of users present. (This result extends to the symmetric-key setting.) > > > > Why is this important? Each key used throughout the duration of a single connection is effectively a distinct user. This means that the attacker’s probability of success against any key in a connection must be considered across all keys. Or, more precisely, the integrity limit counters MUST NOT reset across Key Updates. (Confidentiality limits still apply for individual keys, rather than across Key Updates, since there’s no functional difference in the analyses between tearing down a connection and performing an update. The analyses consider encryption as a function of plaintext blocks protected. Thus, users that need to send N blocks of data will send N blocks of data, whether it be in one connection with many keys, or many connections with a single key.) > > > > Fortunately, this may not be much of a problem in practice. Hoang et al. [6] provide tight multi-user security bounds for AES-GCM with nonce randomization (as is used by TLS 1.3 and QUIC), and those bounds permit a higher amount than previously established for a single key. However, to the best of our knowledge, there are no multi-user security analyses giving tighter bounds than the generic analyses of AEAD_CHACHA20_POLY1305 and AEAD_AES_128_CCM. Thus, for the time being, we are stuck with the single-user integrity limits spread across Key Updates for these AEADs. Recognizing that this is a relatively new area for research, we are aiming to be quite conservative in setting limits, though we do allow an attacker a greater advantage in this multi-user attack than we would for a single connection. We may relax these limits if and when future analyses demonstrate that it’s safe to do so. > > > > Note that this is not an ideal outcome. A “true” multi-user setting would consider all users, i.e., all keys in all connections used by all QUIC clients and servers, simultaneously. However, endpoints cannot obtain such a global view of the Internet, and thus cannot make realistic parameter choices for bounds based on the number of users. The compromise struck in this PR is to consider a narrow view of multi-user security, i.e., one in which the only “users” in a connection are those introduced by Key Update messages. (This is certainly a gap in the literature worth exploring in the future.) We also recommend setting very strong targets for attacker advantage for a single key, which we estimate will ensure that an attacker still has limited advantage in the multi-user setting. > > > > Felix, Martin, and I did our best to document the basis for the analysis in this issue (and corresponding PR) in this CFRG I-D: > > > > https://github.com/chris-wood/draft-wood-cfrg-aead-limits > > > > We believe the foundations for this analysis are sound, though we are of course happy to learn if we made arithmetic mistakes. :-) > > > > Thanks, > > Chris, on behalf of Jean Paul, Felix, Kenny, and Martin > > > > [1] https://eprint.iacr.org/2012/438.pdf > > [2] https://eprint.iacr.org/2014/613.pdf > > [3] https://link.springer.com/chapter/10.1007/3-540-36492-7_7 > > [4] https://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf > > [5] https://cseweb.ucsd.edu/~mihir/papers/musu.pdf > > [6] https://dl.acm.org/doi/10.1145/3243734.3243816 > > > >
- New confidentiality and integrity limits Christopher Wood
- Re: New confidentiality and integrity limits Martin Thomson
- Re: New confidentiality and integrity limits Christian Huitema
- Re: New confidentiality and integrity limits Christopher Wood
- Re: New confidentiality and integrity limits Martin Thomson
- Re: New confidentiality and integrity limits Jana Iyengar
- Re: New confidentiality and integrity limits Martin Thomson
- Re: New confidentiality and integrity limits Lucas Pardue
- Re: New confidentiality and integrity limits Watson Ladd
- Re: New confidentiality and integrity limits Martin Thomson
- Re: New confidentiality and integrity limits Felix Günther
- Re: New confidentiality and integrity limits Lars Eggert
- Re: New confidentiality and integrity limits Watson Ladd