Re: Forgery limits in QUIC

Matt Joras <> Fri, 01 May 2020 20:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF9433A1BDE for <>; Fri, 1 May 2020 13:10:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lyipj4fL809Z for <>; Fri, 1 May 2020 13:10:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::a2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B09E43A1BDB for <>; Fri, 1 May 2020 13:10:45 -0700 (PDT)
Received: by with SMTP id n207so2987198vkf.8 for <>; Fri, 01 May 2020 13:10:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PjyY/JEZlEaDeN26cddjKwdDhC84T9oZVOHiqguVz6M=; b=tpVdNNc12dllPuIzCqWQEkThkOFwBkibmfiGBFsgwUae2RVFSxAE4ejOiHJGkD7NPk lUG3GJsVgRzZWTu/dgwMrGbbMI1YThfTSWjwOi49eU3JIdOKpcv3XlsieGR3k2xMB77+ zuRyLK1qdIBFcp5YRnzOEDaXXcTenmzu0J/4eNccXfPqhsY2auuhtyxWOFbHtTWhe8hw NKRQzEsdwuuIBXwZbXYPZXNe7DV52lncP7+B0iL/xGNTn46EIlSaTKXQu7gpA4oOa7oW F4keU+UOj8vHRde6QVUmC0lbdCZzJtg6rqiYz39iipeN5/Um4y2LsnnJE4k+/5T7MpXu K1Dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PjyY/JEZlEaDeN26cddjKwdDhC84T9oZVOHiqguVz6M=; b=dGd/ZR/9l4i6BwMe9+QnXinlZDcAmXVNyiJ5iGRM/Gpu1y9GQsYpbeqFxtJixSZKvF /9Z+rnWZn14vwQzyprLwLSSEU5lxLWaMSJKlreQmfS8z+AamZ425uXJWq+2QHsmt44re Zj9AkO3yAFkfv0cI09boTfBLlEtjVi3eNjfj+D4+A1lSsc6dGIUnNiRTsKDw5oOxcHzX XJ6b8fgqLspHWNWPS3cBoIHMYFC6VcnL8qXFzc9i5klqQGq/Rk/3LSGceP0ysJVPMgXb eDF6B7xEhybboBPSyk4q2n7bHIoEczhjfXyi+GCKiOda+Su31sUs++rNV27kxSFUeHTr 7tfA==
X-Gm-Message-State: AGi0PuZsQWCxzVWXRbODrowa+MXHq7MHQQQKBxplqYr49kDKHidlA7MN 7uzYxJuhwxAxvR+4O9Y54YeGS3sKFKAs60aI4HEwSa3e
X-Google-Smtp-Source: APiQypJSy3gQjXjo0ET15xberY/fJnd6iv98qBnMjXS6HLvgZDbDNJbvkkD2GzAtIlBlkLCHAjw4jT9n143w64JLZEk=
X-Received: by 2002:a1f:3190:: with SMTP id x138mr4100959vkx.41.1588363844471; Fri, 01 May 2020 13:10:44 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Matt Joras <>
Date: Fri, 1 May 2020 13:10:32 -0700
Message-ID: <>
Subject: Re: Forgery limits in QUIC
To: Martin Thomson <>
Content-Type: multipart/alternative; boundary="000000000000b94e8b05a49bc644"
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: Fri, 01 May 2020 20:10:51 -0000

On Thu, Apr 30, 2020 at 11:15 PM Martin Thomson <> 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
> 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
> >
> > 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.
> >
> >