Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Expand AEAD limits to consider multi-user security. #3789

Merged
merged 21 commits into from Sep 1, 2020
Merged

Expand AEAD limits to consider multi-user security. #3789

Changes from 7 commits
Commits
Show all changes
21 commits
Select commit Hold shift + click to select a range
71684bc
Expand AEAD limits to consider multi-user security.
Jun 24, 2020
89bbe15
Fix linter issues.
Jun 24, 2020
7d763fd
Update draft-ietf-quic-tls.md
chris-wood Jun 29, 2020
847f3c1
Update draft-ietf-quic-tls.md
chris-wood Jun 29, 2020
e50a65d
Update draft-ietf-quic-tls.md
chris-wood Jun 29, 2020
69be766
Clarify connection close cases for the confidentiality limit.
Jun 29, 2020
ed9bbfc
Update AEAD limits
martinthomson Jul 6, 2020
2755bca
Attempt to address some of the other questions
martinthomson Jul 6, 2020
ed028b2
Fix error in adding v to confidentiality calculation
martinthomson Jul 6, 2020
5ef5f06
Fix heading levels
martinthomson Jul 6, 2020
2e1f529
Restore factor of 2
martinthomson Jul 7, 2020
6f58815
Update draft-ietf-quic-tls.md
chris-wood Jul 9, 2020
9dd23dc
Merge pull request #2 from quicwg/aead-limits2
chris-wood Jul 9, 2020
4e9c4a5
Merge branch 'master' into caw/mu-limits
martinthomson Jul 14, 2020
8c094e9
Trim whitespace
martinthomson Jul 14, 2020
8833f00
Loooong line
martinthomson Jul 14, 2020
950c6ae
Add a new AEAD limits error code, and clearly differentiate between t…
Aug 13, 2020
6ada1ac
Nits
martinthomson Aug 31, 2020
1ab4649
rap
martinthomson Aug 31, 2020
81b521d
s/forged/invalid
martinthomson Sep 1, 2020
2a6810d
More invalid rather than forged
martinthomson Sep 1, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
96 changes: 48 additions & 48 deletions draft-ietf-quic-tls.md
View file
Open in desktop
Expand Up @@ -972,9 +972,9 @@ described in {{QUIC-TRANSPORT}}.
The output ciphertext, C, of the AEAD is transmitted in place of P.

Some AEAD functions have limits for how many packets can be encrypted under the
same key and IV (see for example {{AEBounds}}). This might be lower than the
packet number limit. An endpoint MUST initiate a key update ({{key-update}})
prior to exceeding any limit set for the AEAD that is in use.
same key and IV; see {{aead-limits}}. This might be lower than the packet
number limit. An endpoint MUST initiate a key update ({{key-update}}) prior to
exceeding any limit set for the AEAD that is in use.


## Header Protection {#header-protect}
Expand Down Expand Up @@ -1536,7 +1536,7 @@ After this period, old read keys and their corresponding secrets SHOULD be
discarded.


## Limits on AEAD Usage
## Limits on AEAD Usage {#aead-limits}

This document sets usage limits for AEAD algorithms to ensure that overuse does
not give an adversary a disproportionate advantage in attacking the
Expand All @@ -1552,17 +1552,18 @@ packet that cannot be authenticated, allowing multiple forgery attempts.
Endpoints MUST count the number of encrypted packets for each set of keys. If
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this clarify who is doing the updating? If I've sent 2^27 or received 2^27 do I initiate?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an existing ambiguity. And the answer is that either endpoint can do the update. As updates are symmetric, this isn't a big deal, but you can stumble over each other if you do it poorly.

I haven't implemented this bit yet, but when I did it for TLS, the sender updates at limit-N and the receiver requests an update at limit-M where M < N. This is because the primary responsibility for the update lies with the sender. This stops endpoints using the same implementation from doing near-simultaneous updates, which is a little wasteful. If M for one implementation matches N for another, then you can still get a race. Of course, QUIC handles simultaneous updates well, so maybe you don't care for that level of sophistication.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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 the number of encrypted
packets reaches the confidentiality limit for the selected AEAD. If a key update
is not possible, the endpoint MUST stop using the connection for anything other
than stateless resets. 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 not possible.

For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the confidentiality limit is 2^27
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
chris-wood marked this conversation as resolved.
Show resolved Hide resolved
is RECOMMENDED that endpoints immediately close the connection with a connection
error of type PROTOCOL_VIOLATION before reaching a state where key updates are
chris-wood marked this conversation as resolved.
Show resolved Hide resolved
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
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}}.
Expand All @@ -1574,9 +1575,9 @@ connection, across all keys, exceeds the integrity limit for the selected AEAD,
the endpoint MUST immediately close the connection and not process any more
chris-wood marked this conversation as resolved.
Show resolved Hide resolved
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
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}}.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Expand Down Expand Up @@ -2175,6 +2176,7 @@ The protected packet is the smallest possible packet size of 21 bytes.
packet = 4cfe4189655e5cd55c41f69080575d7999c25a5bfb
~~~


# AEAD Algorithm Analysis

This section documents analyses used in deriving AEAD algorithm limits for
Expand Down Expand Up @@ -2224,6 +2226,7 @@ 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.


## Analysis AEAD_AES_128_GCM and AEAD_AES_256_GCM Usage Limits {#gcm-bounds}
chris-wood marked this conversation as resolved.
Show resolved Hide resolved

{{?GCM-MU}} specify concrete bounds for AEAD_AES_128_GCM and AEAD_AES_256_GCM as
Expand All @@ -2242,24 +2245,24 @@ The bounds in {{?GCM-MU}} are tighter and more complete than those used in

### Confidentiality Limit

For confidentiality, Equation (1) in {{?GCM-MU}} establishes that an attacker
gains a distinguishing advantage between a real and random AEAD algorithm of no
more than:
For confidentiality, Theorum (4.3) in {{?GCM-MU}} establish that - for a single
chris-wood marked this conversation as resolved.
Show resolved Hide resolved
user that does not repeat nonces - the dominant term in determining the
distinguishing advantage between a real and random AEAD algorithm gained by an
attacker is:

~~~
((q + v) * l)^2 / 2^128
2 * (q * l)^2 / 2^128
~~~

For a target advantage of 2^-60, which matches that used by {{!TLS13}}, this
results in the relation:
For a target advantage of 2^-57, this results in the relation:

~~~
(q + v) <= 2^28
q <= 2^25
~~~

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.
Thus, endpoints cannot protect more than 2^25 packets in a single connection
without causing an attacker to gain an larger advantage than the target of
2^-57.

### Integrity Limit

Expand All @@ -2271,10 +2274,9 @@ an advantage in successfully forging a packet of no more than:
+ ((2 * o * v) / 2^(k + n)) + (n * (v + (v * l)) / 2^k)
~~~

The goal is to limit this advantage to 2^-57, to match the target in
{{?TLS13}}. For AEAD_AES_128_GCM, the fourth term in this inequality dominates
the rest, so the others can be removed without affecting the result. This
produces the following approximation:
The goal is to limit this advantage to 2^-57. For AEAD_AES_128_GCM, the fourth
term in this inequality dominates the rest, so the others can be removed without
significant effect on the result. This produces the following approximation:

~~~
v <= 2^54
Expand All @@ -2288,11 +2290,12 @@ approximation:
v <= 2^182
~~~

This is substantially larger than the limit for AEAD_AES_128_GCM. However,
this document recommends that the smaller limit from AEAD_AES_128_GCM also
apply to AEAD_AES_256_GCM.
This is substantially larger than the limit for AEAD_AES_128_GCM. However, this
document recommends that the same limit be applied to both functions as either
limit is acceptably large.


# Analysis of AEAD_AES_128_CCM Usage Limits {#ccm-bounds}
## Analysis of AEAD_AES_128_CCM Usage Limits {#ccm-bounds}

TLS {{?TLS13}} and {{AEBounds}} do not specify per-connection limits on usage
for AEAD_AES_128_CCM. However, any AEAD that is used with QUIC requires limits
Expand All @@ -2303,7 +2306,7 @@ section documents that analysis.
analysis. The results of that analysis are used to derive usage limits that are
based on those chosen in {{?TLS13}}.

## Confidentiality Limits
### Confidentiality Limits

For confidentiality, Theorem 2 in {{?CCM-ANALYSIS}} establishes that an attacker
gains a distinguishing advantage over an ideal pseudorandom permutation (PRP) of
Expand All @@ -2313,19 +2316,18 @@ no more than:
(2l * q)^2 / 2^n
~~~

For a target advantage of 2^-60, which matches that used by {{!TLS13}}, this
results in the relation:
For a target advantage of 2^-57, this results in the relation:

~~~
q <= 2^23
q <= 2^24.5
~~~

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.
2^-57. Note however that the integrity limits further constrain this value.


## Integrity Limits
### Integrity Limits

For integrity, Theorem 1 in {{?CCM-ANALYSIS}} establishes that an attacker
gains an advantage over an ideal PRP of no more than:
Expand All @@ -2334,19 +2336,17 @@ gains an advantage over an ideal PRP of no more than:
v / 2^t + (2l * (v + q))^2 / 2^n
~~~

The goal is to limit this advantage to 2^-57, to match the target in
{{?TLS13}}. As `t` and `n` are both 128, the first term is negligible relative
to the second, so that term can be removed without a significant effect on the
result. This produces the relation:
The goal is to limit this advantage to 2^-57. As `t` and `n` are both 128, the
first term is negligible relative to the second, so that term can be removed
without a significant effect on the result. This produces the relation:

~~~
v + q <= 2^24.5
~~~

Using the previously-established value of 2^23 for `q` and rounding, this leads
to an upper limit on `v` of 2^23.5. That is, endpoints cannot attempt to
authenticate more than 2^23.5 packets with the same set of keys without causing
an attacker to gain an larger advantage than the target of 2^-57.
Assuming `q = v`, endpoints cannot attempt to protect or authenticate more than
2^23.5 packets with the same set of keys without causing an attacker to gain an larger
advantage than the target of 2^-57 in forging packets.


# Change Log
Expand Down