Re: Forgery limits in QUIC

Ian Swett <ianswett@google.com> Fri, 01 May 2020 21:48 UTC

Return-Path: <ianswett@google.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 1499B3A13FF for <quic@ietfa.amsl.com>; Fri, 1 May 2020 14:48:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.598
X-Spam-Level:
X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 YrMzYgWrQokp for <quic@ietfa.amsl.com>; Fri, 1 May 2020 14:48:35 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 3C10D3A142A for <quic@ietf.org>; Fri, 1 May 2020 14:48:35 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id h9so2879738wrt.0 for <quic@ietf.org>; Fri, 01 May 2020 14:48:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fBmiTgqy9xPfU88d03flxyyNHwdhoZDaS73SvCqST5w=; b=aKOJiSNzBl/oEM+nuu3Irmlg4aAzmII9dDKD0ROdy+oXfTU6XCYElE64FWppKybWb6 IonTF3x2UOc1Vz2paNXFSfG1MY5D9ZXVJ7QHCTZOVV4SiFpgWRpNVMG/aeiyqEVpIhio EjqqIpNKVbZjAMap6GMTna+Z9V+pO7Ulb+HAx2w5jp9YiwyQIUT8/Ks9vcoAAXMHFFyv wLu7i3nsZNl9dMVghwZZWVwQJl3MFyN8LsG/bE9mSxYpsACOIVcZ3nw2nkJXx6OwAIh0 LP1OvOXVAVhR95ZuckR99m9pw+fZB25PaBuCNwAkcQsgLRa4TeVWAvC+Gt+UxAXnLEKx /IBw==
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=fBmiTgqy9xPfU88d03flxyyNHwdhoZDaS73SvCqST5w=; b=gplOhvrabsuFvRs0Yk3NQl77VUG6onuohLLdbyeg7pAg0ur1oqLKH1NHyaPWoKT/Vv RyFWNvplz9Tfc6AzW0OMHSC/H7nmJ92GZJb48FZfeK9THy7qsTew93h3KOQkz2h6boQT 0qQd64uimBRB60HfskVfhx5QpcEu13FGDodOSbLc4FmiZyA1bTTZ/wmxi1NXhKhYvKiI zQSXDaKYurZfQ7AYeK+NCfZnWvPD908lEVPHREYgRiZhKOga465ymll4JIKzRbobwzoy dbh3TdAKC5WxRoBf5+hr5pQ6QQHYaHhoA8GEf7qhYsIzcsAI+MVbOsQjw6sB6uDPwB3g hrAQ==
X-Gm-Message-State: AGi0PuZhu9Cng9MZwk608oFk/1n5hNgqY4NVtb+r6TJkIHo0DIFVQwhD n0pLwfdeV4xAX5k9qTLaz5otAuHDBpRzku125jaxNQ==
X-Google-Smtp-Source: APiQypLQNq2wxIO91T6wcFSj/KvIu8Gv6VubrLvtQN5VmxybTkwCBme0P2mKyhyK0xii9hQJXIVm9KjtG9J2nBsTOdM=
X-Received: by 2002:a5d:4f06:: with SMTP id c6mr6590581wru.12.1588369713422; Fri, 01 May 2020 14:48:33 -0700 (PDT)
MIME-Version: 1.0
References: <c32379cb-43c1-4db8-9f0a-b7294085dd6d@www.fastmail.com> <d7f385d4-b6cb-4565-ba35-4c096239fd34@www.fastmail.com> <CADdTf+jMUfoNsXcBD_-cVN0JhH4X8ESUyi91N9q6mx-m8iy6QQ@mail.gmail.com>
In-Reply-To: <CADdTf+jMUfoNsXcBD_-cVN0JhH4X8ESUyi91N9q6mx-m8iy6QQ@mail.gmail.com>
From: Ian Swett <ianswett@google.com>
Date: Fri, 1 May 2020 17:48:20 -0400
Message-ID: <CAKcm_gN+nthtpnRo+cRCPFZ0iN63vqtVGiG-bWy4Tn1gBVssgA@mail.gmail.com>
Subject: Re: Forgery limits in QUIC
To: Matt Joras <matt.joras@gmail.com>
Cc: Martin Thomson <mt@lowentropy.net>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008ad32705a49d240c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/oNGUmM6hi-T4afgMDcdYsZLM2CM>
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: Fri, 01 May 2020 21:48:42 -0000

Dropping AEAD_AES_128_CCM is fine for us, since we don't use it.

On Fri, May 1, 2020 at 4:11 PM Matt Joras <matt.joras@gmail.com> wrote:

> On Thu, Apr 30, 2020 at 11:15 PM Martin Thomson <mt@lowentropy.net> wrote:
>
>> OK, I thought this would be easy.  I was wrong.  But it still might be
>> easy.
>>
>> The draft currently defines four AEAD functions.  We have a good analysis
>> for three of those functions.  We lack an analysis of the last.  That is
>> AEAD_AES_128_CCM.
>>
>> It turns out that we never really had a good analysis of CCM.  TLS 1.3
>> conveniently fails to say anything about it.
>>
>> My suggestion is that we remove CCM from QUIC until we have an
>> understanding of its robustness against confidentiality attacks with
>> multiple successful applications of protection AND integrity attacks with
>> multiple forgery attempts.  We need to base our recommendations about
>> limits on something more than what we have now.
>>
>> I realize that this is a fairly dramatic change, but I think we need to
>> hold our ciphers to a high standard.  I will attempt to find an analysis
>> myself, as I would expect it to exist, but I have a poor history of success
>> finding the right cryptographic paper.  If anyone is able to provide
>> pointers, that would be appreciated.
>>
> Is it actually a fairly dramatic change? The supported cipher suite is not
> a huge consideration for us, and I would guess this is generally true.
> We've only implemented AEAD_AES_128_GCM and AEAD_AES_256_GCM. Perhaps this
> is more of a concern for those wishing to ship embedded stacks, since AFAIK
> CCM is nominally simpler to implement?
>
> Removing it seems straightforward unless someone was has a good reason to
> want to ship CCM specifically.
>
>
>> On Fri, May 1, 2020, at 14:45, Martin Thomson wrote:
>> > I have just opened https://github.com/quicwg/base-drafts/issues/3619
>> >
>> > tl;dr We need to recommend limits on the number of failed decryptions.
>> >
>> > I am now working on a pull request to add this to the spec.
>> >
>> > I realize that we're nearing the end, but this is an important security
>> > improvement and the result of some good work by cryptography
>> > researchers, who have done a lot to improve our confidence that QUIC
>> > can deliver on its promises of providing confidentiality and
>> integrity...
>> >
>> > A big thanks to Felix G√ľnther, Marc Fischlin, Christian Janson, and
>> > Kenny Paterson for their work on this.
>> >
>> >
>>
>>