idnits 2.17.1 draft-mcgrew-standby-cipher-00.txt: 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: ---------------------------------------------------------------------------- No issues found here. 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 (January 25, 2013) is 4101 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. McGrew 3 Internet-Draft A. Grieco 4 Intended status: Experimental Cisco 5 Expires: July 29, 2013 Y. Sheffer 6 Porticor 7 January 25, 2013 9 Selection of Future Cryptographic Standards 10 draft-mcgrew-standby-cipher-00 12 Abstract 14 The Advanced Encryption Standard (AES) is extensively used and is 15 widely believed to provide security that is more than adequate. 16 Several other cipher designs have been proposed for use in standards, 17 and new designs continue to be developed, while consideration of cost 18 and complexity impels that the number of mandatory-to-implement 19 ciphers be minimized. This note outlines an approach to the 20 selection of cryptographic algorithms that best serves the needs of 21 the users of cryptography: AES should continue in its role as the 22 mandatory-to-implement cipher, while other cipher designs should be 23 reviewed with the goal of selecting a single standby cipher. If 24 future advances in the science of cryptanalysis uncover security 25 issues with the AES, the standby cipher will be ready for adoption as 26 its replacement. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on July 29, 2013. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 64 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. The (Over)abundance of Ciphers . . . . . . . . . . . . . . . 3 66 4. Algorithm Agility and Security Policies . . . . . . . . . . 4 67 5. Cryptographic Protocols . . . . . . . . . . . . . . . . . . 5 68 6. A Standby Algorithm . . . . . . . . . . . . . . . . . . . . 6 69 6.1. Security Considerations . . . . . . . . . . . . . . . . . . 7 70 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . 8 71 8. Other Considerations . . . . . . . . . . . . . . . . . . . . 9 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 73 10. Security Considerations . . . . . . . . . . . . . . . . . . 9 74 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 12.1. Normative References . . . . . . . . . . . . . . . . . . . . 10 77 12.2. Informative References . . . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 1.1. Requirements Language 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 2. Background 90 The modern cryptography industry relies on peer-reviewed algorithms 91 and protocols. The robustness of a cryptographic algorithm can only 92 be established after experts have reviewed it and no weakness in the 93 algorithm has been found. Many advanced techniques have been 94 developed for designing algorithms and analyzing their security. 96 The reliance that the cryptographic industry has on expert review has 97 caused it to put a premium value on open publication, open peer 98 review, and open standards. The process that selected the Advanced 99 Encryption Standard (AES, [FIPS-197]), was open and transparent. 100 Fifteen submissions were accepted from around the world (though the 101 process was managed by the National Institute of Standards and 102 Technology (NIST) of the United States), and their security and 103 efficiency was widely analyzed and discussed at three public 104 workshops and other peer- reviewed venues over the course of four 105 years, before the Belgian submission was selected. The caution, 106 thoroughness, and openness of the selection process inspired 107 confidence on the part of standards organizations, and the AES cipher 108 was adopted by many international standards, including those in the 109 IETF and the IEEE. 111 Standards organizations are free to select the cryptographic 112 algorithms that meet their requirements for security and efficiency. 113 Currently, AES is the most commonly used cipher, because of the 114 confidence that the industry has in its design and because its wide 115 use ensures wide availability of implementations. The Triple Data 116 Encryption Standard (3DES) is a legacy algorithm that is still in 117 use, as is the RC4 stream cipher. 119 3. The (Over)abundance of Ciphers 121 The nice thing about standards is that there are so many of them 122 to choose from. - Andrew S. Tanenbaum 124 Several other ciphers have been proposed for use in IETF protocols in 125 recent years, including SEED, ARIA, Camellia, CLEFIA and GOST. In 126 some other instances, new ciphers have been introduced as unpublished 127 extensions to IETF standards (as was originally the case with ARIA) 128 or as part of new, non-standard protocols (such as WAPI). These 129 ciphers, as well as other ones, have been proposed in other contexts, 130 such as ISO/IEC JTC 1/SC 27 Working Group on Cryptography and 131 Security Mechanisms, the Japanese Cryptography Research and 132 Evaluation Committees (CRYPTREC), and the European Network of 133 Excellence in Cryptology (ECRYPT) II project. The availability of so 134 many cipher designs that appear to have adequate security is 135 encouraging. However, it would be counterproductive to require or 136 urge that every implementation of security protocols such as IPsec or 137 TLS include multiple new ciphers. That would increase the cost and 138 complexity of those protocols while contributing little benefit to 139 the Internet community. 141 Each additional cipher that an implementation supports will increase 142 the cost of its development, testing, and validation. 143 Implementations that use hardware to achieve scalability and 144 throughput will require additional circuits for each cipher. 145 Additionally, architectures deployed today rely on more than just two 146 endpoints having the same cipher support. Instead, they involve 147 ecosystems of capabilities to deliver secured communications. For 148 example, devices such as load balancers, authentication servers, etc. 149 are all required to support large scale deployments of services in 150 many architectures, and these devices would be required to implement 151 all possible ciphers. Finally, if a multiplicity of ciphers is used 152 in practice, it will drive up operational costs as well, because the 153 policy that determines when the new cipher must be used will need to 154 be put into effect. 156 4. Algorithm Agility and Security Policies 158 Standard cryptographic protocols, such as Transport Layer Security 159 (TLS) and Internet Protocol Security (IPsec), include functionality 160 that allows two endpoints to dynamically negotiate the algorithms 161 that are used in a particular session. This feature is called 162 algorithm agility, and it is important because it enables a new 163 algorithm to be easily introduced in a protocol, while preserving 164 interoperability between devices that support the new algorithm and 165 ones that do not. Algorithm agility is crucial to security because 166 it allows for the replacement of algorithms that are found to have 167 cryptographic weaknesses. 169 The algorithm negotiation capability can also be used to allow 170 implementations to support multiple algorithms, and dynamically 171 decide which algorithms to use. In principle, it is possible to have 172 different devices each support different sets of algorithms, as long 173 as each pair of sets is overlapping. However, it is highly desirable 174 to minimize the number of algorithms that must be supported by an 175 implementation, because of the complexity and administrative burden 176 of managing the policy associated with a multitude of algorithms. 177 Because of these factors, most standards choose to mandate only a 178 single algorithm that must be implemented by all devices, despite the 179 availability of a negotiation mechanism. In addition, cryptographic 180 negotiation also establishes other algorithms and parameters to be 181 used, such as key establishment, authentication, pseudorandom 182 functions, and key sizes. 184 Algorithm agility also allows the use of ciphers other than the 185 mandatory-to-implement cipher within specialized communities of 186 interest. This is a valid use of that capability, but it should be 187 noted, however, that there is complexity and cost in the use of 188 elaborate security policies. If a community of interest requires 189 that a particular cipher be used within that community, but allows 190 the use of other ciphers when devices from that community communicate 191 outside that community, it will need to put this policy into practice 192 on all devices within the community. This process will not be 193 trivial or easy to execute; there will need to be a mechanism by 194 which devices in the community can identify whether or not a 195 communicant is also inside the community. The situation is simpler 196 when a cipher is used only within a community of interest, and the 197 devices in that community are used to communicate only with other 198 devices in the same community. In this case, there is no need for a 199 mechanism that determines which other devices are also in the 200 community; each device in the community can be configured to only use 201 the favored cipher. 203 5. Cryptographic Protocols 205 The IETF should allow the use of specialized algorithms within the 206 cryptographic protocol standards that it defines. To do otherwise 207 could encourage the proliferation of protocol standards, which is a 208 worse situation than the proliferation of cipher standards. It is 209 highly desirable to limit the number of cryptographic protocols. It 210 is much harder to replace a protocol, or to support multiple 211 protocols, as opposed to replacing a cryptographic algorithm. An 212 algorithm may have high complexity, but the complexity is well 213 isolated through a simple interface. In contrast, the complexity of 214 a protocol is not at all isolated; it touches the protocol layers 215 above and below it, and an efficient protocol implementation will 216 closely interact with the system on which it runs. 218 It is far better to add a new feature or algorithm to an existing 219 cryptographic protocol than to introduce an entirely new protocol. 221 By way of example, the TLS protocol was extended so that it can 222 protect UDP traffic as well as TCP traffic, resulting in the Datagram 223 TLS (DTLS) protocol. This standards action was widely perceived as 224 being preferable to the introduction of a new protocol that would 225 protected only UDP. 227 6. A Standby Algorithm 229 The industry is in the fortunate position that the main requirements 230 for a mandatory global cipher and algorithm agility are met by 231 current standards for communication security protocols. Many 232 additional ciphers have been proposed for use in these standards. It 233 may be useful for the global crypto standards community to seek 234 algorithm diversity by selecting a cipher to be used as a standby or 235 fallback, in case of the possibility that future advances in the 236 science of cryptanalysis might uncover security issues with the 237 current global standard cipher. The implementation of the standby 238 cipher should not be required, but could be recommended for 239 implementation by security protocol standards. In the terms of RFC 240 2119, the standby algorithm SHOULD be implemented. 242 The process for the selection of a standby should meet the same 243 Exacting criteria as the global standard cipher, to assure its 244 technical merit. Ideally, a standby cipher should be selected in 245 advance of when it is needed. That cipher should be chosen after 246 extensive public review and analysis, in which time is allowed for 247 significant scientific scrutiny and investigation. The cipher should 248 demonstrate its strength through the publication of attacks that work 249 only against a small number of rounds, since an absence of published 250 attacks may indicate an absence of cryptanalysis instead of an 251 absence of weaknesses. The best cipher designs from around the world 252 should be considered, and analyses should be openly published and 253 widely disseminated. Only a single standby cipher should be 254 recommended, to minimize the cost of implementation and maximize 255 interoperability. To be recommended as a standby, an algorithm 256 should meet all of the criteria set out for the AES: 258 o security, 259 o computational efficiency, 260 o memory requirements, 261 o hardware and software suitability, 262 o simplicity, 263 o flexibility, and 264 o licensing requirements; in particular, it should be available 265 worldwide on a royalty-free basis. 267 In addition to the AES requirements, there are requirements that are 268 particular to a cipher that would serve as a standby to the AES: 270 o it should have a design that is as independent of that of the AES 271 as is possible, so that advances in cryptanalysis that lower the 272 effective security of one design have as little effect as possible 273 on the other one, and 274 o it should also perform well on existing hardware that is optimized 275 for AES implementation. 277 The final criterion, performance on existing AES optimized hardware, 278 refers to the consideration for standby algorithm performance when 279 executing in existing hardware today. The goal of this criteria 280 would be to select a cipher that performs well today on existing 281 hardware implementations, many of which have optimized AES 282 implementations. This constraint would provide for a more timely 283 transition to the standby cipher because no new hardware optimization 284 would be needed. However, this criteria is focused on short term 285 deployment and does so at a cost of constraining the design of the 286 standby cipher. A longer term view would remove this criteria and 287 consider all ciphers that are practical to implement without specific 288 consideration to applicability to existing hardware optimization. In 289 doing so, designs considered for the standby cipher would be more 290 flexible and likely positively impact considerations in other 291 criteria categories, but could also increase adoption time. The 292 authors note this inherent conflict associated with this criteria and 293 request the community's opinion about resolution to this issue. 295 The Triple-DES (TDES) algorithm has a 64-bit block size, and because 296 of this, is not suitable for securing very large volumes of data 297 [coll64bit]. It also is significantly slower in software, and less 298 efficient in hardware. Thus TDES is not a suitable standby cipher. 299 This is an additional motivation for the selection of a new standby 300 algorithm. 302 6.1. Security Considerations 304 There is no known weakness in AES that affects its practical 305 security. Biclique cryptanalysis add citation can be used to shave 306 one or two bytes off of the theoretical strength of the cipher, in 307 scenarios in which the attacker can cause the encryption/decryption 308 of 2^88 chosen plaintexts/ciphertexts of its choice. This attack has 309 no relevance on the uses of AES in conventional block cipher modes of 310 operation, in which 2^64 blocks is the accepted maximum number that 311 should be encrypted with any key. There have been related key 312 attacks against AES-192 and AES-256, and suggestions that the key 313 schedule of that algorithm is not as strong as would be desirable. 314 Thus three important criteria for a standby cipher are that there 315 should be an absence of related key attacks against it, there should 316 be especially high confidence in its 192 and 256 bit variants, and 317 the key schedule should be perceived to be strong. The major goal of 318 a standby cipher is to be secure even if the AES proves vulnerable to 319 future advances in cryptanalysis. Thus, a standby cipher should not 320 follow a design strategy that is identical to that of the AES. Block 321 ciphers with a 64-bit block have a very significantly lower security 322 level than those with a 128-bit block, and thus should be strongly 323 discouraged. 325 7. Recommendations 327 The industry and the IETF should encourage the use of existing 328 security protocols, and to this end, the IETF should allow the 329 publication of documents describing the use of ciphers in IETF 330 standards, even when those ciphers have only a small community of 331 interest. This policy was clarified by the Security Area Directors 332 at IETF78, and it should be continued. However, the IETF should 333 explicitly reject the idea that each community of interest gets to 334 have its favored cipher be added to the list of mandatory-to- 335 implement ciphers. It is important to clarify the difference between 336 algorithms that MUST be implemented in a particular protocol from the 337 algorithms that MAY be implemented. We suggest that: 339 o The IETF and IRTF Crypto Forum Research Group (CFRG) should 340 identify the technical requirements that a standby cipher should 341 meet, and provide this input to the international cryptographic 342 community. This effort will be led by the CFRG, with the goal 343 that the requirement document be published as an RFC no later than 344 XXX months after the current document is published. 345 o The IETF and IRTF Crypto Forum Research Group (CFRG) should 346 identify the technical requirements that a standby cipher should 347 meet, and provide this input to the international cryptographic 348 community. 349 o Ideally, the process will result in the IETF-wide selection of a 350 single standby cipher, followed by a lengthy process of individual 351 working groups adopting this choice for their specific protocols. 352 However the CFRG may also reach the unfortunate conclusion that no 353 current algorithm fulfills the requirements. 354 o The IETF should encourage and support the discussion and analysis 355 of a standby cipher through open and public processes. 356 o Communities of interest that seek to introduce new ciphers to the 357 industry should be encouraged to participate in international 358 standards and other public processes for discussion, review, 359 analysis, presentation, and dissemination of results. 361 8. Other Considerations 363 Above we discussed only symmetric ciphers. Similar considerations 364 apply to hashing, message authentication, signatures, key exchange, 365 and asymmetric encryption. It is highly desirable to limit the 366 number of new cryptographic algorithms that are introduced into 367 standards. The Galois/Counter Mode (GCM) of operation for block 368 ciphers and the Counter and CBC-MAC (CCM) Mode of operation for block 369 ciphers provide both encryption and authentication; they do away with 370 the need to implement a separate message authentication code such as 371 HMAC. This is a strong advantage in the context of limiting the 372 number of algorithms. 374 It could reasonably be argued that instead of selecting a block 375 cipher, the standards community should be selecting an Authenticated 376 Encryption with Associated Data (AEAD) mechanism [RFC5116]. The 377 cryptographic algorithm design community has identified AEAD as the 378 best paradigm for symmetric cryptography, and there is theoretical 379 interest in the development of new algorithms in this area, as 380 indicated by the recent Directions in Authenticated Ciphers workshop. 381 However, it is not yet clear that such a mechanism could be adopted 382 as easily as a new block cipher. 384 The hash algorithm contest recently completed by NIST created a 385 selection for SHA-3. SHA-256 remains the standard, mandatory to 386 implement hash algorithm, but SHA-3 could be considered the standby 387 hash algorithm. 389 9. IANA Considerations 391 This memo includes no request to IANA. 393 10. Security Considerations 395 This note analyzes the considerations in the selection of 396 cryptographic algorithms for future use. The appropriate selection 397 of algorithms is important for security. 399 11. Acknowledgements 401 This document was prepared using the lyx2rfc tool, and we would like 402 to thank Nico Williams, its author. 404 12. References 405 12.1. Normative References 407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 408 Requirement Levels", BCP 14, RFC 2119, March 1997. 410 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 411 Encryption", RFC 5116, January 2008. 413 12.2. Informative References 415 [FIPS-197] 416 National Institute of Standards and Technology (NIST), 417 "Advanced Encryption Standard (AES)", FIPS PUB 197, 418 November 2001. 420 [coll64bit] 421 McGrew, D., "Impossible plaintext cryptanalysis and 422 probable-plaintext collision attacks of 64-bit block 423 cipher modes", IACR Eprint Archive 2012/623, 424 November 2012, . 426 Authors' Addresses 428 David McGrew 429 Cisco Systems, Inc. 430 13600 Dulles Technology Drive 431 Herndon, VA 20171 432 USA 434 Email: mcgrew@cisco.com 436 Anthony Grieco 437 Cisco Systems, Inc. 438 7025 Kit Creek Road 439 RTP, NC 27709 440 USA 442 Email: agrieco@cisco.com 443 Yaron Sheffer 444 Porticor 445 10 Yirmiyahu St. 446 Ramat HaSharon 47298 447 Israel 449 Email: yaronf.ietf@gmail.com