< draft-iab-crypto-alg-agility-05.txt   draft-iab-crypto-alg-agility-06.txt >
Internet-Draft R. Housley Internet-Draft R. Housley
Intended Status: Best Current Practice Vigil Security Intended Status: Best Current Practice Vigil Security
Expires: 6 December 2015 4 June 2015 Expires: 8 January 2016 7 July 2015
Guidelines for Cryptographic Algorithm Agility Guidelines for Cryptographic Algorithm Agility
and Selecting Mandatory-to-Implement Algorithms and Selecting Mandatory-to-Implement Algorithms
<draft-iab-crypto-alg-agility-05.txt> <draft-iab-crypto-alg-agility-06.txt>
Abstract Abstract
Many IETF protocols use cryptographic algorithms to provide Many IETF protocols use cryptographic algorithms to provide
confidentiality, integrity, authentication or digital signature. confidentiality, integrity, authentication or digital signature.
Communicating peers must support a common set of cryptographic Communicating peers must support a common set of cryptographic
algorithms for these mechanisms to work properly. This memo provides algorithms for these mechanisms to work properly. This memo provides
guidelines to ensure that protocols have the ability to migrate from guidelines to ensure that protocols have the ability to migrate from
one mandatory-to-implement algorithm suite to another over time. one mandatory-to-implement algorithm suite to another over time.
skipping to change at page 2, line 15 skipping to change at page 2, line 15
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
0. TO DO
Three comments have not been resolved yet ...
(1) There is a minor organizational issue. It looks like part of
Section 3 could be merged with Section 2. (I got initially confused
by some ambiguous advice in 2.1 that was cleared up in 3.1). Some of
Section 3 belongs with the text in Section 4. Specifically, 3.3 is
really tied quite closely to 4.2, 4.3, and 4.4.
(2) Nowhere does the document discuss directly the problem of long-
term signatures in certificates hindering the dropping of weak
signature algorithms and key lengths, even though this is an example
that many people are familiar with. If a CA signed a long-term cert
with a signature using RSA-MD5, you can't easily drop MD5 support,
you have to try to use it only in the exactly right places, which
leads to errors.
(3) The note in Section 3.2 on Performance belongs elsewhere, likely
in the section on strength.
1. Introduction 1. Introduction
Many IETF protocols use cryptographic algorithms to provide Many IETF protocols use cryptographic algorithms to provide
confidentiality, integrity, authentication, or digital signature. confidentiality, integrity, authentication, or digital signature.
For interoperability, communicating peers must support a common set For interoperability, communicating peers must support a common set
of cryptographic algorithms. In most cases, a combination of of cryptographic algorithms. In most cases, a combination of
compatible cryptographic algorithms will be used to provide the compatible cryptographic algorithms will be used to provide the
desired security services. The set of cryptographic algorithms being desired security services. The set of cryptographic algorithms being
used at a particular time is often referred to as a cryptographic used at a particular time is often referred to as a cryptographic
algorithm suite or cipher suite. In a protocol, algorithm algorithm suite or cipher suite. In a protocol, algorithm
identifiers might name a single cryptographic algorithm or a full identifiers might name a single cryptographic algorithm or a full
suite of algorithms. suite of algorithms.
Cryptographic algorithms age; they become weaker with time. As new Cryptographic algorithms age; they become weaker with time. As new
cryptanalysis techniques are developed and computing capabilities cryptanalysis techniques are developed and computing capabilities
improve, the work factor to break a particular cryptographic improve, the work factor to break a particular cryptographic
algorithm will reduce or become more feasible for more attackers. algorithm will reduce, becoming more feasible for more attackers.
Advances in computing power available to the attacker will eventually
make any algorithm obsolete. For this reason, protocols need
mechanisms to migrate from one algorithm suite to another over time.
Algorithm agility is achieved when a protocol can easily migrate from Algorithm agility is achieved when a protocol can easily migrate from
one algorithm suite to another more desirable one, over time. For one algorithm suite to another more desirable one, over time. For
the protocol implementer, this means that implementations should be the protocol implementer, this means that implementations should be
modular to easily accommodate the insertion of new algorithms or modular to easily accommodate the insertion of new algorithms or
suites of algorithms. Ideally, implementations will also provide a suites of algorithms. Ideally, implementations will also provide a
way to measure when deployed implementations have shifted away from way to measure when deployed implementations have shifted away from
the old algorithms and to the better ones. For the protocol the old algorithms and to the better ones. For the protocol
designer, algorithm agility means that one or more algorithm designer, algorithm agility means that one or more algorithm
identifier must be supported, the set of mandatory-to-implement identifier must be supported, the set of mandatory-to-implement
skipping to change at page 3, line 40 skipping to change at page 3, line 22
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Algorithm Agility Guidelines 2. Algorithm Agility Guidelines
These guidelines are for use by IETF working groups and protocol These guidelines are for use by IETF working groups and protocol
authors for IETF protocols that make use of cryptographic algorithms. authors for IETF protocols that make use of cryptographic algorithms.
Past attempts at algorithm agility have not been completely
successful, and this section provides some insights from those
experiences.
2.1. Algorithm Identifiers 2.1. Algorithm Identifiers
IETF protocols that make use of cryptographic algorithms MUST support IETF protocols that make use of cryptographic algorithms MUST support
one or more algorithm or suite identifier. The identifier might be one or more algorithm or suite identifier. The identifier might be
explicitly carried in the protocol. Alternatively, it can configured explicitly carried in the protocol. Alternatively, it can configured
by a management mechanism. For example, an entry in a key table that by a management mechanism. For example, an entry in a key table that
includes a key value and an algorithm identifier might be sufficient. includes a key value and an algorithm identifier might be sufficient.
If a protocol does not carry an algorithm identifier, then the
protocol version number or some other major change is needed to
transition from one algorithm to another. The inclusion of an
algorithm identifier is a minimal step toward cryptographic algorithm
agility.
Sometimes a combination of protocol version number and explicit
algorithm or suite identifiers is appropriate. For example, the TLS
[RFC5246] version number names the default key derivation function
and the cipher suite identifier names the rest of the needed
algorithms.
Some approaches carry one identifier for each algorithm that is used. Some approaches carry one identifier for each algorithm that is used.
Other approaches carry one identifier for a full suite of algorithms. Other approaches carry one identifier for a full suite of algorithms.
Both approaches are used in IETF protocols. Designers are encouraged Both approaches are used in IETF protocols. Designers are encouraged
to pick one of these approaches and use it consistently throughout to pick one of these approaches and use it consistently throughout
the protocol or family of protocols. Suite identifiers make it the protocol or family of protocols. Suite identifiers make it
easier for the protocol designer to ensure that the algorithm easier for the protocol designer to ensure that the algorithm
selections are complete and compatible for future assignments. selections are complete and compatible for future assignments.
However, suite identifiers inherently face a combinatoric explosion However, suite identifiers inherently face a combinatoric explosion
as new algorithms are defined. Algorithm identifiers, on the other as new algorithms are defined. Algorithm identifiers, on the other
hand, impose a burden on implementations by forcing a determination hand, impose a burden on implementations by forcing a determination
skipping to change at page 4, line 35 skipping to change at page 4, line 33
mark a registry entry as deprecated when implementation is no longer mark a registry entry as deprecated when implementation is no longer
advisable. advisable.
2.2. Mandatory-to-Implement Algorithms 2.2. Mandatory-to-Implement Algorithms
For secure interoperability, BCP 61 [RFC3365] recognizes that For secure interoperability, BCP 61 [RFC3365] recognizes that
communicating peers that use cryptographic mechanisms must support a communicating peers that use cryptographic mechanisms must support a
common set of strong cryptographic algorithms. For this reason, the common set of strong cryptographic algorithms. For this reason, the
protocol MUST specify one or more strong mandatory-to-implement protocol MUST specify one or more strong mandatory-to-implement
algorithm or suite. This does not require all deployments to use algorithm or suite. This does not require all deployments to use
this algorithm or suite, but it does require that are available to this algorithm or suite, but it does require that it be available to
all deployments. all deployments.
The IETF needs to be able to change the mandatory-to-implement The IETF needs to be able to change the mandatory-to-implement
algorithms over time. It is highly desirable to make this change algorithms over time. It is highly desirable to make this change
without updating the base protocol specification. To achieve this without updating the base protocol specification. To achieve this
goal, the base protocol specification includes a reference to a goal, the base protocol specification includes a reference to a
companion algorithms document, allowing the update of one document companion algorithms document, allowing the update of one document
without necessarily requiring an update to the other. This division without necessarily requiring an update to the other. This division
also facilitates the advancement of the base protocol specification also facilitates the advancement of the base protocol specification
on the standards maturity ladder even if the algorithm document on the standards maturity ladder even if the algorithm document
skipping to change at page 5, line 33 skipping to change at page 5, line 33
the specific key sizes and parameter sizes that are to be supported. the specific key sizes and parameter sizes that are to be supported.
When more than one key size is available, expect the mandatory-to- When more than one key size is available, expect the mandatory-to-
implement key size to increase over time. implement key size to increase over time.
Guidance on cryptographic key size for asymmetric keys can be found Guidance on cryptographic key size for asymmetric keys can be found
in BCP 86 [RFC3766]. in BCP 86 [RFC3766].
Guidance on cryptographic key size for symmetric keys can be found in Guidance on cryptographic key size for symmetric keys can be found in
BCP 195 [RFC7525]. BCP 195 [RFC7525].
2.2.3. Providing Notice of Expected Changes
Fortunately, catastrophic algorithm failures without warning are
rare. More often, algorithm transition is the result of age. For
example, the transition from DES to Triple-DES to AES took place over
decades, causing a shift in symmetric block cipher strength from 56
bits to 112 bits to 128 bits. Where possible, authors SHOULD provide
notice to implementers about expected algorithm transitions. One
approach that was first used in RFC 4307 [RFC4307] is to use SHOULD+,
SHOULD-, and MUST- in the specification of algorithms.
SHOULD+ This term means the same as SHOULD. However, it is
likely that an algorithm marked as SHOULD+ will be
promoted to a MUST in the future.
SHOULD- This term means the same as SHOULD. However, it is
likely that an algorithm marked as SHOULD- will be
deprecated to a MAY or worse in the future.
MUST- This term means the same as MUST. However, it is
expected that an algorithm marked as MUST- will be
downgraded in the future. Although the status of the
algorithm will be determined at a later time, it is
reasonable to expect that a the status of a MUST-
algorithm will remain at least a SHOULD or a SHOULD-.
2.3. Transition from Weak Algorithms 2.3. Transition from Weak Algorithms
Transition from an old algorithm that is found to be weak can be Transition from an old algorithm that is found to be weak can be
tricky. It is of course straightforward to specify the use of a new, tricky. It is of course straightforward to specify the use of a new,
better algorithm. And then, when the new algorithm is widely better algorithm. And then, when the new algorithm is widely
deployed, the old algorithm ought no longer be used. However, deployed, the old algorithm ought no longer be used. However,
knowledge about the implementation and deployment of the new knowledge about the implementation and deployment of the new
algorithm will always be imperfect, so one cannot be completely algorithm will always be imperfect, so one cannot be completely
assured of interoperability with the new algorithm. assured of interoperability with the new algorithm.
skipping to change at page 6, line 24 skipping to change at page 7, line 5
cryptographic algorithm suite. In such situations, the protection cryptographic algorithm suite. In such situations, the protection
offered by the algorithm is severely compromised, perhaps to the offered by the algorithm is severely compromised, perhaps to the
point that one wants to stop using the weak suite altogether, point that one wants to stop using the weak suite altogether,
rejecting offers to use the weak suite well before the new suite is rejecting offers to use the weak suite well before the new suite is
widely deployed. widely deployed.
In any case, there comes a point in time where one refuses to use the In any case, there comes a point in time where one refuses to use the
old, weak algorithm or suite. This can happen on a flag day, or each old, weak algorithm or suite. This can happen on a flag day, or each
installation can select a date on their own. installation can select a date on their own.
2.4. Balance Security Strength 2.4. Algorithm Transition Mechanisms
When selecting or negotiating a suite of cryptographic algorithms,
the strength of each algorithm SHOULD be considered. The algorithms
in a suite SHOULD be roughly equal; however, the security service
provided by each algorithm in a particular context needs to be
considered in making the selection. Algorithm strength needs to be
considered at the time a protocol is designed. It also needs to be
considered at the time a protocol implementation is deployed and
configured. Advice from from experts is useful, but in reality, it
is not often available to system administrators that are deploying
and configuring a protocol implementation. For this reason, protocol
designers SHOULD provide clear guidance to implementors, leading to
balanced options being available at the time of deployment and
configuration.
Some algorithms offer flexibility in their strength by adjusting the
key size, number of rounds, authentication tag size, prime group
size, and so on. For example, cipher suites include Diffie-Hellman
or RSA without specifying a particular public key length. If the
algorithm identifier or suite identifier named a particular public
key length, migration to longer ones would be more difficult. On the
other hand, inclusion of a public key length would make it easier to
migrate away from short ones when computational resources available
to attacker dictate the need to do so. Therefore, flexibility on
asymmetric key length is both desirable and undesirable at the same
time.
In CMS [RFC5652], a previously distributed symmetric key-encryption
key can be used to encrypt a content-encryption key, which is in turn
used to encrypt the content. The key-encryption and content-
encryption algorithms are often different. If, for example, a
message content is encrypted with 128-bit AES key and the content-
encryption key is wrapped with a 256-bit AES key, then at most 128
bits of protection is provided. In this situation, the algorithm and
key size selections should ensure that the key encryption is at least
as strong as the content encryption. In general, wrapping one key
with another key of a different size yields the security strength of
the shorter key.
2.5. Opportunistic Security
Despite the guidance in Section 2.4, opportunistic security [RFC7435]
SHOULD also be considered, especially at the time a protocol
implementation is deployed and configured. Using algorithms that are
weak against advanced attackers but sufficient against others is a
way to make pervasive surveillance significantly more difficult. As
a result, algorithms that would not be acceptable in many negotiated
situations are acceptable for opportunistic security. Similarly,
weaker algorithms and shorter key sizes are also acceptable for
opportunistic security. That said, the use of strong algorithms is
always preferable.
3. Algorithm Agility in Protocol Design
Some attempts at algorithm agility have not been completely
successful. This section provides some of the insights based on
protocol designs and deployments.
3.1. Algorithm Identifiers
If a protocol does not carry an algorithm identifier, then the
protocol version number or some other major change is needed to
transition from one algorithm to another. The inclusion of an
algorithm identifier is a minimal step toward cryptographic algorithm
agility. In addition, an IANA registry is needed to pair the
identifier with an algorithm specification.
Sometimes a combination of protocol version number and explicit
algorithm or suite identifiers is appropriate. For example, the TLS
version number names the default key derivation function and the
cipher suite identifier names the rest of the needed algorithms.
Sometimes application layer protocols can make use of transport layer
security protocols, such as TLS or DTLS. This insulates the
application layer protocol from the details of cryptography, but it
is likely to still be necessary to handle the transition from
unprotected traffic to protected traffic in the application layer
protocol. In addition, the application layer protocol may need to
handle the downgrade from encrypted communication to plaintext
communication.
3.2. Migration Mechanisms
Cryptographic algorithm selection or negotiation SHOULD be integrity Cryptographic algorithm selection or negotiation SHOULD be integrity
protected. If selection is not integrity protected, then the protected. If selection is not integrity protected, then the
protocol will be subject to a downgrade attack. Without integrity protocol will be subject to a downgrade attack. Without integrity
protection of algorithm or suite selection, the attempt to transition protection of algorithm or suite selection, the attempt to transition
to a new algorithm or suite may introduce new opportunities for to a new algorithm or suite may introduce new opportunities for
downgrade attack. downgrade attack.
Transition mechanisms SHOULD consider the algorithm that is used to
provide integrity protection for algorithm negotiation itself.
If a protocol specifies a single mandatory-to-implement integrity If a protocol specifies a single mandatory-to-implement integrity
algorithm, eventually that algorithm will be found to be weak. algorithm, eventually that algorithm will be found to be weak.
Extra care is needed when a mandatory-to-implement algorithm is used Extra care is needed when a mandatory-to-implement algorithm is used
to provide integrity protection for the negotiation of other to provide integrity protection for the negotiation of other
cryptographic algorithms. In this situation, a flaw in the cryptographic algorithms. In this situation, a flaw in the
mandatory-to-implement algorithm may allow an attacker to influence mandatory-to-implement algorithm may allow an attacker to influence
the choices of the other algorithms. the choices of the other algorithms.
Performance is always a factor is selecting cryptographic algorithms. 2.5. Cryptographic Key Management
In many algorithms, shorter keys offer higher performance, but less
security. Performance and security need to be balanced. Yet, all
algorithms age, and the advances in computing power available to the
attacker will eventually make any algorithm obsolete. For this
reason, protocols need mechanisms to migrate from one algorithm suite
to another over time, including the algorithm used to provide
integrity protection for algorithm negotiation.
3.3. Preserving Interoperability Traditionally, protocol designers have avoided more than one approach
to key management because it makes the security analysis of the
overall protocol more difficult. When frameworks such as EAP and
GSSAPI are employed, the key management is very flexible, often
hiding many of the details from the application. This results in
protocols that support multiple key management approaches. In fact,
the key management approach itself may be negotiable, which creates a
design challenge to protect the negotiation of the key management
approach before it is used to produce cryptographic keys.
Protocols can negotiate a key management approach, derive an initial
cryptographic key, and then authenticate the negotiation. However,
if the authentication fails, the only recourse is to start the
negotiation over from the beginning.
Some environments will restrict the key management approaches by
policy. Such policies tend to improve interoperability within a
particular environment, but they cause problems for individuals that
need to work in multiple incompatible environments.
2.6. Preserving Interoperability
Cryptographic algorithm deprecation is very hard. People do not like Cryptographic algorithm deprecation is very hard. People do not like
to introduce interoperability problems, even to preserve security. to introduce interoperability problems, even to preserve security.
As a result, flawed algorithms are supported for far too long. The As a result, flawed algorithms are supported for far too long. The
impacts of legacy software an long support tails on security can be impacts of legacy software an long support tails on security can be
reduced by making it easy to rollover from old algorithms and suites reduced by making it easy to rollover from old algorithms and suites
to new ones. to new ones.
Without clear mechanisms for algorithm and suite rollover, preserving Without clear mechanisms for algorithm and suite rollover, preserving
interoperability becomes a difficult social problem. For example, interoperability becomes a difficult social problem. For example,
consider web browsers. Dropping support for an algorithm suite can consider web browsers. Dropping support for an algorithm suite can
break connectivity to some web sites because, and the browser will break connectivity to some web sites, and the browser vendor will
lose users by doing so. This situation creates incentives to support lose users by doing so. This situation creates incentives to support
algorithm suites that would otherwise be deprecated, but preserving algorithm suites that would otherwise be deprecated, but preserving
interoperability. interoperability.
Transition in Internet infrastructure is particularly difficult. The
digital signature on a trust anchor certificate [RFC5280] is often
expected to last decades, which hinders the transition away from a
weak signature algorithm or short key length. Once a long-lived
certificate is issued with a particular signature algorithm, that
algorithm will be used by many relying parties, and none of them can
stop supporting it without invalidating all of the subordinate
certificates. In a hierarchal system, many subordinate certificates
could be impacted by the decision to drop support for a weak
signature algorithm or an associated hash function.
Institutions, being large or dominate users within a large user base, Institutions, being large or dominate users within a large user base,
can assist by coordinating the demise of an algorithm suite, making can assist by coordinating the demise of an algorithm suite, making
the rollover easier for their own users as well as others. the rollover easier for their own users as well as others.
3.4. Cryptographic Key Management 2.7. Balance Security Strength
Traditionally, protocol designers have avoided more than one approach When selecting or negotiating a suite of cryptographic algorithms,
to key management because it makes the security analysis of the the strength of each algorithm SHOULD be considered. The algorithms
overall protocol more difficult. When frameworks such as EAP and in a suite SHOULD be roughly equal; however, the security service
GSSAPI are employed, the key management is very flexible, often provided by each algorithm in a particular context needs to be
hiding many of the details from the application. This results in considered in making the selection. Algorithm strength needs to be
protocols that support multiple key management approaches. In fact, considered at the time a protocol is designed. It also needs to be
the key management approach itself may be negotiable, which creates a considered at the time a protocol implementation is deployed and
design challenge to protect the negotiation of the key management configured. Advice from from experts is useful, but in reality, such
approach before it is used to produce cryptographic keys. advice is often unavailable to system administrators that are
deploying and configuring a protocol implementation. For this
reason, protocol designers SHOULD provide clear guidance to
implementors, leading to balanced options being available at the time
of deployment and configuration.
Protocols can negotiate a key management approach, derive an initial Performance is always a factor is selecting cryptographic algorithms.
cryptographic key, and then authenticate the negotiation. However, Performance and security need to be balanced. Some algorithms offer
if the authentication fails, the only recourse is to start the flexibility in their strength by adjusting the key size, number of
negotiation over from the beginning. rounds, authentication tag size, prime group size, and so on. For
example, cipher suites include Diffie-Hellman or RSA without
specifying a particular public key length. If the algorithm
identifier or suite identifier named a particular public key length,
migration to longer ones would be more difficult. On the other hand,
inclusion of a public key length would make it easier to migrate away
from short ones when computational resources available to attacker
dictate the need to do so. Therefore, flexibility on asymmetric key
length is both desirable and undesirable at the same time.
Some environments will restrict the key management approaches by In CMS [RFC5652], a previously distributed symmetric key-encryption
policy. Such policies tend to improve interoperability within a key can be used to encrypt a content-encryption key, which is in turn
particular environment, but they cause problems for individuals that used to encrypt the content. The key-encryption and content-
need to work in multiple incompatible environments. encryption algorithms are often different. If, for example, a
message content is encrypted with 128-bit AES key and the content-
encryption key is wrapped with a 256-bit AES key, then at most 128
bits of protection is provided. In this situation, the algorithm and
key size selections should ensure that the key encryption is at least
as strong as the content encryption. In general, wrapping one key
with another key of a different size yields the security strength of
the shorter key.
4. Cryptographic Algorithm Specifications 2.8. Balance Protocol Complexity
Protocol designers MUST be prepared for the supported cryptographic
algorithm set to change over time. There is a spectrum of ways to
enable the transition, and Section 3 discusses dome of the related
issues.
Keep implementations as simple as possible. Complex protocol
negotiation provides opportunities for attack, such as downgrade
attacks. Support for many algorithm alternatives is also harmful.
Both of these can lead to portions of the implementation that are
rarely used, increasing the opportunity for undiscovered exploitable
implementation bugs.
2.9. Opportunistic Security
Despite the guidance in Section 2.4, opportunistic security [RFC7435]
SHOULD also be considered, especially at the time a protocol
implementation is deployed and configured. Using algorithms that are
weak against advanced attackers but sufficient against others is a
way to make pervasive surveillance significantly more difficult. As
a result, algorithms that would not be acceptable in many negotiated
situations are acceptable for opportunistic security. Similarly,
weaker algorithms and shorter key sizes are also acceptable for
opportunistic security. That said, the use of strong algorithms is
always preferable.
3. Cryptographic Algorithm Specifications
There are tradeoffs between the number of cryptographic algorithms There are tradeoffs between the number of cryptographic algorithms
that are supported, time to deploy a new algorithm, and protocol that are supported and the time to deploy a new algorithm. This
complexity. This section provides some of the insights about the section provides some of the insights about the tradeoff faced by
tradeoff faced by protocol designers. protocol designers.
Ideally, two independent sets of mandatory-to-implement algorithms Ideally, two independent sets of mandatory-to-implement algorithms
will be specified, allowing for a primary suite and a secondary will be specified, allowing for a primary suite and a secondary
suite. This approach ensures that the secondary suite is widely suite. This approach ensures that the secondary suite is widely
deployed if a flaw is found in the primary one. deployed if a flaw is found in the primary one.
4.1. Choosing Mandatory-to-Implement Algorithms 3.1. Choosing Mandatory-to-Implement Algorithms
It seems like the ability to use an algorithm of one's own choosing It seems like the ability to use an algorithm of one's own choosing
is very desirable; however, the selection is often better left to is very desirable; however, the selection is often better left to
experts. Further, any and all cryptographic algorithm choices ought experts. Further, any and all cryptographic algorithm choices ought
not be available in every implementation. Mandatory-to-implement not be available in every implementation. Mandatory-to-implement
algorithms ought to have a public stable specification and public algorithms ought to have a public stable specification and public
documentation that it has been well studied, giving rise to documentation that it has been well studied, giving rise to
significant confidence. The IETF has alway had a preference for significant confidence. The IETF has alway had a preference for
unencumbered algorithms. There are significant benefits in selecting unencumbered algorithms. There are significant benefits in selecting
algorithms and suites that are widely deployed. The selected algorithms and suites that are widely deployed. The selected
algorithms need to be resistant to side-channel attacks as well as algorithms need to be resistant to side-channel attacks as well as
meeting the performance, power, and code size requirements on a wide meeting the performance, power, and code size requirements on a wide
variety of platforms. In addition, inclusion of too many variety of platforms. In addition, inclusion of too many
alternatives may add complexity to algorithm selection or alternatives may add complexity to algorithm selection or
negotiation. negotiation.
Section 4.1 neglects to mention the obvious benefit in selecting There is significant benefit in selecting the same algorithms and
something that lots of other people are using too. That's a non- suites for different protocols. Using the same algorithms can
trivial advantage over and above the reasons cited (though many of simplify implementation when more than one of the protocols is used
them might be considered different ways of saying the same thing). in the same device or system.
Sometime more than one mandatory-to-implement algorithm is needed to Sometime more than one mandatory-to-implement algorithm is needed to
increase the likelihood of interoperability among a diverse increase the likelihood of interoperability among a diverse
population. For example, authenticated encryption is provided by population. For example, authenticated encryption is provided by
AES-CCM [RFC3610] and AES-GCM [GCM]. Both of these algorithms are AES-CCM [RFC3610] and AES-GCM [GCM]. Both of these algorithms are
considered to be secure. AES-CCM is available in hardware used by considered to be secure. AES-CCM is available in hardware used by
many small devices, and AES-GCM is parallelizable and well suited many small devices, and AES-GCM is parallelizable and well suited
high-speed devices. Therefore an application needing authenticated high-speed devices. Therefore an application needing authenticated
encryption might specify one of these algorithms or both of these encryption might specify one of these algorithms or both of these
algorithms, depending of the population. algorithms, depending of the population.
4.2. Too Many Choices Can Be Harmful 3.2. Too Many Choices Can Be Harmful
It is fairly easy to specify the use of any arbitrary cryptographic It is fairly easy to specify the use of any arbitrary cryptographic
algorithm, and once the specification is available, the algorithm algorithm, and once the specification is available, the algorithm
gets implemented and deployed. Some people say that the freedom to gets implemented and deployed. Some people say that the freedom to
specify algorithms independently from the rest of the protocol has specify algorithms independently from the rest of the protocol has
lead to the specification of too many cryptographic algorithms. Once lead to the specification of too many cryptographic algorithms. Once
deployed, even with moderate uptake, it is quite difficult to remove deployed, even with moderate uptake, it is quite difficult to remove
algorithms because interoperability with some party will be impacted. algorithms because interoperability with some party will be impacted.
As a result, weaker ciphers stick around far too long. Sometimes As a result, weaker ciphers stick around far too long. Sometimes
implementors are forced to maintain cryptographic algorithm implementors are forced to maintain cryptographic algorithm
skipping to change at page 11, line 22 skipping to change at page 11, line 44
impact the other selected algorithms. The idea is to have an impact the other selected algorithms. The idea is to have an
implemented and deployed algorithm as a fallback. However, all of implemented and deployed algorithm as a fallback. However, all of
the selected algorithms need to be routinely exercised to ensure the selected algorithms need to be routinely exercised to ensure
quality implementation. This is not always easy to do, especially if quality implementation. This is not always easy to do, especially if
the various selected algorithms require different credentials. the various selected algorithms require different credentials.
Obtaining multiple credentials for the same installation is an Obtaining multiple credentials for the same installation is an
unacceptable burden on system administrators. Also, the manner by unacceptable burden on system administrators. Also, the manner by
which system administrators are advised to switch algorithms or which system administrators are advised to switch algorithms or
suites is at best ad hoc, and at worst entirely absent. suites is at best ad hoc, and at worst entirely absent.
4.3. Picking One True Cipher Suite Can Be Harmful 3.3. Picking One True Cipher Suite Can Be Harmful
In the past, protocol designers have chosen one cryptographic In the past, protocol designers have chosen one cryptographic
algorithm or suite, and then tied many protocol details to that algorithm or suite, and then tied many protocol details to that
selection. Plan for algorithm transition, either because a mistake selection. Plan for algorithm transition, either because a mistake
is made in the initial selection or because the protocol is is made in the initial selection or because the protocol is
successfully used for a long time and the algorithm becomes week with successfully used for a long time and the algorithm becomes week with
age. Either way, the design should enable transition. age. Either way, the design should enable transition.
Protocol designers are sometimes mislead by the simplicity that Protocol designers are sometimes mislead by the simplicity that
results from selecting one true algorithm or suite. Since algorithms results from selecting one true algorithm or suite. Since algorithms
skipping to change at page 12, line 18 skipping to change at page 12, line 40
implementation were straightforward and fairly prompt. In many implementation were straightforward and fairly prompt. In many
software products, the new algorithm was not considered an update to software products, the new algorithm was not considered an update to
existing release, so the roll out of the next release, subsequent existing release, so the roll out of the next release, subsequent
deployment, and finally adjustment of the configuration by system deployment, and finally adjustment of the configuration by system
administrators took many years. In many consumer hardware products, administrators took many years. In many consumer hardware products,
firmware to implement the new algorithm were difficult to locate and firmware to implement the new algorithm were difficult to locate and
install, or the were simply not available. Further, infrastructure install, or the were simply not available. Further, infrastructure
providers were unwilling to make the transition until all of their providers were unwilling to make the transition until all of their
potential clients were able to use the new algorithm. potential clients were able to use the new algorithm.
4.4. National Cipher Suites 3.4. National Cipher Suites
Some nations specify cryptographic algorithms, and then require their Some nations specify cryptographic algorithms, and then require their
use through legislation or regulations. These algorithms may not use through legislation or regulations. These algorithms may not
have wide public review, and they can have limited reach of have wide public review, and they can have limited reach of
deployments. Yet, the legislative or regulatory mandate creates a deployments. Yet, the legislative or regulatory mandate creates a
captive market. As a result, the use of such algorithms get captive market. As a result, the use of such algorithms get
specified, implemented, and deployed. The default server or specified, implemented, and deployed. The default server or
responder configuration SHOULD disable such algorithms; in this way, responder configuration SHOULD disable such algorithms; in this way,
explicit action by the system administrator is needed to enable them explicit action by the system administrator is needed to enable them
where they are actually required. For tiny devices with no user where they are actually required. For tiny devices with no user
skipping to change at page 12, line 40 skipping to change at page 13, line 13
the device is purchased. the device is purchased.
National algorithms can force an implementer to produce several National algorithms can force an implementer to produce several
incompatible product releases for a different countries or regions, incompatible product releases for a different countries or regions,
which has significantly greater cost over development of a product which has significantly greater cost over development of a product
using a globally-acceptable algorithm. This situation could be even using a globally-acceptable algorithm. This situation could be even
worse if the various national algorithms impose different worse if the various national algorithms impose different
requirements on the protocol, its key management, or its use of requirements on the protocol, its key management, or its use of
random values. random values.
4.5. Balance Protocol Complexity 4. Security Considerations
Protocol designers MUST be prepared for the supported cryptographic
algorithm set to change over time. As shown by the discussion in the
previous two sections, there is a spectrum of ways to enable the
transition.
Keep implementations as simple as possible. Complex protocol
negotiation provides opportunities for attack, such as downgrade
attacks. Support for many algorithm alternatives is also harmful, as
discussed in Section 4.1. Both of these can lead to portions of the
implementation that are rarely used, increasing the opportunity for
undiscovered exploitable implementation bugs.
4.6. Providing Notice
Fortunately, catastrophic algorithm failures without warning are
rare. More often, algorithm transition is the result of age. For
example, the transition from DES to Triple-DES to AES took place over
decades, causing a shift in symmetric block cipher strength from 56
bits to 112 bits to 128 bits. Where possible, authors SHOULD provide
notice to implementers about expected algorithm transitions. One
approach that was first used in RFC 4307 [RFC4307] is to use SHOULD+,
SHOULD-, and MUST- in the specification of algorithms.
SHOULD+ This term means the same as SHOULD. However, it is
likely that an algorithm marked as SHOULD+ will be
promoted to a MUST in the future.
SHOULD- This term means the same as SHOULD. However, it is
likely that an algorithm marked as SHOULD- will be
deprecated to a MAY or worse in the future.
MUST- This term means the same as MUST. However, it is
expected that an algorithm marked as MUST- will be
downgraded in the future. Although the status of the
algorithm will be determined at a later time, it is
reasonable to expect that a the status of a MUST-
algorithm will remain at least a SHOULD or a SHOULD-.
5. Security Considerations
This document provides guidance to working groups and protocol This document provides guidance to working groups and protocol
designers. The security of the Internet is improved when broken or designers. The security of the Internet is improved when broken or
weak cryptographic algorithms can be easily replaced with strong weak cryptographic algorithms can be easily replaced with strong
ones. ones.
From a software development and maintenance perspective, From a software development and maintenance perspective,
cryptographic algorithms can often be added and removed without cryptographic algorithms can often be added and removed without
making changes to surrounding data structures, protocol parsing making changes to surrounding data structures, protocol parsing
routines, or state machines. This approach separates the routines, or state machines. This approach separates the
cryptographic algorithm implementation from the rest of the code, cryptographic algorithm implementation from the rest of the code,
which makes it easier to tackle special security concerns such as key which makes it easier to tackle special security concerns such as key
exposure and constant-time execution. exposure and constant-time execution.
The situation is different for hardware, for both tiny devices and Sometimes application layer protocols can make use of transport layer
very high-end data center equipment. Many tiny devices do not security protocols, such as TLS [RFC5246] or DTLS [RFC6347]. This
include the ability to update the firmware at all. Even if the insulates the application layer protocol from the details of
firmware can be updated, tiny devices are often deployed in places cryptography, but it is likely to still be necessary to handle the
that make it very inconvenient to do so. High-end data center transition from unprotected traffic to protected traffic in the
equipment may use special-purpose chips to achieve very high application layer protocol. In addition, the application layer
protocol may need to handle the downgrade from encrypted
communication to plaintext communication.
Hardware offers challenges in the transition of algorithms, for both
tiny devices and very high-end data center equipment. Many tiny
devices do not include the ability to update the firmware at all.
Even if the firmware can be updated, tiny devices are often deployed
in places that make it very inconvenient to do so. High-end data
center equipment may use special-purpose chips to achieve very high
performance, which means that board-level replacement may be needed performance, which means that board-level replacement may be needed
to change the algorithm. Cost and down-time are both factors in such to change the algorithm. Cost and down-time are both factors in such
an upgrade. an upgrade.
In most cases, the cryptographic algorithm remains strong, but an In most cases, the cryptographic algorithm remains strong, but an
attack is found against the way that the strong algorithm is used in attack is found against the way that the strong algorithm is used in
a particular protocol. In these cases, a protocol change will a particular protocol. In these cases, a protocol change will
probably be needed. For example, the order of cryptographic probably be needed. For example, the order of cryptographic
operations in the TLS protocol has evolved as various attacks have operations in the TLS protocol has evolved as various attacks have
been discovered. Originally, TLS performed encryption after been discovered. Originally, TLS performed encryption after
skipping to change at page 15, line 12 skipping to change at page 15, line 5
needs to begin when practically exploitable flaws become known. The needs to begin when practically exploitable flaws become known. The
update processes on some devices involve certification, which further update processes on some devices involve certification, which further
increases the time to deploy a replacement. For example, devices increases the time to deploy a replacement. For example, devices
that are part of health or safety systems often require certification that are part of health or safety systems often require certification
before deployment. Embedded systems and SCADA systems often have before deployment. Embedded systems and SCADA systems often have
upgrade cycles stretching over many years, leading to similar time to upgrade cycles stretching over many years, leading to similar time to
deployment issues. Prompt action is needed if a replacement has any deployment issues. Prompt action is needed if a replacement has any
hope of being deployed before exploitation techniques become widely hope of being deployed before exploitation techniques become widely
available exploits. available exploits.
6. IANA Considerations 5. IANA Considerations
This document does not establish any new IANA registries, nor does it This document does not establish any new IANA registries, nor does it
add any entries to existing registries. add any entries to existing registries.
This document does RECOMMEND a convention for new registries for This document does RECOMMEND a convention for new registries for
cryptographic algorithm or suite identifiers. Once an algorithm or cryptographic algorithm or suite identifiers. Once an algorithm or
suite identifier is added to the registry, it SHOULD NOT be changed suite identifier is added to the registry, it SHOULD NOT be changed
or removed. However, it is desirable to include a means of marking a or removed. However, it is desirable to include a means of marking a
registry entry as deprecated when implementation is no longer registry entry as deprecated when implementation is no longer
advisable. advisable.
7. Normative References 6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public
Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766,
April 2004. April 2004.
8. Informative References 7. Informative References
[BEAST] http://en.wikipedia.org/wiki/ [BEAST] http://en.wikipedia.org/wiki/
Transport_Layer_Security#BEAST_attack. Transport_Layer_Security#BEAST_attack.
[BN] Bellare, M. and C. Namprempre, "Authenticated Encryption: [BN] Bellare, M. and C. Namprempre, "Authenticated Encryption:
Relations among notions and analysis of the generic Relations among notions and analysis of the generic
composition paradigm", Proceedings of AsiaCrypt '00, composition paradigm", Proceedings of AsiaCrypt '00,
Springer-Verlag LNCS No. 1976, p. 531, December 2000. Springer-Verlag LNCS No. 1976, p. 531, December 2000.
[GCM] Dworkin, M, "Recommendation for Block Cipher Modes of [GCM] Dworkin, M, "Recommendation for Block Cipher Modes of
skipping to change at page 16, line 31 skipping to change at page 16, line 24
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307, Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
December 2005. December 2005.
[RFC5166] Floyd, S., Ed., "Metrics for the Evaluation of Congestion [RFC5166] Floyd, S., Ed., "Metrics for the Evaluation of Congestion
Control Mechanisms", RFC 5166, March 2008. Control Mechanisms", RFC 5166, March 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, September 2009. RFC 5652, September 2009.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010. Specification", RFC 5751, January 2010.
[RFC6347] Rescorla, E., and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility
Procedure for the Resource Public Key Infrastructure Procedure for the Resource Public Key Infrastructure
(RPKI)", BCP 182, RFC 6916, April 2013. (RPKI)", BCP 182, RFC 6916, April 2013.
[RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic Algorithm [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic Algorithm
Understanding in DNS Security Extensions (DNSSEC)", Understanding in DNS Security Extensions (DNSSEC)",
RFC 6975, July 2013. RFC 6975, July 2013.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
 End of changes. 32 change blocks. 
198 lines changed or deleted 189 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/