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

From: Christopher Wood <[email-masked]>
Date: Thu, 09 Jul 2020 07:59:07 -0700

@chris-wood pushed 7 commits.

ed9bbfc7a712b67466842abef03932dbf369dc1e  Update AEAD limits
2755bcaeeea1f9f6f39f689ceae09d6fadb89ad3  Attempt to address some of the other questions
ed028b24ad451e18daa5c91412296f3c8be4f70c  Fix error in adding v to confidentiality calculation
5ef5f06828fe97cc38200b92cadf889c28b32833  Fix heading levels
2e1f5297e5840ee849f213387404053dbe91a4ec  Restore factor of 2
6f58815715679ac0e05ceb8386f7667ca912de9b  Update draft-ietf-quic-tls.md
9dd23dcab6f3eec466284cc8355341875b2fef88  Merge pull request #2 from quicwg/aead-limits2

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3789/files/69be76608b8f7a81d2e64e210121ddbbe1788c78..9dd23dcab6f3eec466284cc8355341875b2fef88

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Jul 2020 00:23:11 -0700

@martinthomson pushed 1 commit.

4e9c4a51dce5a66f3867e289727d01b63d8cd4ae  Merge branch 'master' into caw/mu-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/9dd23dcab6f3eec466284cc8355341875b2fef88..4e9c4a51dce5a66f3867e289727d01b63d8cd4ae

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Jul 2020 00:24:07 -0700

8c094e9815d402f9c8f4aa4a5d4f8c19995ff14f  Trim whitespace

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3789/files/4e9c4a51dce5a66f3867e289727d01b63d8cd4ae..8c094e9815d402f9c8f4aa4a5d4f8c19995ff14f

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Jul 2020 00:34:58 -0700

8833f007c9fd77e438e5d99aee40a52e32412426  Loooong line

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

---

From: Christopher Wood <[email-masked]>
Date: Tue, 14 Jul 2020 06:05:25 -0700

(Thanks, @martinthomson!)

-- 
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#issuecomment-658167249

---

From: Christian Huitema <[email-masked]>
Date: Wed, 15 Jul 2020 11:57:31 -0700

@huitema commented on this pull request.

> @@ -2207,10 +2206,14 @@ v:
   bound on the number of forged packets that an endpoint can reject before
   updating keys.
 
-The analysis of AEAD_AES_128_CCM relies on a count of the number of block
-operations involved in producing each message. For simplicity, and to match the
-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.
+o:
+
+: The amount of offline ideal cipher queries made by an adversary.
+
+The analyses that follow rely on a count of the number of block operations
+involved in producing each message. For simplicity, and to match the analysis of
+other AEAD functions in {{AEBounds}}, this analysis assumes a packet length of
+2^10 blocks; that is, a packet size limit of 2^14 bytes.

When people say 2^11, do they think 1536 bytes? This is indeed a common packet size. The next interesting size are probably in the "jumbo frame" range -- see for example 9001 bytes mentioned for [AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html#jumbo_frame_instances). That would be 2^14. And then the UDP limit is indeed 2^16.

-- 
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_r455273080

---

From: David Schinazi <[email-masked]>
Date: Wed, 15 Jul 2020 13:10:36 -0700

@DavidSchinazi 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

I don't think PROTOCOL_VIOLATION makes sense here, the peer did not violate the protocol

> @@ -1606,30 +1603,41 @@ 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 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

typo: in response to receiving

> +is RECOMMENDED that endpoints immediately close the connection with a connection
+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,

I think this CL might benefit from a paragraph explaining that confidentiality limits and integrity limits are different, and that confidentiality limits are per-key whereas integrity is per-connection.

> +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

nit: should we say which error to use 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/3789#pullrequestreview-449286867

---

From: Martin Thomson <[email-masked]>
Date: Wed, 15 Jul 2020 16:26:02 -0700

@martinthomson commented on this pull request.

+not possible.
+

It might make sense to mint a new error code for this (and the above).  AEAD_LIMIT_REACHED might do.

-- 
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_r455421199

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 15 Jul 2020 21:34:59 -0700

@janaiyengar commented on this pull request.

+not possible.
+

One more error code!

-- 
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_r455504349