idnits 2.17.1 draft-wood-cfrg-aead-limits-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (20 May 2020) is 1430 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-28 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: 21 November 2020 Mozilla 6 C.A. Wood 7 Cloudflare 8 20 May 2020 10 Usage Limits on AEAD Algorithms 11 draft-wood-cfrg-aead-limits-00 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. 22 Discussion Venues 24 This note is to be removed before publishing as an RFC. 26 Source for this draft and an issue tracker can be found at 27 https://github.com/chris-wood/draft-wood-cfrg-aead-limits 28 (https://github.com/chris-wood/draft-wood-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 21 November 2020. 47 Copyright Notice 49 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 65 3. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Calculating Limits . . . . . . . . . . . . . . . . . . . . . 4 67 5. AEAD Limits and Requirements . . . . . . . . . . . . . . . . 5 68 5.1. AEAD_AES_128_GCM and AEAD_AES_256_GCM . . . . . . . . . . 5 69 5.1.1. Confidentiality Limit . . . . . . . . . . . . . . . . 6 70 5.1.2. Integrity Limit . . . . . . . . . . . . . . . . . . . 6 71 5.2. AEAD_CHACHA20_POLY1305 . . . . . . . . . . . . . . . . . 6 72 5.3. AEAD_AES_128_CCM . . . . . . . . . . . . . . . . . . . . 6 73 5.3.1. Confidentiality Limit . . . . . . . . . . . . . . . . 7 74 5.3.2. Integrity Limit . . . . . . . . . . . . . . . . . . . 7 75 5.4. AEAD_AES_128_CCM_8 . . . . . . . . . . . . . . . . . . . 7 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 80 8.2. Informative References . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 An Authenticated Encryption with Associated Data (AEAD) algorithm 86 provides confidentiality and integrity. [RFC5116] specifies an AEAD 87 as a function with four inputs - secret key, nonce, plaintext, and 88 optional associated data - that produces ciphertext output and error 89 code indicating success or failure. The ciphertext is typically 90 composed of the encrypted plaintext bytes and an authentication tag. 92 The generic AEAD interface does not describe usage limits. Each AEAD 93 algorithm does describe limits on its inputs, but these are 94 formulated as strict functional limits, such as the maximum length of 95 inputs, which are determined by the properties of the underlying AEAD 96 composition. Degradation of the security of the AEAD as a single key 97 is used multiple times is not given a thorough treatment. 99 The number of times a single pair of key and nonce can be used might 100 also be relevant to security. For some algorithms, such as 101 AEAD_AES_128_GCM or AEAD_AES_256_GCM, this limit is 1 and using the 102 same pair of key and nonce has serious consequences for both 103 confidentiality and integrity; see [NonceDisrespecting]. Nonce-reuse 104 resistant algorithms like AEAD_AES_128_GCM_SIV can tolerate a limited 105 amount of nonce reuse. 107 It is good practice to have limits on how many times the same key (or 108 pair of key and nonce) are used. Setting a limit based on some 109 measurable property of the usage, such as number of protected 110 messages or amount of data transferred, ensures that it is easy to 111 apply limits. This might require the application of simplifying 112 assumptions. For example, TLS 1.3 specifies limits on the number of 113 records that can be protected, using the simplifying assumption that 114 records are the same size; see Section 5.5 of [TLS]. 116 Currently, AEAD limits and usage requirements are scattered among 117 peer-reviewed papers, standards documents, and other RFCs. 118 Determining the correct limits for a given setting is challenging as 119 papers do not use consistent labels or conventions, and rarely apply 120 any simplifications that might aid in reaching a simple limit. 122 The intent of this document is to collate all relevant information 123 about the proper usage and limits of AEAD algorithms in one place. 124 This may serve as a standard reference when considering which AEAD 125 algorithm to use, and how to use it. 127 2. Requirements Notation 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in 132 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 3. Notation 137 This document defines limitations in part using the quantities below. 139 +--------+----------------------------------------------------+ 140 | Symbol | Description | 141 +========+====================================================+ 142 | n | Size of the AEAD block cipher (in bits) | 143 +--------+----------------------------------------------------+ 144 | t | Size of the authentication tag (in bits) | 145 +--------+----------------------------------------------------+ 146 | l | Length of each message (in blocks) | 147 +--------+----------------------------------------------------+ 148 | s | Total plaintext length in all messages (in blocks) | 149 +--------+----------------------------------------------------+ 150 | q | Number of encryption attempts | 151 +--------+----------------------------------------------------+ 152 | v | Number of forgery attempts | 153 +--------+----------------------------------------------------+ 154 | p | Adversary attack probability | 155 +--------+----------------------------------------------------+ 157 Table 1 159 For each AEAD algorithm, we define the confidentiality and integrity 160 advantage roughly as the advantage an attacker has in breaking the 161 corresponding security property for the algorithm. Specifically: 163 * Confidentiality advantage (CA): The advantage of an attacker 164 succeeding in breaking the confidentiality properties of the AEAD. 165 In this document, the definition of confidentiality advantage is 166 the increase in the probability that an attacker is able to 167 successfully distinguish an AEAD ciphertext from the output of an 168 ideal pseudorandom permutation (PRP). 170 * Integrity advantage (IA): The probability of an attacker 171 succeeding in breaking the integrity properties of the AEAD. In 172 this document, the definition of integrity advantage is the 173 probability that an attacker is able to forge a ciphertext that 174 will be accepted as valid. 176 Each application requires a different application of limits in order 177 to keep CA and IA sufficiently small. For instance, TLS aims to keep 178 CA below 2^-60 and IA below 2^-57. See [TLS], Section 5.5. 180 4. Calculating Limits 182 Once an upper bound on CA and IA are determined, this document 183 defines a process for determining two overall limits: 185 * Confidentiality limit (CL): The number of bytes of plaintext and 186 maybe authenticated additional data (AAD) an application can 187 encrypt before giving the adversary a non-negligible CA. 189 * Integrity limit (IL): The number of bytes of ciphertext and maybe 190 authenticated additional data (AAD) an application can process, 191 either successfully or not, before giving the adversary a non- 192 negligible IA. 194 For an AEAD based on a block function, it is common for these limits 195 to be expressed instead in terms of the number of blocks rather than 196 bytes. Furthermore, it might be more appropriate to track the number 197 of messages rather than track bytes. Therefore, the guidance is 198 usually based on the total number of blocks processed (s). To aid in 199 calculating limits for message-based protocols, a formulation of 200 limits that includes a maximum message size (l) is included. 202 All limits are based on the total number of messages, either the 203 number of protected messages (q) or the number of forgery attempts 204 (v); which correspond to CL and IL respectively. 206 Limits are then derived from those bounds using a target attacker 207 probability. For example, given a confidentiality advantage of "v * 208 (8l / 2^106)" and attacker success probability of "p", the algorithm 209 remains secure, i.e., the adversary's advantage does not exceed the 210 probability of success, provided that "v <= (p * 2^106) / 8l". In 211 turn, this implies that "v <= (p * 2^106) / 8l" is the corresponding 212 limit. 214 5. AEAD Limits and Requirements 216 This section summarizes the confidentiality and integrity bounds and 217 limits for modern AEAD algorithms used in IETF protocols, including: 218 AEAD_AES_128_GCM [RFC5116], AEAD_AES_256_GCM [RFC5116], 219 AEAD_AES_128_CCM [RFC5116], AEAD_CHACHA20_POLY1305 [RFC8439], 220 AEAD_AES_128_CCM_8 [RFC6655]. 222 The CL and IL values bound the total number of encryption and forgery 223 queries (q and v). Alongside each value, we also specify these 224 bounds. 226 5.1. AEAD_AES_128_GCM and AEAD_AES_256_GCM 228 The CL and IL values for AES-GCM are derived in [AEBounds] and 229 summarized below. For this AEAD, n = 128 and t = 128 [GCM]. In this 230 example, the length s is the sum of AAD and plaintext, as described 231 in [GCMProofs]. 233 5.1.1. Confidentiality Limit 235 CA = ((s + q + 1)^2) / 2^129 237 This implies the following usage limit: 239 q + s <= p^(1/2) * 2^(129/2) - 1 241 Which, for a message-based protocol with "s <= q * l", if we assume 242 that every packet is size "l", produces the limit: 244 q <= (p^(1/2) * 2^(129/2) - 1) / (l + 1) 246 5.1.2. Integrity Limit 248 IA = 2 * (v * (l + 1)) / 2^128 250 This implies the following limit: 252 v <= (p * 2^127) / (l + 1) 254 5.2. AEAD_CHACHA20_POLY1305 256 The only known analysis for AEAD_CHACHA20_POLY1305 257 [ChaCha20Poly1305Bounds] combines the confidentiality and integrity 258 limits into a single expression, covered below: 260 CA = IA = v * (8l / 2^106) 262 This advantage is a tight reduction based on the underlying Poly1305 263 PRF [Poly1305]. It implies the following limit: 265 v <= (p * 2^106) / 8l 267 5.3. AEAD_AES_128_CCM 269 The CL and IL values for AEAD_AES_128_CCM are derived from 270 [CCM-ANALYSIS] and specified in the QUIC-TLS mapping specification 271 [I-D.ietf-quic-tls]. This analysis uses the total number of 272 underlying block cipher operations to derive its bound. For CCM, 273 this number is the sum of: the length of the associated data in 274 blocks, the length of the ciphertext in blocks, the length of the 275 plaintext in blocks, plus 1. 277 In the following limits, this is simplified to a value of twice the 278 length of the packet in blocks, i.e., 2l represents the effective 279 length, in number of block cipher operations, of a message with l 280 blocks. This simplification is based on the observation that common 281 applications of this AEAD carry only a small amount of associated 282 data compared to ciphertext. For example, QUIC has 1 to 3 blocks of 283 AAD. 285 For this AEAD, n = 128 and t = 128. 287 5.3.1. Confidentiality Limit 289 CA = (2l * q)^2 / 2^n 290 = (2l * q)^2 / 2^128 292 This implies the following limit: 294 q <= sqrt((p * (2^127)) / l^2) 296 5.3.2. Integrity Limit 298 IA = v / 2^t + (2l * (v + q))^2 / 2^n 299 = v / 2^128 + (2l * (v + q))^2 / 2^128 301 This implies the following limit: 303 v + (2l * (v + q))^2 <= p * 2^128 305 In a setting where "v" or "q" is sufficiently large, "v" is 306 negligible compared to "(2l * (v + q))^2", so this this can be 307 simplified to: 309 v + q <= p^(1/2) * 2^63 / l 311 5.4. AEAD_AES_128_CCM_8 313 The analysis in [CCM-ANALYSIS] also applies to this AEAD, but the 314 reduced tag length of 64 bits changes the integrity limit calculation 315 considerably. 317 IA = v / 2^t + (2l * (v + q))^2 / 2^n 318 = v / 2^64 + (2l * (v + q))^2 / 2^128 320 This results in reducing the limit on "v" by a factor of 2^64. 322 v * 2^64 + (2l * (v + q))^2 <= p * 2^128 324 6. Security Considerations 326 Many of the formulae in this document depend on simplifying 327 assumptions that are not universally applicable. When using this 328 document to set limits, it is necessary to validate all these 329 assumptions for the setting in which the limits might apply. In most 330 cases, the goal is to use assumptions that result in setting a more 331 conservative limit, but this is not always the case. 333 7. IANA Considerations 335 This document does not make any request of IANA. 337 8. References 339 8.1. Normative References 341 [AEBounds] Luykx, A. and K. Paterson, "Limits on Authenticated 342 Encryption Use in TLS", 8 March 2016, 343 . 345 [CCM-ANALYSIS] 346 Jonsson, J., "On the Security of CTR + CBC-MAC", 347 DOI 10.1007/3-540-36492-7_7, Selected Areas in 348 Cryptography pp. 76-93, 2003, 349 . 351 [ChaCha20Poly1305Bounds] 352 Procter, G., "A Security Analysis of the Composition of 353 ChaCha20 and Poly1305", 2014, 354 . 356 [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of 357 Operation: Galois/Counter Mode (GCM) and GMAC", 358 NIST Special Publication 800-38D, November 2007. 360 [GCMProofs] 361 Iwata, T., Ohashi, K., and K. Minematsu, "Breaking and 362 Repairing GCM Security Proofs", n.d., 363 . 365 [Poly1305] Bernstein, D.J., "The Poly1305-AES message-authentication 366 code", International Workshop on Fast Software Encryption, 367 2005 , n.d., . 370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 371 Requirement Levels", BCP 14, RFC 2119, 372 DOI 10.17487/RFC2119, March 1997, 373 . 375 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 376 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 377 . 379 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 380 Transport Layer Security (TLS)", RFC 6655, 381 DOI 10.17487/RFC6655, July 2012, 382 . 384 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 385 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 386 May 2017, . 388 [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 389 Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, 390 . 392 8.2. Informative References 394 [I-D.ietf-quic-tls] 395 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 396 Work in Progress, Internet-Draft, draft-ietf-quic-tls-28, 397 19 May 2020, . 400 [NonceDisrespecting] 401 Bock, H., Zauner, A., Devlin, S., Somorovsky, J., and P. 402 Jovanovic, "Nonce-Disrespecting Adversaries -- Practical 403 Forgery Attacks on GCM in TLS", 17 May 2016, 404 . 406 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 407 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 408 . 410 Authors' Addresses 412 Felix Günther 413 ETH Zurich 415 Email: mail@felixguenther.info 416 Martin Thomson 417 Mozilla 419 Email: mt@lowentropy.net 421 Christopher A. Wood 422 Cloudflare 424 Email: caw@heapingbits.net