Re: [quicwg/base-drafts] Define an anti-forgery limit (#3620)

Martin Thomson <> Mon, 11 May 2020 01:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C8BF13A0C7C for <>; Sun, 10 May 2020 18:22:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.101
X-Spam-Status: No, score=-3.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AfGYbp6RB1pq for <>; Sun, 10 May 2020 18:22:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 774613A0C78 for <>; Sun, 10 May 2020 18:22:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 95EC3960592 for <>; Sun, 10 May 2020 18:22:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1589160170; bh=4OyCR7uizvVjCz1TJD2tAV9F7ZsOQv3aLYk0dPbfWg8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=JKhGt39PSj2wiDBJrhHEj5a8LgiMriOGcps7MGzNEogLzK0MCDdl92wRm5S8sMuut Uutb1gyElXJR4yRrZCZke9h253yr5M4+I/vkRWDxYJGZt1wpSvxywJU1vbFU7F43zc 2oZ4E1y90qTKtXOSMdaFhRT4nbzthm8FHFCKc1Ck=
Date: Sun, 10 May 2020 18:22:50 -0700
From: Martin Thomson <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3620/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Define an anti-forgery limit (#3620)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5eb8a8ea7e41c_5f353fc12d4cd9602239a"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 May 2020 01:22:54 -0000

@martinthomson commented on this pull request.

> +For a target advantage of 2^-60, which matches that used by {{!TLS13}}, this
+results in the relation:
+q <= 2^23
+That is, endpoints cannot protect more than 2^23 packets with the same set of
+keys without causing an attacker to gain an larger advantage than the target of
+## Integrity Limits
+For integrity, Theorem 1 in {{?CCM-ANALYSIS}} establishes that an attacker
+gains an advantage over an ideal PRP of no more than:

I don't think that this is a distinguishing advantage, but a forgery advantage.  That is, the odds of being able to forge increase, not to determine whether a forgery would be successful without consulting the oracle.

> @@ -2029,6 +2079,104 @@ ffff00001b0008f067a5502a4262b574 6f6b656ea523cb5ba524695f6569f293
+# Analysis of Limits on AEAD_AES_128_CCM Usage {#ccm-bounds}

This is an appendix :)

And yeah, I'm not all that happy that this is not in a peer-reviewed paper, but TLS didn't have that either.  The mitigating factors are that this is being carefully reviewed (my two screwups so far have been caught), and the math is fairly simple once you get past the layers of obfuscation.

> +successfully forge a packet; see {{AEBounds}} and {{ROBUST}}.
+For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305, the limit on
+the number of packets that fail authentication is 2^36.  Note that the analysis
+in {{AEBounds}} supports a higher limit for the AEAD_AES_128_GCM and
+AEAD_AES_256_GCM, but this specification recommends a lower limit.  For
+AEAD_AES_128_CCM, the limit on the number of packets that fail authentication
+is 2^23.5; see {{ccm-bounds}}.
+: These limits were originally calculated using assumptions about the
+  limits on TLS record size. The maximum size of a TLS record is 2^14 bytes.
+  In comparison, QUIC packets can be up to 2^16 bytes.  However, it is
+  expected that QUIC packets will generally be smaller than TLS records.
+  Where packets might be larger than 2^14 bytes in length, smaller limits might

Yes, that is what it says.  And it should be scary.  That is, if you want 64k packets, be prepared to read the papers.  (However, if someone ignores this, the damage isn't that bad, as the worst effect from this set of AEADs is in reducing the margin by a factor of 16 to 2^-56/2^-53, which is still small.)

It also says that the margins are usually better in practice than the analysis permits.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: