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

[Jana Iyengar <[e-mail]>]

@janaiyengar commented on this pull request.

Thank you for the PR, @chris-wood ! A few comments.

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

I don't understand how this impacts the analysis, but why is packet size 2^14 bytes? For QUIC, I would suggest that 2^11 ought to be adequate (if a larger packet size is more conservative).

> +
+~~~
+(q + v) <= 2^28
+~~~
+
+Assuming `v = q`, endpoints cannot protect more than 2^27 packets in a single
+connection without causing an attacker to gain an larger advantage than the
+target of 2^-60.
+
+### Integrity Limit
+
+For integrity, Theorem (4.3) in {{?GCM-MU}} establishes that an attacker gains
+an advantage in successfully forging a packet of no more than:
+
+~~~
+(1 / 2^(8 * n)) + ((2 * v) / 2^2*n) + ((2 * o * v) / 2^(k + n))

```suggestion
(1 / 2^(8 * n)) + ((2 * v) / 2^(2 * n)) + ((2 * o * v) / 2^(k + n))
```
?

>  
-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. {{!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.
+This document sets usage limits for AEAD algorithms to ensure that overuse does
+not give an adversary a disproportionate advantage in attacking the
+confidentiality and integrity of communications.

```suggestion
confidentiality and integrity of communications when using QUIC.
```

> +If the number of packets sent or fail authentication within the connection
+(across all keys) exceeds a limit that is specific to the AEAD in use, the
+endpoint MUST immediately close the connection and not attempt to process any
+further packets.  Applying a limit reduces the probability that an attacker can
+successfully forge a packet; see {{AEBounds}}, {{ROBUST}}, and {{?GCM-MU}}.
+
+A connection MUST be closed if the number of packets that fail authentication
+exceed the integrity limit for the selected AEAD. For AEAD_AES_128_GCM, and the
+integrity limit is 2^54 encrypted or forged packets; see {{gcm-bounds}}.  For
+AEAD_CHACHA20_POLY1305, the limit on number of packets that fail authentication
+is 2^36; see {{AEBounds}}.  For AEAD_AES_128_CCM, the integrity limit is 2^23.5
+forged packets; see {{ccm-bounds}}.

There seems to be some redundancy and some inconsistencies in the text heree, I've tried to clean it up a bit. See if the following is accurate.
```suggestion
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
packets. For AEAD_AES_128_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}}.
```

> -  This means that packets that fail authentication will often use the packet
-  protection keys from the next key phase.  It is therefore necessary to also
-  track the number of packets that fail authentication with the next set of
-  packet protection keys.  To avoid exhaustion of both sets of keys, it might be
-  necessary to initiate two key updates in succession.
-
-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}}.
+Endpoints MUST count the number of encrypted packets for each set of keys. If
+the number of encrypted packets with the same key exceeds a limit that is
+specific to the AEAD in use, the endpoint MUST stop using those keys. If a key
+update is not possible, the endpoint MUST immediately close the connection.

Should an error code specified here? How is the endpoint closing the connection?

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