| Network Working Group | P. Hallam-Baker |
| Internet-Draft | Comodo Group Inc. |
| Expires: April 30, 2015 | October 27, 2014 |
Consensus Cryptographic Algorithms
draft-hallambaker-consensuscrypto-01
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.
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 April 30, 2015.
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.
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.
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]
This document specifies three sets of cryptographic algorithms:
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.
Implementations that are compliant with this specification are REQUIRED to observe the following compliance 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.
Implementations MUST not support or accept algorithms in the Obsolete Algorithm set unless one of the following conditions applies:
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.
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.
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.
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.
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.
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.
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.
To avoid unnecessary burden on implementations, only specific key sizes are REQUIRED or RECOMMENDED. The key sizes being chosen to minimize implementation complexity.
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.
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.
The purpose of the recommended algorithms is to provide a backup in case the required algorithm is found to be weak. Accodingly:
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.
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.
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
Three types of public key algorithm are defined:
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.
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.
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.
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.
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.
RECOMMENDED: SHA-3
Rationale
RECOMMENDED: HMAC-SHA3
The
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.
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.
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.
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].
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.
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.
Since this whole document is about security, the focus of the security considerations is properly the risks created by the document itself.
Algorithms within the Required or Recommended set may become vulnerable to attack without updated recomendations being issued.
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.
Create a registry of obsolete algorithms.
| [RFC4868] | Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. |
| [RFC3610] | Whiting, D., Housley, R. and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, September 2003. |
| [RFC3447] | Jonsson, J. and B. Kaliski, "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. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. |
| [RFC6090] | McGrew, D., Igoe, K. and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011. |
| [RFC1320] | Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320, April 1992. |