Internet Engineering Task Force (IETF) Phillip Hallam-Baker Internet-Draft Comodo Group Inc. Intended Status: Standards Track March 17, 2014 Expires: September 18, 2014 Consensus Cryptographic Algorithms draft-hallambaker-consensuscrypto-00 Abstract This document specifies conformance criteria for choices of cryptographic algorithms. Conformance with this document establishes that an implementation supports the community consensus for choice of cryptographic algorithms at the time of publication and that the implementation can interoperate with other implementations compliant with the specified criteria. 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." Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Hallam-Baker September 18, 2014 [Page 1] Internet-Draft Consensus Cryptographic Algorithms March 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Consensus Cryptographic Algorithms . . . . . . . . . . . . . . 3 2.1. Complicance Criteria . . . . . . . . . . . . . . . . . . 4 2.1.1. Enhanced Criteria . . . . . . . . . . . . . . . . . 4 2.1.2. Exempt circumstances . . . . . . . . . . . . . . . . 4 2.2. Selection Criteria . . . . . . . . . . . . . . . . . . . 5 2.2.1. Established Consensus . . . . . . . . . . . . . . . 5 2.2.2. Unencumbered . . . . . . . . . . . . . . . . . . . . 5 2.3. Disqualification Criteria . . . . . . . . . . . . . . . . 5 2.3.1. Algorithm Weaknesses. . . . . . . . . . . . . . . . 6 2.3.2. Intellectual Property Claim. . . . . . . . . . . . . 6 2.4. Algorithm Variations . . . . . . . . . . . . . . . . . . 6 2.4.1. Cipher Modes . . . . . . . . . . . . . . . . . . . . 6 2.4.2. Key Sizes . . . . . . . . . . . . . . . . . . . . . 6 2.4.3. Shared Parameters . . . . . . . . . . . . . . . . . 7 2.4.4. Formats . . . . . . . . . . . . . . . . . . . . . . 7 2.4.5. Required Algorithms . . . . . . . . . . . . . . . . 7 2.4.6. Recommended Algorithms . . . . . . . . . . . . . . . 7 3. Required Algorithms . . . . . . . . . . . . . . . . . . . . . 7 3.1. Symmetric Key . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. Cryptographic Digest . . . . . . . . . . . . . . . . 7 3.1.2. Message Authentication Code . . . . . . . . . . . . 8 3.1.3. Encryption . . . . . . . . . . . . . . . . . . . . . 8 3.2. Public Key . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Ephemeral Key Agreement . . . . . . . . . . . . . . 9 3.2.2. Public Key Encryption . . . . . . . . . . . . . . . 9 3.2.3. Digital Signature . . . . . . . . . . . . . . . . . 9 4. Recommended Algorithms . . . . . . . . . . . . . . . . . . . . 10 4.1. Symmetric Key . . . . . . . . . . . . . . . . . . . . . . 10 4.1.1. Cryptographic Digest . . . . . . . . . . . . . . . . 10 4.1.2. Message Authentication Code . . . . . . . . . . . . 10 4.1.3. Encryption . . . . . . . . . . . . . . . . . . . . . 10 4.2. Public Key . . . . . . . . . . . . . . . . . . . . . . . 10 5. Obsolete Algorithms . . . . . . . . . . . . . . . . . . . . . 11 6. Further Work . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7.1. Outdated recommendations . . . . . . . . . . . . . . . . 12 7.2. Monoculture . . . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Acnowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Hallam-Baker September 18, 2014 [Page 2] Internet-Draft Consensus Cryptographic Algorithms March 2014 1. Introduction Many IETF protocols may use of cryptographic algorithms to provide confidentiality, integrity, or non-repudiation. For the mechanisms to work properly, communicating parties must support the same cryptographic algorithm or algorithms. Yet, cryptographic algorithms become weaker with time. As new cryptanalysis techniques are developed and computing performance improves, the work factor to break a particular cryptographic algorithm will reduce. Traditionally the protocol designers have been responsible for both the implementation of a modular design that enables the use of different algorithms and the choice of the initial algorithms themselves. Changes to the set of mandatory to implement algorithms requires revision of each standard in turn. Since a cryptographic implementation is often only as secure as its weakest link, failure to update algorithm requirements consistently often means the advantage of doing so is lost. It is not the ability to use stronger algorithms that improves the strength of a solution, rather it is discontinuing the use of weak or compromised algorithms. This document describes a set of cryptographic algorithm choices that reflects current IETF consensus at the time of issue. Compliance with this document indicates that an implementation supports the use of a set of cryptographic algorithms backed by the consensus of the IETF community and does not in its default configuration support the use of previously recommended algorithms that have been found to be unsafe. 1.1. Terminology The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119] 2. Consensus Cryptographic Algorithms This document specifies three sets of cryptographic algorithms: Required Algorithms A set of algorithms that is considered to represent the best current tradeoff between security, efficiency and interoperability. Recommended Algorithms A set of 'backup' algorithms to be held in reserve in case that a required algorithm is found to be unacceptable. Hallam-Baker September 18, 2014 [Page 3] Internet-Draft Consensus Cryptographic Algorithms March 2014 Obsolete Algorithms A set of algorithms that were previously cited in IETF protocol specifications that have been found to be unsafe and unfit for purpose. An application that only supports one cryptographic algorithm is vulnerable to attack in the case that algorithm is broken. An application that suports numerous algorithm choices is only as secure as the weakest algorithm choice an attacker can impose on it. Consequently best practice for design of cryptographic protocols holds that at least one REQUIRED algorithm choice be defined to enable interoperability but that there be no more than one additional algorithm Accordingly, the Required set of algorithms contains exactly one choice for each algorithm type and the Recommended set contains at most one choice of algorithm. 2.1. Complicance Criteria Implementations that are compliant with this specification are REQUIRED to observe the following compliance criteria: * Where the protocol indicates the need for a particular type of cryptographic algorithm, the corresponding algorithm from the Required Algorithm set is REQUIRED. * Where the protocol indicates the need for a particular type of cryptographic algorithm, the corresponding algorithm from the Recommended Algorithm set is RECOMMENDED. * Implementations MUST not support or accept algorithms in the Obsolete Algorithm set except in exempt circumstances as specified in [exempt] 2.1.1. Enhanced Criteria Protocol specifications citing this document normatively MAY impose additional requirements. For example, a protocol designed for use in an embedded systems application demanding a long term service life might require implementation of algorithms in the Recomended set so as to ensure that every deployed system supported a backup algorithm. 2.1.2. Exempt circumstances Implementations MUST not support or accept algorithms in the Obsolete Algorithm set unless one of the following conditions applies: * The use of the algorithm is approved for that specific purpose in the notice declaring it to be obsolete. Hallam-Baker September 18, 2014 [Page 4] Internet-Draft Consensus Cryptographic Algorithms March 2014 * Support for the algorithm is disabled by default and can only be enabled by explicit action by a duly authorized administrator. * Support for the algorithm is limited to a fixed transition period established in the notice declaring the algorithm to be obsolete. 2.2. Selection Criteria 2.2.1. Established Consensus It is the objective of this document to follow rather than lead the development of community consensus on cryptographic algorithm choices. Accordingly the definition of the Required algorithm set follows established IETF and Industry practice and entries are only specified in the Recommended algorithm set where there is a clear and overwhelming consensus to do so. 2.2.2. Unencumbered Current industry and community practice strongly discourages the adoption of specifications that are encumbered by patent, copyright or other intellectual property claims unless there is an overwhelming functional advantage in doing so. Since unencumbered algorithm choices exist for each and every cryptographic algorithm specified in the Required set, it is hard to imagine a circumstance in which it would be to the advantage of the community to intentionally select alternatives that were subject to such claims. Accordingly, only algorithms that are believed to be free from such claims are considered eligible for selection. In the case that a party were to establish a credible intellectual property claim in one of the algorithms in the Required or Recommended set, this would constitute a valid disqualification criteria. 2.3. Disqualification Criteria Future revisions of this document may update entries in the Required and/or Recommended algorithms set as determined by IETF process and community consensus. Such updates should attempt to find a balance between the need to protect security while avoiding unnecessary impact on running code. The disqualification criteria set out here are intended to serve as a guide for such discussions rather than attempting to bind them to a particular course of action. Since the Required and Recommended Algorithm sets serve different purposes, the disqualification criteria for different for each set. Hallam-Baker September 18, 2014 [Page 5] Internet-Draft Consensus Cryptographic Algorithms March 2014 2.3.1. Algorithm Weaknesses. An algorithm is disqualified as a member of the Required set of algorithms if community consensus holds that the security of the algorithm has been substantially compromised such that an attack on the algorthm is feasible or expected to become feasible in the near future. Rationale: Since algorithns in the Required set are intended for ubiquitous use, disqualification of such algorithms represents a significant cost and is not to be considered lightly. A purely theoretical attack reducing the time complexity of breaking a 128 bit encryption algorithm to O(2^124) time with the use of 2^120 chosen plaintexts would not justify making a change. An attack that reduced the time complexity of an attack to O(2^100) would be cause for considerably greater concern. An algorithm is disqualified as a member of the Required set of algorithms if community consensus holds that the security of the algorithm has been significantly compromised. Rationale: Since algorithms in the Recommended set are intended for use as replacement algorithms in case the corresponding algorithm in the Required set are found to be weak, the algorithms selected should be beyond reasonable suspicion. 2.3.2. Intellectual Property Claim. The algorithms selected for the Required set are all based on well established technology that was not subject to patent claims or where the patent claims that existed have expired. Should a credible claim be asserted subsequently it would stand as grounds for disqualification. 2.4. Algorithm Variations 2.4.1. Cipher Modes This document does not address choice of cipher modes. The choice of cipher mode is depends on the application for which it is to be used and is therefore best considered as part of the protocol design. 2.4.2. Key Sizes Most modern cryptographic algorithms offer a range of key sizes. For example the AES standard defines 128 bit, 192 bit and 256 bit key sizes. The RSA algorithm supports arbitrary key sizes but is only considered acceptably secure for key sizes of 2048 bits or greater. Hallam-Baker September 18, 2014 [Page 6] Internet-Draft Consensus Cryptographic Algorithms March 2014 To avoid unnecessary burden on implementations, only specific key sizes are REQUIRED or RECOMMENDED. The key sizes being chosen to minimize implementation complexity. 2.4.3. Shared Parameters Most public key algorithms have a set of shared parameters that are not properly part of either the public or private key. In the RSA algorithm, the public key exponent is typically chosen to be 65,537 for efficiency but other values may be used. In the case of Diffie-Hellman key Exchange [RFC2631], the public exponent g and shared modulus p must be agreed by both parties before the public key values can be calculated. Prior agreement of a common public exponent and shared modulus permits these steps to be performed out of band and held in reserve for use when needed. Selection of shared parameter values where necessary is outside the scope of this document. Rather, such selection of values is to be determined in the separate specification describing the algorithm specification. 2.4.4. Formats Except where the choice of data format affects the security of an algorithm and is thus properly considered to be a part thereof, data formats and encodings are outside the scope of these requirements. 2.4.5. Required Algorithms 2.4.6. Recommended Algorithms The purpose of the recommended algorithms is to provide a backup in case the required algorithm is found to be weak. Accodingly: * There should be a high degree of confidence that a weakness affecting the required algorithm should not affect the recommended algorithm * Where possible, recommended algorithms should be the consensus choice of successor algorithm. * Recommended algorithms should be chosen for security over speed. Hallam-Baker September 18, 2014 [Page 7] Internet-Draft Consensus Cryptographic Algorithms March 2014 3. Required Algorithms 3.1. Symmetric Key 3.1.1. Cryptographic Digest REQUIRED: SHA2 256 [RFC6234] RECOMMENDED: SHA2 512 [RFC6234] Rationale: Although the SHA3 algorithms are believed to be superior in strength, no IETF specifications currently mandate implementation and to do so here would be to attempt to lead rather than follow consensus. Further, the choice of SHA2 as required leaves SHA3 for use as a reserve algorithm which would otherwise be empty. 3.1.2. Message Authentication Code REQUIRED: HMAC-SHA-256-128 [RFC4868] RECOMMENDED: AES-128-CCM [RFC3610] According to current practice, Message Authentication Codes (MAC) are currently implemented as a mode of use of either a cryptographic digest or an encryption algorithm. While this approach reduces the number of cryptographic algorithms that an implementation is required to support, such constructions must be considered as separate and independent algorithms for the purpose of evaluating security. In theory an algorithm constructed in this fashion may become vulnerable to attack due to a weakness of either the base algorithm or the mode of use. 3.1.3. Encryption REQUIRED: AES 128 bit RECOMMENDED: AES 256 bit Rationale: AES is the de-facto industry standard encryption algorithm. In addition to being widely used in applications, many CPUs provide support for AES in dedicated or optimized hardware. AES emerged from an open competition in which the process and execution were commonly agreed to be open and fair. Although AES specifies three key sizes, the 128 bit key size should be sufficient for any purpose unless either a weakness is discovered in the algorithm itself or a new form of computing principle is discovered that permits faster attacks. The Hallam-Baker September 18, 2014 [Page 8] Internet-Draft Consensus Cryptographic Algorithms March 2014 3.2. Public Key Three types of public key algorithm are defined: * Ephemeral Key Agreement. * Public Key Encryption / Key Agreement under long term key * Digital Signature. For performance and security reasons, the use of public key encryption is almost invariably restricted to key agreement in Internet protocols: A symmetric key is randomly generated and encrypted under the public encryption key of the intended recipient. While the Diffie-Hellman and RSA algorithms are both capable of supporting key agreement, the practice has arisen that the RSA encryption algorithm is used in cases where a key is to be published or endorsed in some form of PKI and use of the Diffie-Hellman algorithm is limited to ephemeral key exchange where the ability to generate new public keypairs rapidly is a requirement. 3.2.1. Ephemeral Key Agreement REQUIRED: Diffie-Hellman key exchange as described in [RFC2631]. Rationale: Diffie-Helleman is the currently the consensus choic of key exchange algorithm in applications where rapid generation of key pairs is desirable. Unlike RSA which requires a search for two large primes, generation of Diffie Hellman keys only requires a large random number. 3.2.2. Public Key Encryption REQUIRED: RSA Public Key Encryption as described in [RFC3447]. Implementations MUST support RSA Public Encryption key sizes of 2048 and 4096 bits. Implementations MUST NOT accept key sizes of less than 2048 bits Note 1: Following industry practice, an RSA modulus is considered to be a '2048 bit' key size provided that it is greater than 2^2046. Rationale: RSA is the industry standard choice for non-emphemeral key exchange. While the use in Internet protocols is almost exclusively for key exchange as opposed to encryption of data, longstanding practice is to distinguish these uses. Hallam-Baker September 18, 2014 [Page 9] Internet-Draft Consensus Cryptographic Algorithms March 2014 3.2.3. Digital Signature REQUIRED: RSA Public Key Signature as described in [RFC3447]. Implementations MUST support RSA Digital Signature key sizes of 2048 and 4096 bits. Implementations MUST NOT accept key sizes of less than 2048 bits Note 1: Following industry practice, an RSA modulus is considered to be a '2048 bit' key size provided that it is greater than 2^2046. 4. Recommended Algorithms While there is a strong consensus in favor of a Required set of algorithms, no such consensus currently supports the selection of Recommended algorithms except in the case of Cryptographic Digests. 4.1. Symmetric Key 4.1.1. Cryptographic Digest RECOMMENDED: SHA-3 Rationale 4.1.2. Message Authentication Code RECOMMENDED: HMAC-SHA3 The 4.1.3. Encryption No Reccomendation. One of the chief advantages of using AES is that many commodity CPU devices provide support for AES in dedicated circuits or circuits optimized for AES use. As a result the best alternative to use of AES-128 today is to use the AES-256 which requires more rounds of processing in addition to the larger key size. 4.2. Public Key No Reccomendation. Although developments in cryptanalysis of public key cryptographic algorithms strongly suggest that there is an urgent need to specify an alternative to algorithms such as RSA and Diffie-Hellman based on the discrete log problem, there is currently no clear consensus on a single successor. Hallam-Baker September 18, 2014 [Page 10] Internet-Draft Consensus Cryptographic Algorithms March 2014 Although it is generally agreed that Elliptic Curve algorithms provide the strongest contenders for replacement algorithms, recent events have cast doubt on the choice of parameters. 5. Obsolete Algorithms On publication of this document as an RFC, IANA shall create a registry of Obsolete cryptographic algorithms containing the following information. The IANA policy RFC Required shall apply to creation of new entries in the registry. The set of obsolete algorithms SHALL be the set of algorithms listed in the registry created. To avoid the implication that algorithms not listed as obsolete are to be considered 'safe', only algorithms that have been previously published as an RFC or approved for use as a strong cryptographic algorithm in a document previously published as an RFC are eligible for inclusion. For example, MD4 is eligible for inclusion as it is described in [RFC1320]. Algorithm Identifier The commonly used abbreviation of the obsolete algorithm. Long Name The long name of the obsolete algorithm. Document RFC in which the algorithm is declared obsolete. For example, by moving the original specification of the algorithm to HISTORIC status. 6. Further Work As noted previously, best practice for implementation of cryptographic applications strongly encourages support for a reserve or backup algorithm as a transition plan in case the mandatory to implement choice should be found to be defective. With the exception of cryptographi digests however, no existing algorithms can claim the backing of a strong community consensus. Work on building such consensus is thus clearly advised. Public Key algorithms, the area in which immediate attention is generally considered to be most needed is fortunately the area in which prospects for short term success are greatest. While there is a strong consensus that Elliptic Curve cryptography [RFC6090] provides the best alternative to discrete logarithm problems, recent events have cast doubt over proposals to use specific shared parameters. Hallam-Baker September 18, 2014 [Page 11] Internet-Draft Consensus Cryptographic Algorithms March 2014 For the limited purpose of defining a reserve algorithm set it is sufficient to either limit the recommendation to implementation of an algorithm alone, to select a set of curves that are known to be free of backdoors or to generate a completely new set of curves under controlled conditions. Definition of an alternative encryption algorithm presents a greater challenge. If the need for a substitute algorithm suddenly became urgent, one of the runners-up in the AES competition might be chosen as an expedient choice. But absent such circumstances, it is highly unlikely that consensus could be reached on an AES alternative unless the choice was made through a similarly open competition based process. 7. Security Considerations Since this whole document is about security, the focus of the security considerations is properly the risks created by the document itself. 7.1. Outdated recommendations Algorithms within the Required or Recommended set may become vulnerable to attack without updated recomendations being issued. 7.2. Monoculture Adopting a single set of Required and Recommended algorithms may result in an algorithm monoculture such that new algorithms are unable to become established. One of the main reasons for not completing the set of recommended algorithms for the sake of completeness is to identify areas where additional algorithm choices are required and a consensus building effort is needed. 8. IANA Considerations Create a registry of obsolete algorithms. 9. Acnowledgements 10. References 10.1. Normative References [RFC4868] Kelly, S.,Frankel, S., "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. Hallam-Baker September 18, 2014 [Page 12] Internet-Draft Consensus Cryptographic Algorithms March 2014 [RFC3610] Whiting, D.,Housley, R.,Ferguson, N., "Counter with CBC- MAC (CCM)", RFC 3610, September 2003. [RFC3447] Jonsson, J.,Kaliski, B., "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999. [RFC6234] Eastlake, D.,Hansen, T., "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 10.2. Informative References [RFC6090] McGrew, D.,Igoe, K.,Salter, M., "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011. [RFC1320] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320, April 1992. Author's Address Phillip Hallam-Baker Comodo Group Inc. philliph@comodo.com Hallam-Baker September 18, 2014 [Page 13]