Re: Forgery limits in QUIC

Martin Thomson <> Fri, 01 May 2020 06:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F1433A0988 for <>; Thu, 30 Apr 2020 23:15:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=D+CgQ7dt; dkim=pass (2048-bit key) header.b=w6CZJZTi
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EFCctPAYo5rM for <>; Thu, 30 Apr 2020 23:15:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 719DE3A0986 for <>; Thu, 30 Apr 2020 23:15:17 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id C18CF5C019B for <>; Fri, 1 May 2020 02:15:16 -0400 (EDT)
Received: from imap2 ([]) by compute2.internal (MEProxy); Fri, 01 May 2020 02:15:16 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=qNt9A LRsSy8wJ7d26DxvfhQLFkB8RGnRknnpH4LZKP4=; b=D+CgQ7dtJbMPVq7noUzCB HCGOD/zXlBywVzkZW4LNUwfpowOr/dMNH+RBxcO2+eLcRrBceznpNBeORfE4LRmq po23fSkfzoDd05oO1TyLVNoseqS1ReCgiFmdI96SHs4Dw5KPYBMMhlzpCFkqUEob hGMCDAS+8Hhd4h4Gw4TDs/iKlaABKvx1NrHTydrrGD+MtChq5UWkaa6/KK8+sIeR eDHazF9dwW6LXaKjTsWNuv0CgJFd+LRZKD2ctC3VSJasbBT1jGQnCs4OcoALD0x2 0bUNigSxbqDEH5Wz99eALOLOjF4WShS9gcPdz7W/DQXfCNxrEyAHclpWY6E0wHJr Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; 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=fm2; bh=qNt9ALRsSy8wJ7d26DxvfhQLFkB8RGnRknnpH4LZK P4=; b=w6CZJZTiFgkNuVBBdpLMaFyq8t0TcYUJohU5yNDrMbVMBV4VM4xczW0du jlJWLbF3lUcvcBNgbTXmR5HaLiw/x+KX2Yca/dMeNBw0FY/5tMXvSg+eRQV7hNc4 E5mMf+HgkBkFPaK8OUk1RMzT7noaMUyNDFWGzQggs1zanZ0rmr6JV1HKi2nJdRv8 CShrgfHfZuBsaI33QKC9mZbK2hFW6EnYkvDqGL8pLbaZAd20f01Pn/fXaLb2uo3C 8YeTR1IYOb8f1OKslmKgF0i73zrgslPQQ3yCNo5Qyf5046yreu0k1P6QR5ErK2Pv +S/aVKeNvS8fZgu+qkVluxAI/8+bQ==
X-ME-Sender: <xms:dL6rXok1Rqrrz7dDtq8Bg6ozje4xO1bjcqVHKmUJmu5i2Kccc2iKdw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrieeigddutddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepjefhffelheevudefje efvddvhfdvieetudehueffudevudeugeelfeffffelvdefnecuffhomhgrihhnpehgihht hhhusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:dL6rXgl9clnVRI93PMwa60lgKSrvSB2pN04ohvnpdjcWCJcWHgTClg> <xmx:dL6rXlVyAE_hVNKInz5KEMZxw4faI17C5IU147hZfO_KV_qyvlXH4g> <xmx:dL6rXm-jX4j8azstQxg78l8P55zNf4RaN4knNTFFoF7AP-MdJrkE_w> <xmx:dL6rXgVip_r3ZVMA1HumGb9WofqHaG1Ym4ZBJlyfl8ymqV1w4aZXzQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 77FC9E00A9; Fri, 1 May 2020 02:15:16 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <>
Date: Fri, 01 May 2020 16:14:58 +1000
From: "Martin Thomson" <>
Subject: Re: Forgery limits in QUIC
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
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 06:15:20 -0000

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.

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.