From 71684bc7e71580cffa434ca1c3255a6c980f3671 Mon Sep 17 00:00:00 2001 From: Christopher Wood Date: Wed, 24 Jun 2020 16:37:32 -0700 Subject: [PATCH 01/19] Expand AEAD limits to consider multi-user security. In a typical multi-user setting, the adversary is assumed to perform some (massive) amount of offline work to break the integrity of a single random connection. Each user is represented as a unique (key, nonce) pair. In considering the same threat model, we must treat each key resulting from a KeyUpdate event as a unique user. As a result, roughly speaking, bounds implied from the multi-user setting imply (minimally) for the lifetime of a single connection. Hoang et al. [1] present tight multi-user security bounds for randomized AES-GCM (as is used in TLS 1.3 and QUIC), so we can take advantage of those for per-connection integrity limits. (Confidentiality limits still apply per-key, as the analysis considers only encrypted blocks, which would not change if an endpoint updated its key or created a new connection.) In contrast, there are no multi-user security bounds for AEAD_CHACHA20_POLY1305 or AEAD_AES_128_CCM, so we must use the single-user bounds in their stead. [1] https://dl.acm.org/doi/10.1145/3243734.3243816 --- draft-ietf-quic-tls.md | 176 +++++++++++++++++++++++++++++------------ 1 file changed, 127 insertions(+), 49 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 2759399857..db26e4fb3f 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1536,14 +1536,11 @@ After this period, old read keys and their corresponding secrets SHOULD be discarded. -## Minimum Key Update Frequency +## Limits on AEAD Usage -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. The usage limits defined in TLS 1.3 exist for protection against attacks on confidentiality and apply to successful applications of AEAD protection. The @@ -1552,30 +1549,39 @@ 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}}. - -Note: - -: Due to the way that header protection protects the Key Phase, packets that are - discarded are likely to have an even distribution of both Key Phase values. - 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. +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}}. + +Endpoints MUST initiate a key update before the number of encrypted packets +reaches the confidentiality limit for the selected AEAD. For AEAD_AES_128_GCM +and AEAD_AES_256_GCM, the confidentiality limit is 2^27 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 encrypted packets; see +{{ccm-bounds}}. + +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 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}}. + +Future analyses and specifications MAY relax confidentiality or integrity limits +for an AEAD. Note: @@ -1588,7 +1594,7 @@ Note: 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 +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. Providing a reference to any analysis upon which values are based - and any assumptions used in that analysis - allows limits to be adapted @@ -2168,20 +2174,12 @@ The protected packet is the smallest possible packet size of 21 bytes. packet = 4cfe4189655e5cd55c41f69080575d7999c25a5bfb ~~~ -# Analysis of Limits on AEAD_AES_128_CCM Usage {#ccm-bounds} +# AEAD Algorithm Analysis -TLS {{?TLS13}} and {{AEBounds}} do not specify limits on usage for -AEAD_AES_128_CCM. However, any AEAD that is used with QUIC requires limits on -use that ensure that both confidentiality and integrity are preserved. This -section documents that analysis. - -{{?CCM-ANALYSIS=DOI.10.1007/3-540-36492-7_7}} is used as the basis of this -analysis. The results of that analysis are used to derive usage limits that are -based on those chosen in {{?TLS13}}. - -This analysis uses symbols for multiplication (*), division (/), and -exponentiation (^), plus parentheses for establishing precedence. The following -symbols are also used: +This section documents analyses used in deriving AEAD algorithm limits for +AEAD_AES_128_GCM, AEAD_AES_128_CCM, and AEAD_AES_256_GCM. The analyses that follow +use symbols for multiplication (*), division (/), and exponentiation (^), plus +parentheses for establishing precedence. The following symbols are also used: t: @@ -2207,10 +2205,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. 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 @@ -2220,6 +2222,82 @@ 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} + +{{?GCM-MU}} specify concrete bounds for AEAD_AES_128_GCM and AEAD_AES_256_GCM as +used in TLS 1.3 and QUIC. This section documents this analysis using several +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, Equation (1) in {{?GCM-MU}} establishes that an attacker gains +a distinguishing advantage between a real and random AEAD algorithm of no more than: + +~~~ +((q + v) * l)^2 / 2^128 +~~~ + +For a target advantage of 2^-60, which matches that used by {{!TLS13}}, this +results in the relation: + +~~~ +(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)) + + (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: + +~~~ +v <= 2^54 +~~~ + +For AEAD_AES_256_GCM, the second and fourth terms dominate the rest, so the +others can be removed without affecting the result. This produces the following +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. + +# 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 +on use that ensure that both confidentiality and integrity are preserved. This +section documents that analysis. + +{{?CCM-ANALYSIS=DOI.10.1007/3-540-36492-7_7}} is used as the basis of this +analysis. The results of that analysis are used to derive usage limits that are +based on those chosen in {{?TLS13}}. ## Confidentiality Limits From 89bbe1515f04766c0fa48dfd1b0fd4126fc3ecae Mon Sep 17 00:00:00 2001 From: Christopher Wood Date: Wed, 24 Jun 2020 16:45:18 -0700 Subject: [PATCH 02/19] Fix linter issues. --- draft-ietf-quic-tls.md | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index db26e4fb3f..dfbbdd2865 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -2177,9 +2177,10 @@ packet = 4cfe4189655e5cd55c41f69080575d7999c25a5bfb # AEAD Algorithm Analysis This section documents analyses used in deriving AEAD algorithm limits for -AEAD_AES_128_GCM, AEAD_AES_128_CCM, and AEAD_AES_256_GCM. The analyses that follow -use symbols for multiplication (*), division (/), and exponentiation (^), plus -parentheses for establishing precedence. The following symbols are also used: +AEAD_AES_128_GCM, AEAD_AES_128_CCM, and AEAD_AES_256_GCM. The analyses that +follow use symbols for multiplication (*), division (/), and exponentiation (^), +plus parentheses for establishing precedence. The following symbols are also +used: t: @@ -2209,10 +2210,10 @@ 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. +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. 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 @@ -2228,8 +2229,9 @@ overestimation of the number of operations. used in TLS 1.3 and QUIC. This section documents this analysis using several 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 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. @@ -2239,8 +2241,9 @@ 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, Equation (1) in {{?GCM-MU}} establishes that an attacker +gains a distinguishing advantage between a real and random AEAD algorithm of no +more than: ~~~ ((q + v) * l)^2 / 2^128 From 7d763fd6e71e4e1c38add4d78dbf3f7c28645f07 Mon Sep 17 00:00:00 2001 From: Christopher Wood Date: Mon, 29 Jun 2020 08:30:31 -0700 Subject: [PATCH 03/19] Update draft-ietf-quic-tls.md Co-authored-by: Jana Iyengar --- draft-ietf-quic-tls.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index dfbbdd2865..3b03091ba7 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -2266,7 +2266,7 @@ 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)) +(1 / 2^(8 * n)) + ((2 * v) / 2^(2 * n)) + ((2 * o * v) / 2^(k + n)) + (n * (v + (v * l)) / 2^k) ~~~ From 847f3c1666ca1ec23c92c72a9be998e74fb1ce68 Mon Sep 17 00:00:00 2001 From: Christopher Wood Date: Mon, 29 Jun 2020 08:30:39 -0700 Subject: [PATCH 04/19] Update draft-ietf-quic-tls.md Co-authored-by: Jana Iyengar --- draft-ietf-quic-tls.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 3b03091ba7..a1ea8ac060 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1540,7 +1540,7 @@ discarded. 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. +confidentiality and integrity of communications when using QUIC. The usage limits defined in TLS 1.3 exist for protection against attacks on confidentiality and apply to successful applications of AEAD protection. The From e50a65d844bf4c09891bf873d64c9211b28f43f5 Mon Sep 17 00:00:00 2001 From: Christopher Wood Date: Mon, 29 Jun 2020 08:32:31 -0700 Subject: [PATCH 05/19] Update draft-ietf-quic-tls.md Co-authored-by: Jana Iyengar --- draft-ietf-quic-tls.md | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index a1ea8ac060..a4d455f009 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1567,18 +1567,15 @@ AEAD_AES_128_CCM, the confidentiality limit is 2^23 encrypted packets; see 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 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}}. +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}}. Future analyses and specifications MAY relax confidentiality or integrity limits for an AEAD. From 69be76608b8f7a81d2e64e210121ddbbe1788c78 Mon Sep 17 00:00:00 2001 From: Christopher Wood Date: Mon, 29 Jun 2020 08:50:11 -0700 Subject: [PATCH 06/19] Clarify connection close cases for the confidentiality limit. Also, split out the integrity limit text again for parallel flow. --- draft-ietf-quic-tls.md | 38 +++++++++++++++++++++----------------- 1 file changed, 21 insertions(+), 17 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index a4d455f009..6dec7b0f42 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1550,27 +1550,31 @@ 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 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. -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}}. - -Endpoints MUST initiate a key update before the number of encrypted packets -reaches the confidentiality limit for the selected AEAD. For AEAD_AES_128_GCM -and AEAD_AES_256_GCM, the confidentiality limit is 2^27 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 encrypted packets; see -{{ccm-bounds}}. +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 +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 +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 -packets. For AEAD_AES_128_GCM, the integrity limit is 2^54 forged packets; see +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 @@ -2263,8 +2267,8 @@ 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)) - + (n * (v + (v * l)) / 2^k) +(1 / 2^(8 * n)) + ((2 * v) / 2^(2 * n)) + + ((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 From ed9bbfc7a712b67466842abef03932dbf369dc1e Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 6 Jul 2020 16:49:22 +1000 Subject: [PATCH 07/19] Update AEAD limits This corrects an arithmetic error in the calculation of the confidentiality limit for AES-GCM. It also changes to using a fixed advantage target of 2^-57 for both confidentiality and integrity. The inconsistent use of different limits was making it hard to reason about. As the overall target is AE security, the net effect of this is a factor of 2 improvement in attacker advantage over what is in the TLS analysis, which was 2^-57+2^-60. This moves to 2^-56 overall, which is cleaner. In doing so, I discovered that the integrity limits for both AES-GCM and AES-CCM were being set independent of the confidentiality limits, but that the confidentiality limits assumed limits on the number of forgeries. As a result, the limits on forgeries had to be capped based on those assumptions. --- draft-ietf-quic-tls.md | 59 +++++++++++++++++++++--------------------- 1 file changed, 30 insertions(+), 29 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 6dec7b0f42..570c2bce44 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1559,10 +1559,10 @@ 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 +For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the confidentiality limit is 2^24.5 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}}. @@ -1574,9 +1574,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 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^24.5 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}}. @@ -2250,16 +2250,15 @@ more than: ((q + v) * 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 + v) <= 2^25.5 ~~~ -Assuming `v = q`, endpoints cannot protect more than 2^27 packets in a single +Assuming `v = q`, endpoints cannot protect more than 2^24.5 packets in a single connection without causing an attacker to gain an larger advantage than the -target of 2^-60. +target of 2^-57. ### Integrity Limit @@ -2271,10 +2270,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 @@ -2288,9 +2286,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, as the confidentiality limit depends on an assumption of `v = q`, the +total number of forged packets cannot exceed 2^24.5 packets without degrading +the margins for confidentiality. Thus, this document recommends tolerating no +more than 2^24.5 possible forgery attempts. # Analysis of AEAD_AES_128_CCM Usage Limits {#ccm-bounds} @@ -2313,16 +2314,15 @@ 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 @@ -2334,19 +2334,20 @@ 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. +Noting that this is the same value as the confidentiality limit, the value can +be adjusted to allow `v` and `q` to be the same value. This leads to an upper +limit on both `v` and `q` of 2^23.5. That is, 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 From 2755bcaeeea1f9f6f39f689ceae09d6fadb89ad3 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 6 Jul 2020 17:04:23 +1000 Subject: [PATCH 08/19] Attempt to address some of the other questions --- draft-ietf-quic-tls.md | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 570c2bce44..969c36635f 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -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} @@ -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 @@ -1552,12 +1552,13 @@ packet that cannot be authenticated, allowing multiple forgery attempts. 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 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. +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 +not possible. For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the confidentiality limit is 2^24.5 encrypted packets; see {{gcm-bounds}}. For AEAD_CHACHA20_POLY1305, the From ed028b24ad451e18daa5c91412296f3c8be4f70c Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 6 Jul 2020 19:13:33 +1000 Subject: [PATCH 09/19] Fix error in adding v to confidentiality calculation --- draft-ietf-quic-tls.md | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 969c36635f..ef9ab5f753 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1560,7 +1560,7 @@ 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^24.5 +For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the confidentiality limit is 2^25.5 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 @@ -1575,7 +1575,7 @@ 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 and AEAD_AES_256_GCM, the integrity limit is 2^24.5 forged +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 @@ -2176,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 @@ -2225,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} {{?GCM-MU}} specify concrete bounds for AEAD_AES_128_GCM and AEAD_AES_256_GCM as @@ -2248,18 +2250,18 @@ gains a distinguishing advantage between a real and random AEAD algorithm of no more than: ~~~ -((q + v) * l)^2 / 2^128 +(q * l)^2 / 2^128 ~~~ For a target advantage of 2^-57, this results in the relation: ~~~ -(q + v) <= 2^25.5 +q <= 2^25.5 ~~~ -Assuming `v = q`, endpoints cannot protect more than 2^24.5 packets in a single -connection without causing an attacker to gain an larger advantage than the -target of 2^-57. +Thus, endpoints cannot protect more than 2^25.5 packets in a single connection +without causing an attacker to gain an larger advantage than the target of +2^-57. ### Integrity Limit @@ -2287,14 +2289,12 @@ approximation: v <= 2^182 ~~~ -This is substantially larger than the limit for AEAD_AES_128_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. -However, as the confidentiality limit depends on an assumption of `v = q`, the -total number of forged packets cannot exceed 2^24.5 packets without degrading -the margins for confidentiality. Thus, this document recommends tolerating no -more than 2^24.5 possible forgery attempts. -# 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 @@ -2343,10 +2343,10 @@ without a significant effect on the result. This produces the relation: v + q <= 2^24.5 ~~~ -Noting that this is the same value as the confidentiality limit, the value can -be adjusted to allow `v` and `q` to be the same value. This leads to an upper -limit on both `v` and `q` of 2^23.5. That is, endpoints cannot attempt to -protect or authenticate more than 2^23.5 packets with the same set of keys +Noting that this is the same value as the confidentiality limit, the +confidentiality limit can be adjusted to allow `v` and `q` to be the same value. +Thus the limit for both `v` and `q` is 2^23.5. That is, 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. From 5ef5f06828fe97cc38200b92cadf889c28b32833 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 6 Jul 2020 19:41:31 +1000 Subject: [PATCH 10/19] Fix heading levels --- draft-ietf-quic-tls.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index ef9ab5f753..77af9bf1ff 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -2305,7 +2305,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 @@ -2326,7 +2326,7 @@ keys without causing an attacker to gain an larger advantage than the target of 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: From 2e1f5297e5840ee849f213387404053dbe91a4ec Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 7 Jul 2020 14:13:23 +1000 Subject: [PATCH 11/19] Restore factor of 2 --- draft-ietf-quic-tls.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 77af9bf1ff..02835c359a 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1560,7 +1560,7 @@ 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.5 +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 @@ -2245,21 +2245,22 @@ 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 +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 * l)^2 / 2^128 +2 * (q * l)^2 / 2^128 ~~~ For a target advantage of 2^-57, this results in the relation: ~~~ -q <= 2^25.5 +q <= 2^25 ~~~ -Thus, endpoints cannot protect more than 2^25.5 packets in a single connection +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. From 6f58815715679ac0e05ceb8386f7667ca912de9b Mon Sep 17 00:00:00 2001 From: Christopher Wood Date: Thu, 9 Jul 2020 07:58:33 -0700 Subject: [PATCH 12/19] Update draft-ietf-quic-tls.md --- draft-ietf-quic-tls.md | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 02835c359a..5daecfdf90 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -2344,12 +2344,9 @@ without a significant effect on the result. This produces the relation: v + q <= 2^24.5 ~~~ -Noting that this is the same value as the confidentiality limit, the -confidentiality limit can be adjusted to allow `v` and `q` to be the same value. -Thus the limit for both `v` and `q` is 2^23.5. That is, 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. +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 From 8c094e9815d402f9c8f4aa4a5d4f8c19995ff14f Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 14 Jul 2020 17:23:40 +1000 Subject: [PATCH 13/19] Trim whitespace --- draft-ietf-quic-tls.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 88ced92d04..27a7406aca 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -2407,8 +2407,8 @@ without a significant effect on the result. This produces the relation: v + q <= 2^24.5 ~~~ -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 +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. From 8833f007c9fd77e438e5d99aee40a52e32412426 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 14 Jul 2020 17:34:32 +1000 Subject: [PATCH 14/19] Loooong line --- draft-ietf-quic-tls.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 27a7406aca..693216d80b 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -2408,8 +2408,8 @@ v + q <= 2^24.5 ~~~ 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. +2^23.5 packets with the same set of keys without causing an attacker to gain a +larger advantage in forging packets than the target of 2^-57. # Change Log From 950c6ae004446b2ba0dba4156d1002eaf13dee81 Mon Sep 17 00:00:00 2001 From: Christopher Wood Date: Thu, 13 Aug 2020 05:53:48 -0700 Subject: [PATCH 15/19] Add a new AEAD limits error code, and clearly differentiate between the usage limits. --- draft-ietf-quic-tls.md | 18 ++++++++++++------ draft-ietf-quic-transport.md | 5 +++++ 2 files changed, 17 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 693216d80b..9f71d3ed99 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1603,16 +1603,22 @@ 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. +QUIC accounts for AEAD confidentiality and integrity limits separately. The +confidentiality limit applies to the number of packets encrypted with a given +key. The integrity limit applies to the number of packets decrypted within a +given connection. Details on enforcing these limits for each AEAD algorithm +follow below. + 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 -not possible. +the connection and only send stateless resets in response to receiving packets. +It is RECOMMENDED that endpoints immediately close the connection with a +connection error of type AEAD_LIMIT_REACHED 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 @@ -1626,8 +1632,8 @@ 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 -packets. +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 diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index fb6b554d7a..c0e760992e 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -6167,6 +6167,11 @@ CRYPTO_BUFFER_EXCEEDED (0xD): : An endpoint has received more data in CRYPTO frames than it can buffer. +AEAD_LIMIT_REACHED (0xE): + +: An endpoint has reached the confidentiality or integrity limit for the AEAD + algorithm used by the given connection. + CRYPTO_ERROR (0x1XX): : The cryptographic handshake failed. A range of 256 values is reserved for From 6ada1ac4688ca050869c7f72c6f256ba27cccd8b Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 31 Aug 2020 10:19:47 +1000 Subject: [PATCH 16/19] Nits --- draft-ietf-quic-tls.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 9f71d3ed99..bacccdb350 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -2293,7 +2293,7 @@ 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} +## Analysis of AEAD_AES_128_GCM and AEAD_AES_256_GCM Usage Limits {#gcm-bounds} {{?GCM-MU}} specify concrete bounds for AEAD_AES_128_GCM and AEAD_AES_256_GCM as used in TLS 1.3 and QUIC. This section documents this analysis using several @@ -2312,7 +2312,7 @@ The bounds in {{?GCM-MU}} are tighter and more complete than those used in ### Confidentiality Limit -For confidentiality, Theorum (4.3) in {{?GCM-MU}} establish that - for a single +For confidentiality, Theorum (4.3) in {{?GCM-MU}} establishes that - for a single 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: From 1ab46496fb69c603d1e57f3c5f15f0e0a34d9155 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 31 Aug 2020 10:23:19 +1000 Subject: [PATCH 17/19] rap --- draft-ietf-quic-tls.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index bacccdb350..57b036e960 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -2312,8 +2312,8 @@ The bounds in {{?GCM-MU}} are tighter and more complete than those used in ### Confidentiality Limit -For confidentiality, Theorum (4.3) in {{?GCM-MU}} establishes that - for a single -user that does not repeat nonces - the dominant term in determining the +For confidentiality, Theorum (4.3) in {{?GCM-MU}} establishes that - for a +single 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: From 81b521dc3b9fe79ce7cba463bbf22af8dd0deb2a Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 2 Sep 2020 07:39:42 +1000 Subject: [PATCH 18/19] s/forged/invalid --- draft-ietf-quic-tls.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 57b036e960..8b1d22ce81 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1638,7 +1638,7 @@ 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 +is 2^23.5 invalid packets; see {{ccm-bounds}}. Applying this limit reduces the probability that an attacker can successfully forge a packet; see {{AEBounds}}, {{ROBUST}}, and {{?GCM-MU}}. From 2a6810d9f614262c08dcc9b08f3550631cbc394e Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 2 Sep 2020 07:41:28 +1000 Subject: [PATCH 19/19] More invalid rather than forged more sleep needed --- draft-ietf-quic-tls.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 8b1d22ce81..0e4a56beff 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1635,12 +1635,12 @@ 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 +For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the integrity limit is 2^54 invalid 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 invalid packets; see {{ccm-bounds}}. Applying this limit reduces the -probability that an attacker can successfully forge a packet; see {{AEBounds}}, -{{ROBUST}}, and {{?GCM-MU}}. +2^36 invalid packets; see {{AEBounds}}. For AEAD_AES_128_CCM, the integrity +limit is 2^23.5 invalid packets; see {{ccm-bounds}}. Applying this limit reduces +the probability that an attacker can successfully forge a packet; see +{{AEBounds}}, {{ROBUST}}, and {{?GCM-MU}}. Future analyses and specifications MAY relax confidentiality or integrity limits for an AEAD.