Network Working Group D. McGrew Internet-Draft A. Grieco Intended status: Experimental Cisco Expires: July 29, 2013 Y. Sheffer Porticor January 25, 2013 Selection of Future Cryptographic Standards draft-mcgrew-standby-cipher-00 Abstract The Advanced Encryption Standard (AES) is extensively used and is widely believed to provide security that is more than adequate. Several other cipher designs have been proposed for use in standards, and new designs continue to be developed, while consideration of cost and complexity impels that the number of mandatory-to-implement ciphers be minimized. This note outlines an approach to the selection of cryptographic algorithms that best serves the needs of the users of cryptography: AES should continue in its role as the mandatory-to-implement cipher, while other cipher designs should be reviewed with the goal of selecting a single standby cipher. If future advances in the science of cryptanalysis uncover security issues with the AES, the standby cipher will be ready for adoption as its replacement. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 29, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. McGrew, et al. Expires July 29, 2013 [Page 1] Internet-Draft Standby Cipher Selection January 2013 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The (Over)abundance of Ciphers . . . . . . . . . . . . . . . 3 4. Algorithm Agility and Security Policies . . . . . . . . . . 4 5. Cryptographic Protocols . . . . . . . . . . . . . . . . . . 5 6. A Standby Algorithm . . . . . . . . . . . . . . . . . . . . 6 6.1. Security Considerations . . . . . . . . . . . . . . . . . . 7 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . 8 8. Other Considerations . . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . 9 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . . . 10 12.2. Informative References . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 McGrew, et al. Expires July 29, 2013 [Page 2] Internet-Draft Standby Cipher Selection January 2013 1. Introduction 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Background The modern cryptography industry relies on peer-reviewed algorithms and protocols. The robustness of a cryptographic algorithm can only be established after experts have reviewed it and no weakness in the algorithm has been found. Many advanced techniques have been developed for designing algorithms and analyzing their security. The reliance that the cryptographic industry has on expert review has caused it to put a premium value on open publication, open peer review, and open standards. The process that selected the Advanced Encryption Standard (AES, [FIPS-197]), was open and transparent. Fifteen submissions were accepted from around the world (though the process was managed by the National Institute of Standards and Technology (NIST) of the United States), and their security and efficiency was widely analyzed and discussed at three public workshops and other peer- reviewed venues over the course of four years, before the Belgian submission was selected. The caution, thoroughness, and openness of the selection process inspired confidence on the part of standards organizations, and the AES cipher was adopted by many international standards, including those in the IETF and the IEEE. Standards organizations are free to select the cryptographic algorithms that meet their requirements for security and efficiency. Currently, AES is the most commonly used cipher, because of the confidence that the industry has in its design and because its wide use ensures wide availability of implementations. The Triple Data Encryption Standard (3DES) is a legacy algorithm that is still in use, as is the RC4 stream cipher. 3. The (Over)abundance of Ciphers The nice thing about standards is that there are so many of them to choose from. - Andrew S. Tanenbaum Several other ciphers have been proposed for use in IETF protocols in recent years, including SEED, ARIA, Camellia, CLEFIA and GOST. In McGrew, et al. Expires July 29, 2013 [Page 3] Internet-Draft Standby Cipher Selection January 2013 some other instances, new ciphers have been introduced as unpublished extensions to IETF standards (as was originally the case with ARIA) or as part of new, non-standard protocols (such as WAPI). These ciphers, as well as other ones, have been proposed in other contexts, such as ISO/IEC JTC 1/SC 27 Working Group on Cryptography and Security Mechanisms, the Japanese Cryptography Research and Evaluation Committees (CRYPTREC), and the European Network of Excellence in Cryptology (ECRYPT) II project. The availability of so many cipher designs that appear to have adequate security is encouraging. However, it would be counterproductive to require or urge that every implementation of security protocols such as IPsec or TLS include multiple new ciphers. That would increase the cost and complexity of those protocols while contributing little benefit to the Internet community. Each additional cipher that an implementation supports will increase the cost of its development, testing, and validation. Implementations that use hardware to achieve scalability and throughput will require additional circuits for each cipher. Additionally, architectures deployed today rely on more than just two endpoints having the same cipher support. Instead, they involve ecosystems of capabilities to deliver secured communications. For example, devices such as load balancers, authentication servers, etc. are all required to support large scale deployments of services in many architectures, and these devices would be required to implement all possible ciphers. Finally, if a multiplicity of ciphers is used in practice, it will drive up operational costs as well, because the policy that determines when the new cipher must be used will need to be put into effect. 4. Algorithm Agility and Security Policies Standard cryptographic protocols, such as Transport Layer Security (TLS) and Internet Protocol Security (IPsec), include functionality that allows two endpoints to dynamically negotiate the algorithms that are used in a particular session. This feature is called algorithm agility, and it is important because it enables a new algorithm to be easily introduced in a protocol, while preserving interoperability between devices that support the new algorithm and ones that do not. Algorithm agility is crucial to security because it allows for the replacement of algorithms that are found to have cryptographic weaknesses. The algorithm negotiation capability can also be used to allow implementations to support multiple algorithms, and dynamically decide which algorithms to use. In principle, it is possible to have different devices each support different sets of algorithms, as long McGrew, et al. Expires July 29, 2013 [Page 4] Internet-Draft Standby Cipher Selection January 2013 as each pair of sets is overlapping. However, it is highly desirable to minimize the number of algorithms that must be supported by an implementation, because of the complexity and administrative burden of managing the policy associated with a multitude of algorithms. Because of these factors, most standards choose to mandate only a single algorithm that must be implemented by all devices, despite the availability of a negotiation mechanism. In addition, cryptographic negotiation also establishes other algorithms and parameters to be used, such as key establishment, authentication, pseudorandom functions, and key sizes. Algorithm agility also allows the use of ciphers other than the mandatory-to-implement cipher within specialized communities of interest. This is a valid use of that capability, but it should be noted, however, that there is complexity and cost in the use of elaborate security policies. If a community of interest requires that a particular cipher be used within that community, but allows the use of other ciphers when devices from that community communicate outside that community, it will need to put this policy into practice on all devices within the community. This process will not be trivial or easy to execute; there will need to be a mechanism by which devices in the community can identify whether or not a communicant is also inside the community. The situation is simpler when a cipher is used only within a community of interest, and the devices in that community are used to communicate only with other devices in the same community. In this case, there is no need for a mechanism that determines which other devices are also in the community; each device in the community can be configured to only use the favored cipher. 5. Cryptographic Protocols The IETF should allow the use of specialized algorithms within the cryptographic protocol standards that it defines. To do otherwise could encourage the proliferation of protocol standards, which is a worse situation than the proliferation of cipher standards. It is highly desirable to limit the number of cryptographic protocols. It is much harder to replace a protocol, or to support multiple protocols, as opposed to replacing a cryptographic algorithm. An algorithm may have high complexity, but the complexity is well isolated through a simple interface. In contrast, the complexity of a protocol is not at all isolated; it touches the protocol layers above and below it, and an efficient protocol implementation will closely interact with the system on which it runs. It is far better to add a new feature or algorithm to an existing cryptographic protocol than to introduce an entirely new protocol. McGrew, et al. Expires July 29, 2013 [Page 5] Internet-Draft Standby Cipher Selection January 2013 By way of example, the TLS protocol was extended so that it can protect UDP traffic as well as TCP traffic, resulting in the Datagram TLS (DTLS) protocol. This standards action was widely perceived as being preferable to the introduction of a new protocol that would protected only UDP. 6. A Standby Algorithm The industry is in the fortunate position that the main requirements for a mandatory global cipher and algorithm agility are met by current standards for communication security protocols. Many additional ciphers have been proposed for use in these standards. It may be useful for the global crypto standards community to seek algorithm diversity by selecting a cipher to be used as a standby or fallback, in case of the possibility that future advances in the science of cryptanalysis might uncover security issues with the current global standard cipher. The implementation of the standby cipher should not be required, but could be recommended for implementation by security protocol standards. In the terms of RFC 2119, the standby algorithm SHOULD be implemented. The process for the selection of a standby should meet the same Exacting criteria as the global standard cipher, to assure its technical merit. Ideally, a standby cipher should be selected in advance of when it is needed. That cipher should be chosen after extensive public review and analysis, in which time is allowed for significant scientific scrutiny and investigation. The cipher should demonstrate its strength through the publication of attacks that work only against a small number of rounds, since an absence of published attacks may indicate an absence of cryptanalysis instead of an absence of weaknesses. The best cipher designs from around the world should be considered, and analyses should be openly published and widely disseminated. Only a single standby cipher should be recommended, to minimize the cost of implementation and maximize interoperability. To be recommended as a standby, an algorithm should meet all of the criteria set out for the AES: o security, o computational efficiency, o memory requirements, o hardware and software suitability, o simplicity, o flexibility, and o licensing requirements; in particular, it should be available worldwide on a royalty-free basis. In addition to the AES requirements, there are requirements that are McGrew, et al. Expires July 29, 2013 [Page 6] Internet-Draft Standby Cipher Selection January 2013 particular to a cipher that would serve as a standby to the AES: o it should have a design that is as independent of that of the AES as is possible, so that advances in cryptanalysis that lower the effective security of one design have as little effect as possible on the other one, and o it should also perform well on existing hardware that is optimized for AES implementation. The final criterion, performance on existing AES optimized hardware, refers to the consideration for standby algorithm performance when executing in existing hardware today. The goal of this criteria would be to select a cipher that performs well today on existing hardware implementations, many of which have optimized AES implementations. This constraint would provide for a more timely transition to the standby cipher because no new hardware optimization would be needed. However, this criteria is focused on short term deployment and does so at a cost of constraining the design of the standby cipher. A longer term view would remove this criteria and consider all ciphers that are practical to implement without specific consideration to applicability to existing hardware optimization. In doing so, designs considered for the standby cipher would be more flexible and likely positively impact considerations in other criteria categories, but could also increase adoption time. The authors note this inherent conflict associated with this criteria and request the community's opinion about resolution to this issue. The Triple-DES (TDES) algorithm has a 64-bit block size, and because of this, is not suitable for securing very large volumes of data [coll64bit]. It also is significantly slower in software, and less efficient in hardware. Thus TDES is not a suitable standby cipher. This is an additional motivation for the selection of a new standby algorithm. 6.1. Security Considerations There is no known weakness in AES that affects its practical security. Biclique cryptanalysis add citation can be used to shave one or two bytes off of the theoretical strength of the cipher, in scenarios in which the attacker can cause the encryption/decryption of 2^88 chosen plaintexts/ciphertexts of its choice. This attack has no relevance on the uses of AES in conventional block cipher modes of operation, in which 2^64 blocks is the accepted maximum number that should be encrypted with any key. There have been related key attacks against AES-192 and AES-256, and suggestions that the key schedule of that algorithm is not as strong as would be desirable. Thus three important criteria for a standby cipher are that there should be an absence of related key attacks against it, there should McGrew, et al. Expires July 29, 2013 [Page 7] Internet-Draft Standby Cipher Selection January 2013 be especially high confidence in its 192 and 256 bit variants, and the key schedule should be perceived to be strong. The major goal of a standby cipher is to be secure even if the AES proves vulnerable to future advances in cryptanalysis. Thus, a standby cipher should not follow a design strategy that is identical to that of the AES. Block ciphers with a 64-bit block have a very significantly lower security level than those with a 128-bit block, and thus should be strongly discouraged. 7. Recommendations The industry and the IETF should encourage the use of existing security protocols, and to this end, the IETF should allow the publication of documents describing the use of ciphers in IETF standards, even when those ciphers have only a small community of interest. This policy was clarified by the Security Area Directors at IETF78, and it should be continued. However, the IETF should explicitly reject the idea that each community of interest gets to have its favored cipher be added to the list of mandatory-to- implement ciphers. It is important to clarify the difference between algorithms that MUST be implemented in a particular protocol from the algorithms that MAY be implemented. We suggest that: o The IETF and IRTF Crypto Forum Research Group (CFRG) should identify the technical requirements that a standby cipher should meet, and provide this input to the international cryptographic community. This effort will be led by the CFRG, with the goal that the requirement document be published as an RFC no later than XXX months after the current document is published. o The IETF and IRTF Crypto Forum Research Group (CFRG) should identify the technical requirements that a standby cipher should meet, and provide this input to the international cryptographic community. o Ideally, the process will result in the IETF-wide selection of a single standby cipher, followed by a lengthy process of individual working groups adopting this choice for their specific protocols. However the CFRG may also reach the unfortunate conclusion that no current algorithm fulfills the requirements. o The IETF should encourage and support the discussion and analysis of a standby cipher through open and public processes. o Communities of interest that seek to introduce new ciphers to the industry should be encouraged to participate in international standards and other public processes for discussion, review, analysis, presentation, and dissemination of results. McGrew, et al. Expires July 29, 2013 [Page 8] Internet-Draft Standby Cipher Selection January 2013 8. Other Considerations Above we discussed only symmetric ciphers. Similar considerations apply to hashing, message authentication, signatures, key exchange, and asymmetric encryption. It is highly desirable to limit the number of new cryptographic algorithms that are introduced into standards. The Galois/Counter Mode (GCM) of operation for block ciphers and the Counter and CBC-MAC (CCM) Mode of operation for block ciphers provide both encryption and authentication; they do away with the need to implement a separate message authentication code such as HMAC. This is a strong advantage in the context of limiting the number of algorithms. It could reasonably be argued that instead of selecting a block cipher, the standards community should be selecting an Authenticated Encryption with Associated Data (AEAD) mechanism [RFC5116]. The cryptographic algorithm design community has identified AEAD as the best paradigm for symmetric cryptography, and there is theoretical interest in the development of new algorithms in this area, as indicated by the recent Directions in Authenticated Ciphers workshop. However, it is not yet clear that such a mechanism could be adopted as easily as a new block cipher. The hash algorithm contest recently completed by NIST created a selection for SHA-3. SHA-256 remains the standard, mandatory to implement hash algorithm, but SHA-3 could be considered the standby hash algorithm. 9. IANA Considerations This memo includes no request to IANA. 10. Security Considerations This note analyzes the considerations in the selection of cryptographic algorithms for future use. The appropriate selection of algorithms is important for security. 11. Acknowledgements This document was prepared using the lyx2rfc tool, and we would like to thank Nico Williams, its author. 12. References McGrew, et al. Expires July 29, 2013 [Page 9] Internet-Draft Standby Cipher Selection January 2013 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, January 2008. 12.2. Informative References [FIPS-197] National Institute of Standards and Technology (NIST), "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001. [coll64bit] McGrew, D., "Impossible plaintext cryptanalysis and probable-plaintext collision attacks of 64-bit block cipher modes", IACR Eprint Archive 2012/623, November 2012, . Authors' Addresses David McGrew Cisco Systems, Inc. 13600 Dulles Technology Drive Herndon, VA 20171 USA Email: mcgrew@cisco.com Anthony Grieco Cisco Systems, Inc. 7025 Kit Creek Road RTP, NC 27709 USA Email: agrieco@cisco.com McGrew, et al. Expires July 29, 2013 [Page 10] Internet-Draft Standby Cipher Selection January 2013 Yaron Sheffer Porticor 10 Yirmiyahu St. Ramat HaSharon 47298 Israel Email: yaronf.ietf@gmail.com McGrew, et al. Expires July 29, 2013 [Page 11]