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

From: Martin Thomson <[email-masked]>
Date: Tue, 05 May 2020 23:56:09 -0700

@martinthomson pushed 2 commits.

4b2f0cf43f98a5b8f80e258e6f4de369e9ac8856  Update link
f94409a03ddd7a92cf1c1388e036a3eecf896853  Keep CCM

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620/files/2417e9d953bdae559dd0b2c74406da98dc75c1e1..f94409a03ddd7a92cf1c1388e036a3eecf896853

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 May 2020 00:13:45 -0700

a81e74f3a94c44735f38a943d8ad242d6e5adbed  Improve description of 'l'
5efe1df7db38536d6b9e2153e5ecb52dacb1105a  Merge branch 'master' into forgery-limit

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620/files/f94409a03ddd7a92cf1c1388e036a3eecf896853..5efe1df7db38536d6b9e2153e5ecb52dacb1105a

---

From: ianswett <[email-masked]>
Date: Wed, 06 May 2020 09:20:22 -0700

@ianswett approved this pull request.

> +The usage limits defined in TLS 1.3 exist to provide protection against attacks
+on confidentiality and apply to successful applications of AEAD protection. The
+integrity protections in authenticated encryption also depend on limiting the
+number of attempts to forge packets. TLS achieves this by closing connections
+after any record fails an authentication check. In comparison, QUIC ignores any
+packet that cannot be authenticated, allowing multiple attempts at defeating
+integrity protection.
+
+Endpoints MUST count the number of packets that are received but cannot be
+authenticated. Packet protection keys MUST NOT be used for removing packet
+protection after authentication fails on more than a per-AEAD limit. Endpoints
+MUST initiate a key update before reaching this limit. Applying a limit reduces
+the probability than attacker is able to successfully forge a packet; see
+{{AEBounds}} and {{ROBUST}}.
+
+For AEAD_AES_128_GCM and AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305 the

```suggestion
For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305 the
```

> +number of packets that fail authentication MUST NOT exceed 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 number of packets that fail authentication MUST NOT exceed
+2^24.5; see {{ccm-bounds}}.
+
+Any TLS cipher suite that is specified for use with QUIC MUST define limits on
+the use of the associated AEAD function that preserves margins for
+confidentiality and integrity. That is, limits MUST be specified for the number
+of packets that can be authenticated and for the number packets that can fail
+authentication.  Any limits SHOULD reference any analysis upon which values are
+based and describe any assumptions used in that analysis.
+
+Note:
+
+: These limits were originally calculated based using assumptions about the

```suggestion
: These limits were originally calculated using assumptions about the
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620#pullrequestreview-406773852

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 May 2020 17:17:40 -0700

@martinthomson pushed 1 commit.

acb7b227f19ac7572efb987e60f8e494e1301e32  Basic editing

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620/files/5efe1df7db38536d6b9e2153e5ecb52dacb1105a..acb7b227f19ac7572efb987e60f8e494e1301e32

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 07 May 2020 08:01:09 -0700

@LPardue commented on this pull request.

> +packets can be used to obtain the same confidentiality protection as the limits
+specified in TLS.
+

```suggestion
the probability that an attacker is able to successfully forge a packet; see
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620#pullrequestreview-407561208

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 07 May 2020 14:11:03 -0700

@janaiyengar commented on this pull request.

This seems good overall, but a few comments

> +Section 5.5 of {{!TLS13}} apply. {{!TLS13}} does not specify a limit for
+AEAD_AES_128_CCM, but the analysis in {{ccm-bounds}} shows that a limit of 2^24

What's a "per-AEAD limit"?

+For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305 the

This MUST NOT is a bit of a circuitous requirement. Perhaps "if the number of packets that fail authentication exceeds 2^36, the endpoint MUST immediately close the connection"

+integrity protection.
+
+For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305 the

similar to above

+For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305 the

This is a strange SHOULD. It's a recommendation about how the spec is to be written in the future. I would remove the normative here.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620#pullrequestreview-407814166

---

From: Martin Thomson <[email-masked]>
Date: Thu, 07 May 2020 16:47:41 -0700

7d982461c409323b5a2ba2363441c09f3d763832  Grammah

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620/files/acb7b227f19ac7572efb987e60f8e494e1301e32..7d982461c409323b5a2ba2363441c09f3d763832

---

From: Martin Thomson <[email-masked]>
Date: Thu, 07 May 2020 16:52:19 -0700

d5613bc37a4a89238782c0743c64f541c810f54a  Editorial comments, reorder

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620/files/7d982461c409323b5a2ba2363441c09f3d763832..d5613bc37a4a89238782c0743c64f541c810f54a

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 07 May 2020 17:03:57 -0700

@kazuho commented on this pull request.

Thank you for all of this. LGTM modulo the point below.

+number of attempts to forge packets. TLS achieves this by closing connections
+after any record fails an authentication check. In comparison, QUIC ignores any
+packet that cannot be authenticated, allowing multiple attempts at defeating
+integrity protection.
+
+Endpoints MUST count the number of packets that are received but cannot be
+authenticated. Packet protection keys MUST NOT be used for removing packet
+protection after authentication fails on more than a limit that is specific to
+the AEAD in use. Endpoints MUST initiate a key update before reaching this
+limit. Applying a limit reduces the probability that an attacker is able to
+successfully forge a packet; see {{AEBounds}} and {{ROBUST}}.
+
+For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305, if the
+number of packets that fail authentication exceeds 2^36, the endpoint MUST
+immediately close the connection.  Note that the analysis in {{AEBounds}}

I wonder if "MUST immediately close the connection" is correct. Our recommendation, stated above, is to do a key update.

I think it would be fine to simply say "MUST NOT exceed X."

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620#pullrequestreview-407915096

---

From: Martin Thomson <[email-masked]>
Date: Thu, 07 May 2020 17:07:28 -0700

@martinthomson commented on this pull request.

My thinking was that this is the necessary reaction if the key update was not successful before this limit was reached.  That we require a key update to be initiated before this is reached isn't any guarantee that the key update will succeed.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620#discussion_r421862841

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 07 May 2020 17:36:49 -0700

I see. Thank you for the clarification.

Then, I think that the text could become less confusing if we move "MUST close the connection" to the paragraph above, and change this paragraph to just listing the numbers.

For example, the paragraph above can be changed to something like:
_Endpoints MUST count the number of packets that are received but cannot be authenticated. If the number of packets that fail authentication exceeds a limit that is specific to the AEAD in use, the endpoint MUST immediately close the connection. Endpoints MUST initiate a key update before reaching this limit. Applying a limit reduces the probability that an attacker is able to 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..._

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620#discussion_r421871212

---

From: Martin Thomson <[email-masked]>
Date: Thu, 07 May 2020 18:39:48 -0700

9da9774ddd3638a4f85faf29893495b5855fcbe9  Editorial improvement
cdf655307293ebf7be598849ccdad0f41ce32e11  Math is hard, halve the numbers again

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620/files/d5613bc37a4a89238782c0743c64f541c810f54a..cdf655307293ebf7be598849ccdad0f41ce32e11

---

From: Felix Günther <[email-masked]>
Date: Thu, 07 May 2020 23:47:42 -0700

@fxguenther commented on this pull request.

> @@ -2158,12 +2158,12 @@ to the second, so that term can be removed without a significant effect on the
 result. This produces the relation:
 
 ~~~
-v + q <= 2^25.5
+v + q <= 2^24.5
 ~~~
 
 Using the previously-established value of 2^24 for `q` and rounding, this leads

```suggestion
Using the previously-established value of 2^23 for `q` and rounding, this leads
```

Reflecting the updated confidentiality bound.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620#pullrequestreview-408033722

---

From: Martin Thomson <[email-masked]>
Date: Fri, 08 May 2020 00:38:32 -0700

7d4f2ac708582bd6b60d00586d177af41867263a  Missed one

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620/files/cdf655307293ebf7be598849ccdad0f41ce32e11..7d4f2ac708582bd6b60d00586d177af41867263a

---

From: Martin Thomson <[email-masked]>
Date: Fri, 08 May 2020 01:04:41 -0700

f756508d497d4111c40f0f2523b90d1cd5f91abc  Explain how we got the 2l value

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620/files/7d4f2ac708582bd6b60d00586d177af41867263a..f756508d497d4111c40f0f2523b90d1cd5f91abc

---

From: Christopher Wood <[email-masked]>
Date: Fri, 08 May 2020 08:23:29 -0700

@chris-wood approved this pull request.

Thanks, @martinthomson! I derived the same bounds. This looks good to me.

 Key updates MUST be initiated before usage limits on packet protection keys are
-exceeded.  For the cipher suites mentioned in this document, the limits in
-Section 5.5 of {{!TLS13}} apply.  Other cipher suites MUST define usage limits
-in order to be used with QUIC.
+exceeded. For the cipher suites mentioned in this document, the limits in
+Section 5.5 of {{!TLS13}} apply. {{!TLS13}} does not specify a limit for
+AEAD_AES_128_CCM, but the analysis in {{ccm-bounds}} shows that a limit of 2^23
+packets can be used to obtain the same confidentiality protection as the limits
+specified in TLS.
+
+The usage limits defined in TLS 1.3 exist to provide protection against attacks

```suggestion
The usage limits defined in TLS 1.3 exist for protection against attacks
```

+integrity protection.

```suggestion
packet that cannot be authenticated, allowing multiple attempts forgery attempts.
```

> +Endpoints MUST count the number of packets that are received but cannot be
+authenticated.  If the number of packets that fail authentication exceeds a

```suggestion
Endpoints MUST count the number of received packets that fail authentication.
If the number of packets that fail authentication exceeds a
```

> +analysis of other AEAD functions in {{AEBounds}}, this analysis assumes a
+packet length of 2^10 blocks and a packet size limit of 2^14.
+
+For AEAD_AES_128_CCM, the total number of block cipher operations is the sum
+of: the length of the associated data in blocks, the length of the ciphertext
+in blocks, the length of the plaintext in blocks, plus 1. In this analysis,
+this is simplified to a value of twice the length of the packet in blocks (that
+is, `2l = 2^11`). This simplification is based on the packet containing all of
+the associated data and ciphertext. This results in a negligible 1 to 3 block
+overestimation of the number of operations.
+
+
+## Confidentiality Limits
+
+For confidentiality, Theorem 2 in {{?CCM-ANALYSIS}} establishes that an
+attacker gains an advantage over an ideal pseudorandom permutation (PRP) of no

```suggestion
attacker gains a distinguishing advantage over an ideal pseudorandom permutation (PRP) of no
```

> +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
+2^-60.
+
+
+## Integrity Limits
+
+For integrity, Theorem 1 in {{?CCM-ANALYSIS}} establishes that an attacker
+gains an advantage over an ideal PRP of no more than:

```suggestion
gains a distinguishing advantage over an ideal PRP of no more than:
```

> +analysis of other AEAD functions in {{AEBounds}}, this analysis assumes a
+packet length of 2^10 blocks and a packet size limit of 2^14.
+
+For AEAD_AES_128_CCM, the total number of block cipher operations is the sum
+of: the length of the associated data in blocks, the length of the ciphertext
+in blocks, the length of the plaintext in blocks, plus 1. In this analysis,
+this is simplified to a value of twice the length of the packet in blocks (that
+is, `2l = 2^11`). This simplification is based on the packet containing all of
+the associated data and ciphertext. This results in a negligible 1 to 3 block
+overestimation of the number of operations.
+
+
+## Confidentiality Limits
+
+For confidentiality, Theorem 2 in {{?CCM-ANALYSIS}} establishes that an
+attacker gains an advantage over an ideal pseudorandom permutation (PRP) of no

(to clarify that the harm is distinguishability from an ideal PRP, and not plaintext leakage or something.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620#pullrequestreview-408305716

---

From: Felix Günther <[email-masked]>
Date: Fri, 08 May 2020 08:28:42 -0700

+integrity protection.

```suggestion
packet that cannot be authenticated, allowing multiple forgery attempts.
```

Duplicate.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620#discussion_r422209058

---

From: Christopher Wood <[email-masked]>
Date: Fri, 08 May 2020 08:30:54 -0700

@chris-wood commented on this pull request.

+integrity protection.

:-)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620#discussion_r422210185

---

From: David Schinazi <[email-masked]>
Date: Fri, 08 May 2020 15:48:57 -0700

@DavidSchinazi commented on this pull request.

This feels like playing with fire to me. I think I'd almost prefer to remove CCM from the spec entirely, and add it as an extension document once there exists a peer-reviewed analysis that doesn't have the 2^14 record size caveat.

+limit that is specific to the AEAD in use, the endpoint MUST immediately close
+the connection.  Endpoints MUST initiate a key update before reaching this

This text feels unclear to me. It could be interpreted as "you MUST close the connection and initiate key rotation" which is silly. I think what's missing is the fact that the counter of invalid packets received is rest on key rotation. But if we have a "MUST initiate rotation", what's the point of the "MUST close the connection"?

> +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}}.
+
+Note:
+
+: 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

This sounds scary to me. It feels like the spec is saying `Computing the limits for larger packet sizes is left as an exercise to the reader.` As a reader of this specification, I personally do not feel competent to get that right.

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

Would it make sense to move this to an appendix? Ideally I would prefer for this to not be in the draft at all, and instead have a reference to a peer-reviewed paper, but I suspect that doesn't exist today.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620#pullrequestreview-408565073

---

From: Martin Thomson <[email-masked]>
Date: Sun, 10 May 2020 17:56:26 -0700

2eb8646ec7863d97336e7f8e1391391db6d57e24  Some code review suggestions

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620/files/f756508d497d4111c40f0f2523b90d1cd5f91abc..2eb8646ec7863d97336e7f8e1391391db6d57e24

---

From: Martin Thomson <[email-masked]>
Date: Sun, 10 May 2020 18:22:50 -0700

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.

 a1359d8e
 ~~~

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.

+

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:
https://github.com/quicwg/base-drafts/pull/3620#discussion_r422727856

---

From: Martin Thomson <[email-masked]>
Date: Sun, 10 May 2020 18:24:32 -0700

7958c9f2ae14aaf59ce3cc39817173cc65422dc5  Reflow

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620/files/2eb8646ec7863d97336e7f8e1391391db6d57e24..7958c9f2ae14aaf59ce3cc39817173cc65422dc5

---

From: Christopher Wood <[email-masked]>
Date: Sun, 10 May 2020 18:31:56 -0700

Yep, sorry, I misinterpreted their definition of Adv^{auth}!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620#discussion_r422734053

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 13 May 2020 20:22:02 -0700

@janaiyengar approved this pull request.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620#pullrequestreview-411438782

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 May 2020 21:22:55 -0700

ce9fde0b69b18db153239177fe1fe5e4655b295d  Limits are per key
05b02df1e77c959c0dba467baed39e525f2a4ee8  Stop using the keys, not close

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620/files/7958c9f2ae14aaf59ce3cc39817173cc65422dc5..05b02df1e77c959c0dba467baed39e525f2a4ee8

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 May 2020 22:03:38 -0700

In the interest of transparency, I have added one more commit here.

When I did the same for DTLS, ekr observed that if you have updated, you might safely stop trying to accept packets with the old keys rather than killing the connection.  That results in loss for any packets that genuinely did want to use the exhausted keys, but that is probably less disruptive than having the connection drop.  Of course, you can't always update, so closure is still likely necessary in some cases.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620#issuecomment-632482488

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 May 2020 22:04:31 -0700

> @@ -1550,12 +1550,13 @@ number of attempts to forge packets. TLS achieves this by closing connections
 after any record fails an authentication check. In comparison, QUIC ignores any
 packet that cannot be authenticated, allowing multiple forgery attempts.
 
-Endpoints MUST count the number of received packets that fail authentication.
-If the number of packets that fail authentication with the same key exceeds a
-limit that is specific to the AEAD in use, the endpoint MUST immediately close
-the connection.  Endpoints MUST initiate a key update before reaching this
-limit.  Applying a limit reduces the probability that an attacker is able to
-successfully forge a packet; see {{AEBounds}} and {{ROBUST}}.
+Endpoints MUST count the number of received packets that fail authentication for
+each set of keys.  If the number of packets that fail authentication with the
+same key exceeds a limit that is specific to the AEAD in use, the endpoint MUST
+stop using those keys.  Endpoints MUST initiate a key update before reaching
+this limit.  If a key update is not possible, the endpoints MUST immediately

```suggestion
this limit.  If a key update is not possible, the endpoint MUST immediately
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620#pullrequestreview-416649354

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 May 2020 22:05:06 -0700

874036ba9762c1cddaaf54e2dcd43d4d80297161  plural

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620/files/05b02df1e77c959c0dba467baed39e525f2a4ee8..874036ba9762c1cddaaf54e2dcd43d4d80297161

---

From: David Schinazi <[email-masked]>
Date: Fri, 22 May 2020 10:37:14 -0700

@DavidSchinazi approved this pull request.

Thanks for the edits!

+

It would be really nice to do the math for 2^16 byte packets in this document, but I'm not volunteering so I guess I can live with this as is

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620#pullrequestreview-417079978

---

From: Christopher Wood <[email-masked]>
Date: Fri, 22 May 2020 16:37:02 -0700

> It would be really nice to do the math for 2^16 byte packets in this document, but I'm not volunteering so I guess I can live with this as is

For what it's worth, Martin, Felix, and I put together a document which might help users do this themselves:

https://github.com/chris-wood/draft-wood-cfrg-aead-limits

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620#issuecomment-632944131

---

From: David Schinazi <[email-masked]>
Date: Fri, 22 May 2020 18:15:36 -0700

@chris-wood Could you use that to come up with 2^16 limits and put them in the doc? I’m really wary of letting implementors roll their own

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620#issuecomment-632961218

---

From: Christopher Wood <[email-masked]>
Date: Sat, 23 May 2020 07:16:22 -0700

> @chris-wood Could you use that to come up with 2^16 limits and put them in the doc? I’m really wary of letting implementors roll their own

Sure! Can you file an issue with that request?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620#issuecomment-633062212

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 May 2020 15:30:01 -0700

bfc409bb529d6a248f4ed20cac3c3d1d204a75ae  Forgeries likely exhaust TWO keys
3a1f14b85b5528cf230251a6924f5d0b5581859d  Merge pull request #3686 from quicwg/forgeries-and-updates

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3620/files/874036ba9762c1cddaaf54e2dcd43d4d80297161..3a1f14b85b5528cf230251a6924f5d0b5581859d