Internet Engineering Task Force (IETF) Phillip Hallam-Baker
Internet-Draft Comodo Group Inc.
Intended Status: Standards Track October 27, 2014
Expires: April 30, 2015
Consensus Cryptographic Algorithms
draft-hallambaker-consensuscrypto-01
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 April 30, 2015 [Page 1]
Internet-Draft Consensus Cryptographic Algorithms October 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 April 30, 2015 [Page 2]
Internet-Draft Consensus Cryptographic Algorithms October 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 April 30, 2015 [Page 3]
Internet-Draft Consensus Cryptographic Algorithms October 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 April 30, 2015 [Page 4]
Internet-Draft Consensus Cryptographic Algorithms October 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 April 30, 2015 [Page 5]
Internet-Draft Consensus Cryptographic Algorithms October 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 April 30, 2015 [Page 6]
Internet-Draft Consensus Cryptographic Algorithms October 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 April 30, 2015 [Page 7]
Internet-Draft Consensus Cryptographic Algorithms October 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 April 30, 2015 [Page 8]
Internet-Draft Consensus Cryptographic Algorithms October 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 April 30, 2015 [Page 9]
Internet-Draft Consensus Cryptographic Algorithms October 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 April 30, 2015 [Page 10]
Internet-Draft Consensus Cryptographic Algorithms October 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 April 30, 2015 [Page 11]
Internet-Draft Consensus Cryptographic Algorithms October 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 April 30, 2015 [Page 12]
Internet-Draft Consensus Cryptographic Algorithms October 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 April 30, 2015 [Page 13]