Re: New confidentiality and integrity limits

Watson Ladd <watsonbladd@gmail.com> Wed, 22 July 2020 12:38 UTC

Return-Path: <watsonbladd@gmail.com>
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 399163A0B27 for <quic@ietfa.amsl.com>; Wed, 22 Jul 2020 05:38:57 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=gmail.com
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 BlcEwOR14qjJ for <quic@ietfa.amsl.com>; Wed, 22 Jul 2020 05:38:55 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 424C43A0B1B for <quic@ietf.org>; Wed, 22 Jul 2020 05:38:55 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id i19so1213524lfj.8 for <quic@ietf.org>; Wed, 22 Jul 2020 05:38:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cwIYBSFbY44LDVwgwdoFV6wgv3WPNiWSnWTSXT+DZuY=; b=INSyqyis9VHnyG/uLQMo27bsTCjNA4YhUJ/xBX/I8JL70Z98JRkiNS7k0XRFq50Afp 65Re7lnCpQ9pufT7skL+W7SwDXWdXow+iFVYuHuRCOOAqmRayEfMizHo02wJDMAIrpoe US22uG4dgbKFXKh1LoZzNI95T8C95fpepG7D7fxIINYrAODtKLkO675y0l0WBkiQ+qrm DnmeOTZdYxxLaYLYMkHtPKTCSci41Zo4u9RWCgs5jYnmdW4WV02zBTROiZe5vBs3e0K7 xOM/3pIanMIW9FhlVCBR85Bubiw4feHs9D/TP7rKF/ewpJBpSUGNzEfcgAjdJqJXFwS1 lxrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cwIYBSFbY44LDVwgwdoFV6wgv3WPNiWSnWTSXT+DZuY=; b=GH5JIyN9gPgLwR0Xc07oulSquhAeL02F5Lt4e0ofeFEhXFv/JZxBQhgiZgcM5pC/s6 b4AkYcR5zixs3PMPR6twkZccMEc7pLluTSveMDt7JPre6ymsTUep/HDc1uQ7Au/Bj57G h/HwFEBLNAAWSnfGKIMT83dsO+aS3GIJypAmK0GHL8SB+wgl6owFHA323eKwNsgLnCho wE4vIWtif/UdxmNPdrgPoDiUPir/+3bkrPgOLxRm1XZjSOdPIbMK3T+YCqV/fw5LDzbN pNUJAqobdTA/VXQNvzA23KxQG7BHzHjlS3cSx4EpnQpwKCzqjUpo1KmL1OQwfjpcGe7H SkAQ==
X-Gm-Message-State: AOAM530rmN6ZG7G3dqxdvF/VUBiG1IDobKpd02hd7c67yISBW2kFSUKf Y2txSjtp3dByDbTaH8eoKLFZUn9GYyQeiiEblgqwFTud
X-Google-Smtp-Source: ABdhPJyP+Y4iTJ81T3tG82QgHXA+V6cV3k+my2DtTfJ0mO114/LE7pkpcHMPn5RaAjV+ZCTClkzU7z0RWvftt3kjgew=
X-Received: by 2002:a05:6512:3249:: with SMTP id c9mr16117993lfr.216.1595421533523; Wed, 22 Jul 2020 05:38:53 -0700 (PDT)
MIME-Version: 1.0
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> <04697AEF-461E-46C8-B1EC-B15D462B8B7E@eggert.org>
In-Reply-To: <04697AEF-461E-46C8-B1EC-B15D462B8B7E@eggert.org>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Wed, 22 Jul 2020 08:38:42 -0400
Message-ID: <CACsn0cm8QUgKmHeJH52YgYCR9294N2Cez5_Qg7ZMtEkRdWgJvA@mail.gmail.com>
Subject: Re: New confidentiality and integrity limits
To: Lars Eggert <lars@eggert.org>
Cc: =?UTF-8?Q?Felix_G=C3=BCnther?= <mail@felixguenther.info>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c5d44905ab0705b3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/KPtYqIz2GUbgfLObh2YfDKUHnbg>
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: Wed, 22 Jul 2020 12:38:57 -0000

On Tue, Jul 21, 2020, 2:50 AM Lars Eggert <lars@eggert.org> wrote:

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

Yes. I am still confused but it's clear I need to think harder about multi
user.


> 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.
> >>
> >
>
>