Subject: Re: [quicwg/base-drafts] Expand AEAD limits to consider multi-user security. (#3789)

From: Christopher Wood <[email-masked]>
Date: Thu, 13 Aug 2020 05:50:09 -0700

@chris-wood commented on this pull request.

> -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 endpoint MUST immediately
-close the connection.  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 encrypted packets for each set of keys. If
+the total number of encrypted packets with the same key exceeds the
+confidentiality limit for the selected AEAD, the endpoint MUST stop using those
+keys. Endpoints MUST initiate a key update before sending more protected packets
+than the confidentiality limit for the selected AEAD permits. If a key update
+is not possible or integrity limits are reached, the endpoint MUST stop using
+the connection and only send stateless resets in response receiving packets. It
+is RECOMMENDED that endpoints immediately close the connection with a connection
+error of type PROTOCOL_VIOLATION before reaching a state where key updates are

We can use `AEAD_LIMIT_REACHED` as Martin suggests below.

-- 
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/3789#discussion_r469926127

---

From: Christopher Wood <[email-masked]>
Date: Thu, 13 Aug 2020 05:50:20 -0700

> +error of type PROTOCOL_VIOLATION before reaching a state where key updates are
+not possible.
+
+For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the confidentiality limit is 2^25
+encrypted packets; see {{gcm-bounds}}. For AEAD_CHACHA20_POLY1305, the
+confidentiality limit is greater than the number of possible packets (2^62) and
+so can be disregarded. For AEAD_AES_128_CCM, the confidentiality limit is 2^23.5
+encrypted packets; see {{ccm-bounds}}. Applying a limit reduces the probability
+that an attacker can distinguish the AEAD in use from a random permutation; see
+{{AEBounds}}, {{ROBUST}}, and {{?GCM-MU=DOI.10.1145/3243734.3243816}}.
+
+In addition to counting packets sent, endpoints MUST count the number of
+received packets that fail authentication during the lifetime of a connection.
+If the total number of received packets that fail authentication within the
+connection, across all keys, exceeds the integrity limit for the selected AEAD,
+the endpoint MUST immediately close the connection and not process any more

`AEAD_LIMIT_REACHED` works for me!

-- 
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/3789#discussion_r469926248

---

From: Christopher Wood <[email-masked]>
Date: Thu, 13 Aug 2020 05:54:53 -0700

@chris-wood pushed 1 commit.

950c6ae004446b2ba0dba4156d1002eaf13dee81  Add a new AEAD limits error code, and clearly differentiate between the usage limits.

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3789/files/8833f007c9fd77e438e5d99aee40a52e32412426..950c6ae004446b2ba0dba4156d1002eaf13dee81

---

From: Christopher Wood <[email-masked]>
Date: Thu, 13 Aug 2020 05:55:06 -0700

I took a stab at this. Please feel free to make suggestions or edits as you see fit!

-- 
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/3789#discussion_r469928977

---

From: ekr <[email-masked]>
Date: Fri, 28 Aug 2020 11:57:11 -0700

@ekr approved this pull request.

+{{AEBounds}}, {{ROBUST}}, and {{?GCM-MU=DOI.10.1145/3243734.3243816}}.
+
+In addition to counting packets sent, endpoints MUST count the number of
+received packets that fail authentication during the lifetime of a connection.
+If the total number of received packets that fail authentication within the
+connection, across all keys, exceeds the integrity limit for the selected AEAD,
+the endpoint MUST immediately close the connection with a connection error of
+type AEAD_LIMIT_REACHED and not process any more packets.
+
+For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the integrity limit is 2^54 forged
+packets; see {{gcm-bounds}}. For AEAD_CHACHA20_POLY1305, the integrity limit is
+2^36 forged packets; see {{AEBounds}}. For AEAD_AES_128_CCM, the integrity limit
+is 2^23.5 forged packets; see {{ccm-bounds}}. Applying this limit reduces the
+probability that an attacker can successfully forge a packet; see {{AEBounds}},
+{{ROBUST}}, and {{?GCM-MU}}.

Nit: I wouldn't use "forged" here but rather "invalid". We don't know why they are invalid.

-- 
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/3789#pullrequestreview-477957946

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 28 Aug 2020 12:22:43 -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/3789#pullrequestreview-477972417

---

From: David Schinazi <[email-masked]>
Date: Fri, 28 Aug 2020 13:14:27 -0700

@DavidSchinazi approved this pull request.

Overall I think this is ready to merge. I left some small editorial nits

> @@ -2281,7 +2293,89 @@ the associated data and ciphertext. This results in a negligible 1 to 3 block
 overestimation of the number of operations.

-## Confidentiality Limits
+## Analysis AEAD_AES_128_GCM and AEAD_AES_256_GCM Usage Limits {#gcm-bounds}

Should this be Analysis *of* AEAD_... ?

> +simplifying assumptions:
+
+- The number of ciphertext blocks an attacker uses in forgery attempts is
+bounded by v * l, the number of forgery attempts and the size of each packet (in
+blocks).
+
+- The amount of offline work done by an attacker does not dominate other factors
+in the analysis.
+
+The bounds in {{?GCM-MU}} are tighter and more complete than those used in
+{{AEBounds}}, which allows for larger limits than those described in {{?TLS13}}.
+
+
+### Confidentiality Limit
+
+For confidentiality, Theorum (4.3) in {{?GCM-MU}} establish that - for a single

s/establish/establishes/ ?

> @@ -1552,30 +1549,40 @@ 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.

I'll second that. IKEv2 simultaneous key update is so complicated that most configurations I've seen intentionally use different limits on both endpoints to reduce the odds of a simultaneous rekey. In QUIC however, simultaneous rekey has the same complexity as regular rekey so I don't think it's worth working around.

New text looks great to me, thanks!

-- 
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/3789#pullrequestreview-477989779

---

From: Martin Thomson <[email-masked]>
Date: Sun, 30 Aug 2020 17:20:11 -0700

@martinthomson pushed 1 commit.

6ada1ac4688ca050869c7f72c6f256ba27cccd8b  Nits

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3789/files/950c6ae004446b2ba0dba4156d1002eaf13dee81..6ada1ac4688ca050869c7f72c6f256ba27cccd8b

---

From: Martin Thomson <[email-masked]>
Date: Sun, 30 Aug 2020 17:23:43 -0700

1ab46496fb69c603d1e57f3c5f15f0e0a34d9155  rap

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3789/files/6ada1ac4688ca050869c7f72c6f256ba27cccd8b..1ab46496fb69c603d1e57f3c5f15f0e0a34d9155