idnits 2.17.1 draft-irtf-cfrg-aead-limits-01.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 September 2020) is 1308 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-30 -- Duplicate reference: RFC8446, mentioned in 'TLS', was also mentioned in 'RFC8446'. Summary: 0 errors (**), 0 flaws (~~), 4 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: 24 March 2021 Mozilla 6 C.A. Wood 7 Cloudflare 8 20 September 2020 10 Usage Limits on AEAD Algorithms 11 draft-irtf-cfrg-aead-limits-01 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-user 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/chris-wood/draft-wood-cfrg-aead-limits 29 (https://github.com/chris-wood/draft-wood-cfrg-aead-limits). 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 24 March 2021. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Simplified BSD License text 59 as described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 66 3. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Calculating Limits . . . . . . . . . . . . . . . . . . . . . 6 68 5. Single-User AEAD Limits . . . . . . . . . . . . . . . . . . . 7 69 5.1. AEAD_AES_128_GCM and AEAD_AES_256_GCM . . . . . . . . . . 7 70 5.1.1. Confidentiality Limit . . . . . . . . . . . . . . . . 7 71 5.1.2. Integrity Limit . . . . . . . . . . . . . . . . . . . 8 72 5.2. AEAD_CHACHA20_POLY1305 . . . . . . . . . . . . . . . . . 8 73 5.3. AEAD_AES_128_CCM . . . . . . . . . . . . . . . . . . . . 8 74 5.3.1. Confidentiality Limit . . . . . . . . . . . . . . . . 9 75 5.3.2. Integrity Limit . . . . . . . . . . . . . . . . . . . 9 76 5.4. AEAD_AES_128_CCM_8 . . . . . . . . . . . . . . . . . . . 9 77 6. Multi-User AEAD Limits . . . . . . . . . . . . . . . . . . . 9 78 6.1. AEAD_AES_128_GCM and AEAD_AES_256_GCM . . . . . . . . . . 10 79 6.1.1. Authenticated Encryption Security Limit . . . . . . . 10 80 6.1.2. Confidentiality Limit . . . . . . . . . . . . . . . . 10 81 6.1.3. Integrity Limit . . . . . . . . . . . . . . . . . . . 10 82 6.2. AEAD_CHACHA20_POLY1305, AEAD_AES_128_CCM, and 83 AEAD_AES_128_CCM_8 . . . . . . . . . . . . . . . . . . . 11 84 6.2.1. AEAD_CHACHA20_POLY1305 . . . . . . . . . . . . . . . 11 85 6.2.2. AEAD_AES_128_CCM and AEAD_AES_128_CCM_8 . . . . . . . 11 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 90 9.2. Informative References . . . . . . . . . . . . . . . . . 13 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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, and 98 optional associated data - that produces ciphertext output and error 99 code indicating success or failure. The ciphertext is typically 100 composed of the encrypted plaintext bytes and an authentication tag. 102 The generic AEAD interface does not describe usage limits. Each AEAD 103 algorithm does describe limits on its inputs, but these are 104 formulated as strict functional limits, such as the maximum length of 105 inputs, which are determined by the properties of the underlying AEAD 106 composition. Degradation of the security of the AEAD as a single key 107 is used multiple times is not given a thorough treatment. 109 These limits might also be influenced by the number of "users" of a 110 given key. In the traditional setting, there is one key shared 111 between two parties. Any limits on the maximum length of inputs or 112 encryption operations apply to that single key. The attacker's goal 113 is to break security (confidentiality or integrity) of that specific 114 key. However, in practice, there are often many users with 115 independent keys. The "multi-user" security setting hence considers 116 an attacker's advantage in breaking security of any of these many 117 keys, further assuming the attacker may have done some offline work 118 to help break security. As a result, AEAD algorithm limits may 119 depend on offline work and the number of users. However, given that 120 a multi-user attacker does not target any specific user, acceptable 121 advantages may differ from that of the single-user setting. 123 The number of times a single pair of key and nonce can be used might 124 also be relevant to security. For some algorithms, such as 125 AEAD_AES_128_GCM or AEAD_AES_256_GCM, this limit is 1 and using the 126 same pair of key and nonce has serious consequences for both 127 confidentiality and integrity; see [NonceDisrespecting]. Nonce-reuse 128 resistant algorithms like AEAD_AES_128_GCM_SIV can tolerate a limited 129 amount of nonce reuse. 131 It is good practice to have limits on how many times the same key (or 132 pair of key and nonce) are used. Setting a limit based on some 133 measurable property of the usage, such as number of protected 134 messages or amount of data transferred, ensures that it is easy to 135 apply limits. This might require the application of simplifying 136 assumptions. For example, TLS 1.3 specifies limits on the number of 137 records that can be protected, using the simplifying assumption that 138 records are the same size; see Section 5.5 of [TLS]. 140 Currently, AEAD limits and usage requirements are scattered among 141 peer-reviewed papers, standards documents, and other RFCs. 142 Determining the correct limits for a given setting is challenging as 143 papers do not use consistent labels or conventions, and rarely apply 144 any simplifications that might aid in reaching a simple limit. 146 The intent of this document is to collate all relevant information 147 about the proper usage and limits of AEAD algorithms in one place. 148 This may serve as a standard reference when considering which AEAD 149 algorithm to use, and how to use it. 151 2. Requirements Notation 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in 156 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 157 capitals, as shown here. 159 3. Notation 161 This document defines limitations in part using the quantities below. 163 +========+====================================================+ 164 | Symbol | Description | 165 +========+====================================================+ 166 | n | AEAD block length (in bits) | 167 +--------+----------------------------------------------------+ 168 | k | AEAD key length (in bits) | 169 +--------+----------------------------------------------------+ 170 | r | AEAD nonce length (in bits) | 171 +--------+----------------------------------------------------+ 172 | t | Size of the authentication tag (in bits) | 173 +--------+----------------------------------------------------+ 174 | l | Length of each message (in blocks) | 175 +--------+----------------------------------------------------+ 176 | s | Total plaintext length in all messages (in blocks) | 177 +--------+----------------------------------------------------+ 178 | q | Number of protected messages (AEAD encryption | 179 | | invocations) | 180 +--------+----------------------------------------------------+ 181 | v | Number of attacker forgery attempts (failed AEAD | 182 | | decryption invocations) | 183 +--------+----------------------------------------------------+ 184 | p | Adversary attack probability | 185 +--------+----------------------------------------------------+ 186 | o | Offline adversary work (in number of encryption | 187 | | and decryption queries; multi-user setting only) | 188 +--------+----------------------------------------------------+ 189 | u | Number of users or keys (multi-user setting only) | 190 +--------+----------------------------------------------------+ 191 | B | Maximum number of blocks encrypted by any user or | 192 | | key (multi-user setting only) | 193 +--------+----------------------------------------------------+ 195 Table 1 197 For each AEAD algorithm, we define the (passive) confidentiality and 198 (active) integrity advantage roughly as the advantage an attacker has 199 in breaking the corresponding classical security property for the 200 algorithm. Moreover, we define the combined authenticated encryption 201 advantage guaranteeing both confidentiality and integrity against an 202 active attacker. Specifically: 204 * Confidentiality advantage (CA): The probability of a passive 205 attacker succeeding in breaking the confidentiality properties 206 (IND-CPA) of the AEAD scheme. In this document, the definition of 207 confidentiality advantage roughly is the probability that an 208 attacker successfully distinguishes the ciphertext outputs of the 209 AEAD scheme from the outputs of a random function. 211 * Integrity advantage (IA): The probability of a active attacker 212 succeeding in breaking the integrity properties (INT-CTXT) of the 213 AEAD scheme. In this document, the definition of integrity 214 advantage roughly is the probability that an attacker is able to 215 forge a ciphertext that will be accepted as valid. 217 * Authenticated Encryption advantage (AEA): The probability of a 218 active attacker succeeding in breaking the authenticated- 219 encryption properties of the AEAD scheme. In this document, the 220 definition of authenticated encryption advantage roughly is the 221 probability that an attacker successfully distinguishes the 222 ciphertext outputs of the AEAD scheme from the outputs of a random 223 function or is able to forge a ciphertext that will be accepted as 224 valid. 226 See [AEComposition], [AEAD] for the formal definitions of and 227 relations between passive confidentiality (IND-CPA), ciphertext 228 integrity (INT-CTXT), and authenticated encryption security (AE). 229 The authenticated encryption advantage subsumes, and can be derived 230 as the combination of, both CA and IA: 232 CA <= AEA 233 IA <= AEA 234 AEA <= CA + IA 236 Each application requires an individual determination of limits in 237 order to keep CA and IA sufficiently small. For instance, TLS aims 238 to keep CA below 2^-60 and IA below 2^-57 (in the single-user 239 setting). See [TLS], Section 5.5. 241 4. Calculating Limits 243 Once upper bounds on CA, IA, or AEA are determined, this document 244 defines a process for determining three overall operational limits: 246 * Confidentiality limit (CL): The number of messages an application 247 can encrypt before giving the adversary a confidentiality 248 advantage higher than CA. 250 * Integrity limit (IL): The number ciphertexts an application can 251 decrypt, either successfully or not, before giving the adversary 252 an integrity advantage higher than IA. 254 * Authenticated encryption limit (AEL): The combined number of 255 messages and number of ciphertexts an application can encrypt or 256 decrypt before giving the adversary an authenticated encryption 257 advantage higher than AEA. 259 When limits are expressed as a number of messages an application can 260 encrypt or decrypt, this requires assumptions about the size of 261 messages and any authenticated additional data (AAD). Limits can 262 instead be expressed in terms of the number of bytes, or blocks, of 263 plaintext and maybe AAD in total. To aid in translating between 264 message-based and byte/block-based limits, a formulation of limits 265 that includes a maximum message size (l) and the AEAD schemes' block 266 length in bits (n) is provided. 268 All limits are based on the total number of messages, either the 269 number of protected messages (q) or the number of forgery attempts 270 (v); which correspond to CL and IL respectively. 272 Limits are then derived from those bounds using a target attacker 273 probability. For example, given an integrity advantage of "IA = v * 274 (8l / 2^106)" and a targeted maximum attacker success probability of 275 "IA = p", the algorithm remains secure, i.e., the adversary's 276 advantage does not exceed the targeted probability of success, 277 provided that "v <= (p * 2^106) / 8l". In turn, this implies that "v 278 <= (p * 2^103) / l" is the corresponding limit. 280 5. Single-User AEAD Limits 282 This section summarizes the confidentiality and integrity bounds and 283 limits for modern AEAD algorithms used in IETF protocols, including: 284 AEAD_AES_128_GCM [RFC5116], AEAD_AES_256_GCM [RFC5116], 285 AEAD_AES_128_CCM [RFC5116], AEAD_CHACHA20_POLY1305 [RFC8439], 286 AEAD_AES_128_CCM_8 [RFC6655]. 288 The CL and IL values bound the total number of encryption and forgery 289 queries (q and v). Alongside each value, we also specify these 290 bounds. 292 5.1. AEAD_AES_128_GCM and AEAD_AES_256_GCM 294 The CL and IL values for AES-GCM are derived in [AEBounds] and 295 summarized below. For this AEAD, n = 128 and t = 128 [GCM]. In this 296 example, the length s is the sum of AAD and plaintext, as described 297 in [GCMProofs]. 299 5.1.1. Confidentiality Limit 301 CA <= ((s + q + 1)^2) / 2^129 303 This implies the following usage limit: 305 q + s <= p^(1/2) * 2^(129/2) - 1 306 Which, for a message-based protocol with "s <= q * l", if we assume 307 that every packet is size "l", produces the limit: 309 q <= (p^(1/2) * 2^(129/2) - 1) / (l + 1) 311 5.1.2. Integrity Limit 313 IA <= 2 * (v * (l + 1)) / 2^128 315 This implies the following limit: 317 v <= (p * 2^127) / (l + 1) 319 5.2. AEAD_CHACHA20_POLY1305 321 The only known analysis for AEAD_CHACHA20_POLY1305 322 [ChaCha20Poly1305Bounds] combines the confidentiality and integrity 323 limits into a single expression, covered below: 325 CA <= v * ((8 * l) / 2^106) 326 IA <= v * ((8 * l) / 2^106) 328 This advantage is a tight reduction based on the underlying Poly1305 329 PRF [Poly1305]. It implies the following limit: 331 v <= (p * 2^103) / l 333 5.3. AEAD_AES_128_CCM 335 The CL and IL values for AEAD_AES_128_CCM are derived from 336 [CCM-ANALYSIS] and specified in the QUIC-TLS mapping specification 337 [I-D.ietf-quic-tls]. This analysis uses the total number of 338 underlying block cipher operations to derive its bound. For CCM, 339 this number is the sum of: the length of the associated data in 340 blocks, the length of the ciphertext in blocks, the length of the 341 plaintext in blocks, plus 1. 343 In the following limits, this is simplified to a value of twice the 344 length of the packet in blocks, i.e., 2l represents the effective 345 length, in number of block cipher operations, of a message with l 346 blocks. This simplification is based on the observation that common 347 applications of this AEAD carry only a small amount of associated 348 data compared to ciphertext. For example, QUIC has 1 to 3 blocks of 349 AAD. 351 For this AEAD, n = 128 and t = 128. 353 5.3.1. Confidentiality Limit 355 CA <= (2l * q)^2 / 2^n 356 <= (2l * q)^2 / 2^128 358 This implies the following limit: 360 q <= sqrt((p * 2^126) / l^2) 362 5.3.2. Integrity Limit 364 IA <= v / 2^t + (2l * (v + q))^2 / 2^n 365 <= v / 2^128 + (2l * (v + q))^2 / 2^128 367 This implies the following limit: 369 v + (2l * (v + q))^2 <= p * 2^128 371 In a setting where "v" or "q" is sufficiently large, "v" is 372 negligible compared to "(2l * (v + q))^2", so this this can be 373 simplified to: 375 v + q <= p^(1/2) * 2^63 / l 377 5.4. AEAD_AES_128_CCM_8 379 The analysis in [CCM-ANALYSIS] also applies to this AEAD, but the 380 reduced tag length of 64 bits changes the integrity limit calculation 381 considerably. 383 IA <= v / 2^t + (2l * (v + q))^2 / 2^n 384 <= v / 2^64 + (2l * (v + q))^2 / 2^128 386 This results in reducing the limit on "v" by a factor of 2^64. 388 v * 2^64 + (2l * (v + q))^2 <= p * 2^128 390 6. Multi-User AEAD Limits 392 In the multi-user setting, each user is assumed to have an 393 independent and identically distributed key, though nonces may be re- 394 used across users with some very small probability. The success 395 probability in attacking one of these many independent user keys can 396 be generically bounded by the success probability of attacking a 397 single user multiplied by the number of users present [MUSecurity], 398 [GCM-MU]. Absent concrete multi-user bounds, this means the attacker 399 advantage in the multi-user setting is the product of the single-user 400 advantage and the number of users. 402 This section summarizes the confidentiality and integrity bounds and 403 limits for the same algorithms as in Section 5 for the multi-user 404 setting. The CL and IL values bound the total number of encryption 405 and forgery queries (q and v). Alongside each value, we also specify 406 these bounds. 408 6.1. AEAD_AES_128_GCM and AEAD_AES_256_GCM 410 Concrete multi-user bounds for AEAD_AES_128_GCM and AEAD_AES_256_GCM 411 exist due to [GCM-MU2]. AES-GCM without nonce randomization is also 412 discussed in [GCM-MU2], though this section does not include those 413 results as they do not apply to protocols such as TLS 1.3 [RFC8446]. 415 For this AEAD, n = 128, t = 128, and r = 96; the key length is k = 416 128 or k = 256. 418 6.1.1. Authenticated Encryption Security Limit 420 AEA <= ((q+v)*l*B / 2^127) + (1 / 2^48) 422 This implies the following limit: 424 q + v <= (p * 2^127 - 2^79) / (l * B) 426 6.1.2. Confidentiality Limit 428 The confidentiality advantage is essentially dominated by the same 429 terms as the AE advantage: 431 CA <= (q*l*B / 2^127) + (1 / 2^48) 433 This implies the following limit: 435 q <= (p * 2^127 - 2^79) / (l * B) 437 6.1.3. Integrity Limit 439 There is currently no dedicated integrity multi-user bound available 440 for AEAD_AES_128_GCM and AEAD_AES_256_GCM. The AE limit can be used 441 to derive an integrity limit as 443 IA <= AEA <= (q+v)*l*B / 2^127 + 1/2^48 445 This implies the following limit: 447 q + v <= (p * 2^127 - 2^79) / (l * B) 449 6.2. AEAD_CHACHA20_POLY1305, AEAD_AES_128_CCM, and AEAD_AES_128_CCM_8 451 There are currently no concrete multi-user bounds for 452 AEAD_CHACHA20_POLY1305, AEAD_AES_128_CCM, or AEAD_AES_128_CCM_8. 453 Thus, to account for the additional factor "u", i.e., the number of 454 users, each "p" term in the confidentiality and integrity limits is 455 replaced with "p / u". 457 6.2.1. AEAD_CHACHA20_POLY1305 459 The combined confidentiality and integrity limit for 460 AEAD_CHACHA20_POLY1305 is as follows. 462 v <= ((p / u) * 2^106) / 8l 463 <= (p * 2^103) / (l * u) 465 6.2.2. AEAD_AES_128_CCM and AEAD_AES_128_CCM_8 467 The integrity limit for AEAD_AES_128_CCM is as follows. 469 v + q <= (p / u)^(1/2) * 2^63 / l 471 Likewise, the integrity limit for AEAD_AES_128_CCM_8 is as follows. 473 v * 2^64 + (2l * (v + q))^2 <= (p / u) * 2^128 475 7. Security Considerations 477 Many of the formulae in this document depend on simplifying 478 assumptions that are not universally applicable. When using this 479 document to set limits, it is necessary to validate all these 480 assumptions for the setting in which the limits might apply. In most 481 cases, the goal is to use assumptions that result in setting a more 482 conservative limit, but this is not always the case. 484 8. IANA Considerations 486 This document does not make any request of IANA. 488 9. References 490 9.1. Normative References 492 [AEAD] Rogaway, P., "Authenticated-Encryption with Associated- 493 Data", September 2002, 494 . 496 [AEBounds] Luykx, A. and K. Paterson, "Limits on Authenticated 497 Encryption Use in TLS", 8 March 2016, 498 . 500 [AEComposition] 501 Bellare, M. and C. Namprempre, "Authenticated Encryption: 502 Relations among notions and analysis of the generic 503 composition paradigm", July 2007, 504 . 506 [CCM-ANALYSIS] 507 Jonsson, J., "On the Security of CTR + CBC-MAC", 508 DOI 10.1007/3-540-36492-7_7, Selected Areas in 509 Cryptography pp. 76-93, 2003, 510 . 512 [ChaCha20Poly1305Bounds] 513 Procter, G., "A Security Analysis of the Composition of 514 ChaCha20 and Poly1305", 11 August 2014, 515 . 517 [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of 518 Operation: Galois/Counter Mode (GCM) and GMAC", 519 NIST Special Publication 800-38D, November 2007. 521 [GCM-MU] Bellare, M. and B. Tackmann, "The Multi-User Security of 522 Authenticated Encryption: AES-GCM in TLS 1.3", 27 November 523 2017, . 525 [GCM-MU2] Hoang, V.T., Tessaro, S., and A. Thiruvengadam, "The 526 Multi-user Security of GCM, Revisited: Tight Bounds for 527 Nonce Randomization", 15 October 2018, 528 . 530 [GCMProofs] 531 Iwata, T., Ohashi, K., and K. Minematsu, "Breaking and 532 Repairing GCM Security Proofs", 1 August 2012, 533 . 535 [MUSecurity] 536 Bellare, M., Boldyreva, A., and S. Micali, "Public-Key 537 Encryption in a Multi-user Setting: Security Proofs and 538 Improvements", May 2000, 539 . 541 [Poly1305] Bernstein, D., "The Poly1305-AES Message-Authentication 542 Code", DOI 10.1007/11502760_3, Fast Software 543 Encryption pp. 32-49, 2005, 544 . 546 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 547 Requirement Levels", BCP 14, RFC 2119, 548 DOI 10.17487/RFC2119, March 1997, 549 . 551 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 552 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 553 . 555 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 556 Transport Layer Security (TLS)", RFC 6655, 557 DOI 10.17487/RFC6655, July 2012, 558 . 560 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 561 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 562 May 2017, . 564 [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 565 Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, 566 . 568 9.2. Informative References 570 [I-D.ietf-quic-tls] 571 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 572 Work in Progress, Internet-Draft, draft-ietf-quic-tls-30, 573 9 September 2020, . 576 [NonceDisrespecting] 577 Bock, H., Zauner, A., Devlin, S., Somorovsky, J., and P. 578 Jovanovic, "Nonce-Disrespecting Adversaries -- Practical 579 Forgery Attacks on GCM in TLS", 17 May 2016, 580 . 582 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 583 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 584 . 586 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 587 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 588 . 590 Authors' Addresses 592 Felix Günther 593 ETH Zurich 595 Email: mail@felixguenther.info 597 Martin Thomson 598 Mozilla 600 Email: mt@lowentropy.net 602 Christopher A. Wood 603 Cloudflare 605 Email: caw@heapingbits.net