idnits 2.17.1 draft-irtf-cfrg-aead-limits-03.txt: -(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (12 July 2021) is 1016 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Günther 3 Internet-Draft ETH Zurich 4 Intended status: Informational M. Thomson 5 Expires: 13 January 2022 Mozilla 6 C.A. Wood 7 Cloudflare 8 12 July 2021 10 Usage Limits on AEAD Algorithms 11 draft-irtf-cfrg-aead-limits-03 13 Abstract 15 An Authenticated Encryption with Associated Data (AEAD) algorithm 16 provides confidentiality and integrity. Excessive use of the same 17 key can give an attacker advantages in breaking these properties. 18 This document provides simple guidance for users of common AEAD 19 functions about how to limit the use of keys in order to bound the 20 advantage given to an attacker. It considers limits in both single- 21 and multi-key settings. 23 Discussion Venues 25 This note is to be removed before publishing as an RFC. 27 Source for this draft and an issue tracker can be found at 28 https://github.com/cfrg/draft-irtf-cfrg-aead-limits. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 13 January 2022. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 65 3. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Calculating Limits . . . . . . . . . . . . . . . . . . . . . 6 67 5. Single-Key AEAD Limits . . . . . . . . . . . . . . . . . . . 8 68 5.1. AEAD_AES_128_GCM and AEAD_AES_256_GCM . . . . . . . . . . 8 69 5.1.1. Confidentiality Limit . . . . . . . . . . . . . . . . 8 70 5.1.2. Integrity Limit . . . . . . . . . . . . . . . . . . . 8 71 5.2. AEAD_CHACHA20_POLY1305 . . . . . . . . . . . . . . . . . 8 72 5.3. AEAD_AES_128_CCM . . . . . . . . . . . . . . . . . . . . 9 73 5.3.1. Confidentiality Limit . . . . . . . . . . . . . . . . 9 74 5.3.2. Integrity Limit . . . . . . . . . . . . . . . . . . . 9 75 5.4. AEAD_AES_128_CCM_8 . . . . . . . . . . . . . . . . . . . 10 76 5.5. Single-Key Examples . . . . . . . . . . . . . . . . . . . 10 77 6. Multi-Key AEAD Limits . . . . . . . . . . . . . . . . . . . . 11 78 6.1. AEAD_AES_128_GCM and AEAD_AES_256_GCM . . . . . . . . . . 11 79 6.1.1. Authenticated Encryption Security Limit . . . . . . . 11 80 6.1.2. Confidentiality Limit . . . . . . . . . . . . . . . . 12 81 6.1.3. Integrity Limit . . . . . . . . . . . . . . . . . . . 12 82 6.2. AEAD_CHACHA20_POLY1305, AEAD_AES_128_CCM, and 83 AEAD_AES_128_CCM_8 . . . . . . . . . . . . . . . . . . . 12 84 6.2.1. AEAD_CHACHA20_POLY1305 . . . . . . . . . . . . . . . 13 85 6.2.2. AEAD_AES_128_CCM and AEAD_AES_128_CCM_8 . . . . . . . 13 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 90 9.2. Informative References . . . . . . . . . . . . . . . . . 15 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 An Authenticated Encryption with Associated Data (AEAD) algorithm 96 provides confidentiality and integrity. [RFC5116] specifies an AEAD 97 as a function with four inputs -- secret key, nonce, plaintext, 98 associated data (of which plaintext and associated data can 99 optionally be zero-length) -- that produces ciphertext output and an 100 error code indicating success or failure. The ciphertext is 101 typically composed of the encrypted plaintext bytes and an 102 authentication tag. 104 The generic AEAD interface does not describe usage limits. Each AEAD 105 algorithm does describe limits on its inputs, but these are 106 formulated as strict functional limits, such as the maximum length of 107 inputs, which are determined by the properties of the underlying AEAD 108 composition. Degradation of the security of the AEAD as a single key 109 is used multiple times is not given a thorough treatment. 111 These limits might also be influenced by the number of "users" of a 112 given key. In the traditional setting, there is one key shared 113 between two parties. Any limits on the maximum length of inputs or 114 encryption operations apply to that single key. The attacker's goal 115 is to break security (confidentiality or integrity) of that specific 116 key. However, in practice, there are often many users with 117 independent keys. This multi-key security setting, often referred to 118 as the multi-user setting in the academic literature, hence considers 119 an attacker's advantage in breaking security of any of these many 120 keys, further assuming the attacker may have done some offline work 121 to help break security. As a result, AEAD algorithm limits may 122 depend on offline work and the number of keys. However, given that a 123 multi-key attacker does not target any specific key, acceptable 124 advantages may differ from that of the single-key setting. 126 The number of times a single pair of key and nonce can be used might 127 also be relevant to security. For some algorithms, such as 128 AEAD_AES_128_GCM or AEAD_AES_256_GCM, this limit is 1 and using the 129 same pair of key and nonce has serious consequences for both 130 confidentiality and integrity; see [NonceDisrespecting]. Nonce-reuse 131 resistant algorithms like AEAD_AES_128_GCM_SIV can tolerate a limited 132 amount of nonce reuse. 134 It is good practice to have limits on how many times the same key (or 135 pair of key and nonce) are used. Setting a limit based on some 136 measurable property of the usage, such as number of protected 137 messages or amount of data transferred, ensures that it is easy to 138 apply limits. This might require the application of simplifying 139 assumptions. For example, TLS 1.3 specifies limits on the number of 140 records that can be protected, using the simplifying assumption that 141 records are the same size; see Section 5.5 of [TLS]. 143 Currently, AEAD limits and usage requirements are scattered among 144 peer-reviewed papers, standards documents, and other RFCs. 145 Determining the correct limits for a given setting is challenging as 146 papers do not use consistent labels or conventions, and rarely apply 147 any simplifications that might aid in reaching a simple limit. 149 The intent of this document is to collate all relevant information 150 about the proper usage and limits of AEAD algorithms in one place. 151 This may serve as a standard reference when considering which AEAD 152 algorithm to use, and how to use it. 154 2. Requirements Notation 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 158 "OPTIONAL" in this document are to be interpreted as described in 159 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 160 capitals, as shown here. 162 3. Notation 164 This document defines limitations in part using the quantities below. 166 +========+====================================================+ 167 | Symbol | Description | 168 +========+====================================================+ 169 | n | AEAD block length (in bits) | 170 +--------+----------------------------------------------------+ 171 | k | AEAD key length (in bits) | 172 +--------+----------------------------------------------------+ 173 | r | AEAD nonce length (in bits) | 174 +--------+----------------------------------------------------+ 175 | t | Size of the authentication tag (in bits) | 176 +--------+----------------------------------------------------+ 177 | l | Maximum length of each message (in blocks) | 178 +--------+----------------------------------------------------+ 179 | s | Total plaintext length in all messages (in blocks) | 180 +--------+----------------------------------------------------+ 181 | q | Number of protected messages (AEAD encryption | 182 | | invocations) | 183 +--------+----------------------------------------------------+ 184 | v | Number of attacker forgery attempts (failed AEAD | 185 | | decryption invocations) | 186 +--------+----------------------------------------------------+ 187 | p | Upper bound on adversary attack probability | 188 +--------+----------------------------------------------------+ 189 | o | Offline adversary work (in number of encryption | 190 | | and decryption queries; multi-key setting only) | 191 +--------+----------------------------------------------------+ 192 | u | Number of keys (multi-key setting only) | 193 +--------+----------------------------------------------------+ 194 | B | Maximum number of blocks encrypted by any key | 195 | | (multi-key setting only) | 196 +--------+----------------------------------------------------+ 198 Table 1 200 For each AEAD algorithm, we define the (passive) confidentiality and 201 (active) integrity advantage roughly as the advantage an attacker has 202 in breaking the corresponding classical security property for the 203 algorithm. A passive attacker can query ciphertexts for arbitrary 204 plaintexts. An active attacker can additionally query plaintexts for 205 arbitrary ciphertexts. Moreover, we define the combined 206 authenticated encryption advantage guaranteeing both confidentiality 207 and integrity against an active attacker. Specifically: 209 * Confidentiality advantage (CA): The probability of a passive 210 attacker succeeding in breaking the confidentiality properties 211 (IND-CPA) of the AEAD scheme. In this document, the definition of 212 confidentiality advantage roughly is the probability that an 213 attacker successfully distinguishes the ciphertext outputs of the 214 AEAD scheme from the outputs of a random function. 216 * Integrity advantage (IA): The probability of a active attacker 217 succeeding in breaking the integrity properties (INT-CTXT) of the 218 AEAD scheme. In this document, the definition of integrity 219 advantage roughly is the probability that an attacker is able to 220 forge a ciphertext that will be accepted as valid. 222 * Authenticated Encryption advantage (AEA): The probability of a 223 active attacker succeeding in breaking the authenticated- 224 encryption properties of the AEAD scheme. In this document, the 225 definition of authenticated encryption advantage roughly is the 226 probability that an attacker successfully distinguishes the 227 ciphertext outputs of the AEAD scheme from the outputs of a random 228 function or is able to forge a ciphertext that will be accepted as 229 valid. 231 See [AEComposition], [AEAD] for the formal definitions of and 232 relations between passive confidentiality (IND-CPA), ciphertext 233 integrity (INT-CTXT), and authenticated encryption security (AE). 234 The authenticated encryption advantage subsumes, and can be derived 235 as the combination of, both CA and IA: 237 CA <= AEA 238 IA <= AEA 239 AEA <= CA + IA 241 Each application requires an individual determination of limits in 242 order to keep CA and IA sufficiently small. For instance, TLS aims 243 to keep CA below 2^-60 and IA below 2^-57 in the single-key setting; 244 see Section 5.5 of [TLS]. 246 4. Calculating Limits 248 Once upper bounds on CA, IA, or AEA are determined, this document 249 defines a process for determining three overall operational limits: 251 * Confidentiality limit (CL): The number of messages an application 252 can encrypt before giving the adversary a confidentiality 253 advantage higher than CA. 255 * Integrity limit (IL): The number ciphertexts an application can 256 decrypt, either successfully or not, before giving the adversary 257 an integrity advantage higher than IA. 259 * Authenticated encryption limit (AEL): The combined number of 260 messages and number of ciphertexts an application can encrypt or 261 decrypt before giving the adversary an authenticated encryption 262 advantage higher than AEA. 264 When limits are expressed as a number of messages an application can 265 encrypt or decrypt, this requires assumptions about the size of 266 messages and any authenticated additional data (AAD). Limits can 267 instead be expressed in terms of the number of bytes, or blocks, of 268 plaintext and maybe AAD in total. 270 To aid in translating between message-based and byte/block-based 271 limits, a formulation of limits that includes a maximum message size 272 (l) and the AEAD schemes' block length in bits (n) is provided. 274 All limits are based on the total number of messages, either the 275 number of protected messages (q) or the number of forgery attempts 276 (v); which correspond to CL and IL respectively. 278 Limits are then derived from those bounds using a target attacker 279 probability. For example, given an integrity advantage of "IA = v * 280 (8l / 2^106)" and a targeted maximum attacker success probability of 281 "IA = p", the algorithm remains secure, i.e., the adversary's 282 advantage does not exceed the targeted probability of success, 283 provided that "v <= (p * 2^106) / 8l". In turn, this implies that "v 284 <= (p * 2^103) / l" is the corresponding limit. 286 To apply these limits, implementations can count the number of 287 messages that are protected or rejected against the determined limits 288 (q and v respectively). This requires that messages cannot exceed 289 the maximum message size (l) that is chosen. 291 This analysis assumes a message-based approach to setting limits. 292 Implementations that use byte counting rather than message counting 293 could use a maximum message size (l) of one to determine a limit for 294 q that can be applied with byte counting. This results in 295 attributing per-message overheads to every byte, so the resulting 296 limit could be significantly lower than necessary. Actions, like 297 rekeying, that are taken to avoid the limit might occur more often as 298 a result. 300 5. Single-Key AEAD Limits 302 This section summarizes the confidentiality and integrity bounds and 303 limits for modern AEAD algorithms used in IETF protocols, including: 304 AEAD_AES_128_GCM [RFC5116], AEAD_AES_256_GCM [RFC5116], 305 AEAD_AES_128_CCM [RFC5116], AEAD_CHACHA20_POLY1305 [RFC8439], 306 AEAD_AES_128_CCM_8 [RFC6655]. 308 The CL and IL values bound the total number of encryption and forgery 309 queries (q and v). Alongside each value, we also specify these 310 bounds. 312 5.1. AEAD_AES_128_GCM and AEAD_AES_256_GCM 314 The CL and IL values for AES-GCM are derived in [AEBounds] and 315 summarized below. For this AEAD, n = 128 and t = 128 [GCM]. In this 316 example, the length s is the sum of AAD and plaintext, as described 317 in [GCMProofs]. 319 5.1.1. Confidentiality Limit 321 CA <= ((s + q + 1)^2) / 2^129 323 This implies the following usage limit: 325 q + s <= p^(1/2) * 2^(129/2) - 1 327 Which, for a message-based protocol with "s <= q * l", if we assume 328 that every packet is size "l", produces the limit: 330 q <= (p^(1/2) * 2^(129/2) - 1) / (l + 1) 332 5.1.2. Integrity Limit 334 IA <= 2 * (v * (l + 1)) / 2^128 336 This implies the following limit: 338 v <= (p * 2^127) / (l + 1) 340 5.2. AEAD_CHACHA20_POLY1305 342 The only known analysis for AEAD_CHACHA20_POLY1305 343 [ChaCha20Poly1305Bounds] combines the confidentiality and integrity 344 limits into a single expression, covered below: 346 CA <= v * ((8 * l) / 2^106) 347 IA <= v * ((8 * l) / 2^106) 348 This advantage is a tight reduction based on the underlying Poly1305 349 PRF [Poly1305]. It implies the following limit: 351 v <= (p * 2^103) / l 353 5.3. AEAD_AES_128_CCM 355 The CL and IL values for AEAD_AES_128_CCM are derived from 356 [CCM-ANALYSIS] and specified in the QUIC-TLS mapping specification 357 [I-D.ietf-quic-tls]. This analysis uses the total number of 358 underlying block cipher operations to derive its bound. For CCM, 359 this number is the sum of: the length of the associated data in 360 blocks, the length of the ciphertext in blocks, the length of the 361 plaintext in blocks, plus 1. 363 In the following limits, this is simplified to a value of twice the 364 length of the packet in blocks, i.e., 2l represents the effective 365 length, in number of block cipher operations, of a message with l 366 blocks. This simplification is based on the observation that common 367 applications of this AEAD carry only a small amount of associated 368 data compared to ciphertext. For example, QUIC has 1 to 3 blocks of 369 AAD. 371 For this AEAD, n = 128 and t = 128. 373 5.3.1. Confidentiality Limit 375 CA <= (2l * q)^2 / 2^n 376 <= (2l * q)^2 / 2^128 378 This implies the following limit: 380 q <= sqrt((p * 2^126) / l^2) 382 5.3.2. Integrity Limit 384 IA <= v / 2^t + (2l * (v + q))^2 / 2^n 385 <= v / 2^128 + (2l * (v + q))^2 / 2^128 387 This implies the following limit: 389 v + (2l * (v + q))^2 <= p * 2^128 391 In a setting where "v" or "q" is sufficiently large, "v" is 392 negligible compared to "(2l * (v + q))^2", so this this can be 393 simplified to: 395 v + q <= p^(1/2) * 2^63 / l 397 5.4. AEAD_AES_128_CCM_8 399 The analysis in [CCM-ANALYSIS] also applies to this AEAD, but the 400 reduced tag length of 64 bits changes the integrity limit calculation 401 considerably. 403 IA <= v / 2^t + (2l * (v + q))^2 / 2^n 404 <= v / 2^64 + (2l * (v + q))^2 / 2^128 406 This results in reducing the limit on "v" by a factor of 2^64. 408 v * 2^64 + (2l * (v + q))^2 <= p * 2^128 410 5.5. Single-Key Examples 412 An example protocol might choose to aim for a single-key CA and IA 413 that is at most 2^-50. If the messages exchanged in the protocol are 414 at most a common Internet MTU of around 1500 bytes, then a value for 415 l might be set to 2^7. The values in Table 2 show values of q and v 416 that might be chosen under these conditions. 418 +========================+===========+===========+ 419 | AEAD | Maximum q | Maximum v | 420 +========================+===========+===========+ 421 | AEAD_AES_128_GCM | 2^32.5 | 2^71 | 422 +------------------------+-----------+-----------+ 423 | AEAD_AES_256_GCM | 2^32.5 | 2^71 | 424 +------------------------+-----------+-----------+ 425 | AEAD_CHACHA20_POLY1305 | n/a | 2^46 | 426 +------------------------+-----------+-----------+ 427 | AEAD_AES_128_CCM | 2^30 | 2^30 | 428 +------------------------+-----------+-----------+ 429 | AEAD_AES_128_CCM_8 | 2^30.9 | 2^13 | 430 +------------------------+-----------+-----------+ 432 Table 2: Example limits 434 AEAD_CHACHA20_POLY1305 provides no limit to q based on the provided 435 analysis. 437 The limit for q on AEAD_AES_128_CCM and AEAD_AES_128_CCM_8 is reduced 438 due to a need to reduce the value of q to ensure that IA does not 439 exceed the target. This assumes equal proportions for q and v for 440 AEAD_AES_128_CCM. AEAD_AES_128_CCM_8 in permits a much smaller value 441 of v due to the shorter tag, which permits a higher limit for q. 443 Some protocols naturally limit v to 1, such as TCP-based variants of 444 TLS, which terminate sessions on decryption failure. If v is limited 445 to 1, q can be increased to 2^31 for both CCM AEADs. 447 6. Multi-Key AEAD Limits 449 In the multi-key setting, each user is assumed to have an independent 450 and identically distributed key, though nonces may be re-used across 451 users with some very small probability. The success probability in 452 attacking one of these many independent keys can be generically 453 bounded by the success probability of attacking a single key 454 multiplied by the number of keys present [MUSecurity], [GCM-MU]. 455 Absent concrete multi-key bounds, this means the attacker advantage 456 in the multi-key setting is the product of the single-key advantage 457 and the number of keys. 459 This section summarizes the confidentiality and integrity bounds and 460 limits for the same algorithms as in Section 5 for the multi-key 461 setting. The CL and IL values bound the total number of encryption 462 and forgery queries (q and v). Alongside each value, we also specify 463 these bounds. 465 6.1. AEAD_AES_128_GCM and AEAD_AES_256_GCM 467 Concrete multi-key bounds for AEAD_AES_128_GCM and AEAD_AES_256_GCM 468 exist due to Theorem 4.3 in [GCM-MU2], which covers protocols with 469 nonce randomization, like TLS 1.3 [TLS] and QUIC [RFC9001]. 471 Results for AES-GCM without nonce randomization are captured by 472 Theorem 3.1 in [GCM-MU2], which apply to protocols such as TLS 1.2 473 [RFC5246]. This produces similar limits under most conditions. 475 For this AEAD, n = 128, t = 128, and r = 96; the key length is k = 476 128 or k = 256 for AEAD_AES_128_GCM and AEAD_AES_128_GCM 477 respectively. 479 6.1.1. Authenticated Encryption Security Limit 481 Protocols with nonce randomization have a limit of: 483 AEA <= ((q+v)*l*B / 2^127) + (1 / 2^48) 485 This implies the following limit: 487 q + v <= (p * 2^127 - 2^79) / (l * B) 488 This assumes that B is much larger than 100; that is, each user 489 enciphers significantly more than 1600 bytes of data. Otherwise, B 490 should be increased by 161 for AEAD_AES_128_GCM and by 97 for 491 AEAD_AES_256_GCM. 493 Protocols without nonce randomization have limits that are 494 essentially the same provided that p is not less than 2^-48, as the 495 simplified expression for AEA does not include the 2^-48 term: 497 q + v <= p * 2^127 / (l * B) 499 Without nonce randomization, B should be increased by an additional 500 0.5. 502 6.1.2. Confidentiality Limit 504 The confidentiality advantage is essentially dominated by the same 505 terms as the AE advantage for protocols with nonce randomization: 507 CA <= (q*l*B / 2^127) + (1 / 2^48) 509 This implies the following limit: 511 q <= (p * 2^127 - 2^79) / (l * B) 513 As before, the limit without nonce randomization is: 515 q <= (p * 2^127) / (l * B) 517 6.1.3. Integrity Limit 519 There is currently no dedicated integrity multi-key bound available 520 for AEAD_AES_128_GCM and AEAD_AES_256_GCM. The AE limit can be used 521 to derive an integrity limit as: 523 IA <= AEA 525 Section 6.1.1 therefore contains the integrity limits. 527 6.2. AEAD_CHACHA20_POLY1305, AEAD_AES_128_CCM, and AEAD_AES_128_CCM_8 529 There are currently no concrete multi-key bounds for 530 AEAD_CHACHA20_POLY1305, AEAD_AES_128_CCM, or AEAD_AES_128_CCM_8. 531 Thus, to account for the additional factor "u", i.e., the number of 532 keys, each "p" term in the confidentiality and integrity limits is 533 replaced with "p / u". 535 6.2.1. AEAD_CHACHA20_POLY1305 537 The combined confidentiality and integrity limit for 538 AEAD_CHACHA20_POLY1305 is as follows. 540 v <= ((p / u) * 2^106) / 8l 541 <= (p * 2^103) / (l * u) 543 6.2.2. AEAD_AES_128_CCM and AEAD_AES_128_CCM_8 545 The integrity limit for AEAD_AES_128_CCM is as follows. 547 v + q <= (p / u)^(1/2) * 2^63 / l 549 Likewise, the integrity limit for AEAD_AES_128_CCM_8 is as follows. 551 v * 2^64 + (2l * (v + q))^2 <= (p / u) * 2^128 553 7. Security Considerations 555 The different analyses of AEAD functions that this work is based upon 556 generally assume that the underlying primitives are ideal. For 557 example, that the pseudorandom function (PRF) or pseudorandom 558 permutation (PRP) the AEAD builds upon is indistinguishable from a 559 truly random function. Thus, the advantage estimates assume that the 560 attacker is not able to exploit a weakness in an underlying 561 primitive. 563 Many of the formulae in this document depend on simplifying 564 assumptions, from differing models, which means that results are not 565 universally applicable. When using this document to set limits, it 566 is necessary to validate all these assumptions for the setting in 567 which the limits might apply. In most cases, the goal is to use 568 assumptions that result in setting a more conservative limit, but 569 this is not always the case. As an example of one such 570 simplification, this document defines v as the total number of failed 571 decryption queries (that is, failed forgery attempts), whereas models 572 usually count in v all forgery attempts. 574 The CA and IL values defined in this document are upper bounds based 575 on existing cryptographic research. Future analysis may introduce 576 tighter bounds. Applications SHOULD NOT assume these bounds are 577 rigid, and SHOULD accommodate changes. In particular, in two-party 578 communication, one participant cannot regard apparent overuse of a 579 key by other participants as being in error, when it could be that 580 the other participant has better information about bounds. 582 Note that the limits in this document apply to the adversary's 583 ability to conduct a single successful forgery. For some algorithms 584 and in some cases, an adversary's success probability in repeating 585 forgeries may be noticeably larger than that of the first forgery. 586 As an example, [MF05] describes such multiple forgery attacks in the 587 context of AES-GCM in more detail. 589 8. IANA Considerations 591 This document does not make any request of IANA. 593 9. References 595 9.1. Normative References 597 [AEAD] Rogaway, P., "Authenticated-Encryption with Associated- 598 Data", September 2002, 599 . 601 [AEBounds] Luykx, A. and K. Paterson, "Limits on Authenticated 602 Encryption Use in TLS", 8 March 2016, 603 . 605 [AEComposition] 606 Bellare, M. and C. Namprempre, "Authenticated Encryption: 607 Relations among notions and analysis of the generic 608 composition paradigm", July 2007, 609 . 611 [CCM-ANALYSIS] 612 Jonsson, J., "On the Security of CTR + CBC-MAC", Selected 613 Areas in Cryptography pp. 76-93, 614 DOI 10.1007/3-540-36492-7_7, 2003, 615 . 617 [ChaCha20Poly1305Bounds] 618 Procter, G., "A Security Analysis of the Composition of 619 ChaCha20 and Poly1305", 11 August 2014, 620 . 622 [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of 623 Operation: Galois/Counter Mode (GCM) and GMAC", 624 NIST Special Publication 800-38D, November 2007. 626 [GCM-MU] Bellare, M. and B. Tackmann, "The Multi-User Security of 627 Authenticated Encryption: AES-GCM in TLS 1.3", 27 November 628 2017, . 630 [GCM-MU2] Hoang, V.T., Tessaro, S., and A. Thiruvengadam, "The 631 Multi-user Security of GCM, Revisited: Tight Bounds for 632 Nonce Randomization", 15 October 2018, 633 . 635 [GCMProofs] 636 Iwata, T., Ohashi, K., and K. Minematsu, "Breaking and 637 Repairing GCM Security Proofs", 1 August 2012, 638 . 640 [MUSecurity] 641 Bellare, M., Boldyreva, A., and S. Micali, "Public-Key 642 Encryption in a Multi-user Setting: Security Proofs and 643 Improvements", May 2000, 644 . 646 [Poly1305] Bernstein, D., "The Poly1305-AES Message-Authentication 647 Code", Fast Software Encryption pp. 32-49, 648 DOI 10.1007/11502760_3, 2005, 649 . 651 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 652 Requirement Levels", BCP 14, RFC 2119, 653 DOI 10.17487/RFC2119, March 1997, 654 . 656 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 657 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 658 . 660 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 661 Transport Layer Security (TLS)", RFC 6655, 662 DOI 10.17487/RFC6655, July 2012, 663 . 665 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 666 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 667 May 2017, . 669 [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 670 Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, 671 . 673 9.2. Informative References 675 [I-D.ietf-quic-tls] 676 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 677 Work in Progress, Internet-Draft, draft-ietf-quic-tls-34, 678 14 January 2021, . 681 [MF05] McGrew, D.A. and S.R. Fluhrer, "Multiple forgery attacks 682 against Message Authentication Codes", 31 May 2005, 683 . 687 [NonceDisrespecting] 688 Bock, H., Zauner, A., Devlin, S., Somorovsky, J., and P. 689 Jovanovic, "Nonce-Disrespecting Adversaries -- Practical 690 Forgery Attacks on GCM in TLS", 17 May 2016, 691 . 693 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 694 (TLS) Protocol Version 1.2", RFC 5246, 695 DOI 10.17487/RFC5246, August 2008, 696 . 698 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 699 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 700 . 702 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 703 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 704 . 706 Authors' Addresses 708 Felix Günther 709 ETH Zurich 711 Email: mail@felixguenther.info 713 Martin Thomson 714 Mozilla 716 Email: mt@lowentropy.net 718 Christopher A. Wood 719 Cloudflare 720 Email: caw@heapingbits.net