< draft-iab-crypto-alg-agility-06.txt   draft-iab-crypto-alg-agility-07.txt >
Internet-Draft R. Housley Internet-Draft R. Housley
Intended Status: Best Current Practice Vigil Security Intended Status: Best Current Practice Vigil Security
Expires: 8 January 2016 7 July 2015 Expires: 18 February 2016 17 August 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-06.txt> <draft-iab-crypto-alg-agility-07.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 5 skipping to change at page 2, line 5
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright and License Notice Copyright and License Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
Guidelines for Cryptographic Algorithm Agility August 2015
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.
skipping to change at page 3, line 4 skipping to change at page 3, line 4
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
algorithms will change over time, and an IANA registry of algorithm algorithms will change over time, and an IANA registry of algorithm
identifiers will be needed. identifiers will be needed.
Algorithm identifiers by themselves are not sufficient to ensure easy Algorithm identifiers by themselves are not sufficient to ensure easy
migration. Action by people that maintain implementations and migration. Action by people that maintain implementations and
operate services is needed to develop, deploy, and adjust operate services is needed to develop, deploy, and adjust
configuration settings to enable the new more desirable algorithms configuration settings to enable the new more desirable algorithms
and to deprecate or disable older, less desirable ones. For various and to deprecate or disable older, less desirable ones. For various
Guidelines for Cryptographic Algorithm Agility August 2015
reasons, most notably interoperability concerns, experience has shown reasons, most notably interoperability concerns, experience has shown
that it has proven difficult for implementors and administrators to that it has proven difficult for implementors and administrators to
remove or disable weak algorithms. Further, the inability of legacy remove or disable weak algorithms. Further, the inability of legacy
systems and resource-constrained devices to support new algorithms systems and resource-constrained devices to support new algorithms
adds to those concerns. As a result, people live with weaker adds to those concerns. As a result, people live with weaker
algorithms, sometimes seriously flawed ones, well after experts algorithms, sometimes seriously flawed ones, well after experts
recommend migration. recommend migration.
1.1. Terminology 1.1. Terminology
skipping to change at page 4, line 4 skipping to change at page 4, line 4
[RFC5246] version number names the default key derivation function [RFC5246] version number names the default key derivation function
and the cipher suite identifier names the rest of the needed and the cipher suite identifier names the rest of the needed
algorithms. 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
Guidelines for Cryptographic Algorithm Agility August 2015
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
at run-time regarding which algorithm combinations are acceptable. at run-time regarding which algorithm combinations are acceptable.
Regardless of the approach used, protocols historically negotiate the Regardless of the approach used, protocols historically negotiate the
symmetric cipher and cipher mode together to ensure that they are symmetric cipher and cipher mode together to ensure that they are
completely compatible. completely compatible.
skipping to change at page 5, line 5 skipping to change at page 5, line 5
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
changes frequently. changes frequently.
The IETF SHOULD keep the set of mandatory-to-implement algorithms The IETF SHOULD keep the set of mandatory-to-implement algorithms
small. To do so, the set of algorithms will necessarily change over small. To do so, the set of algorithms will necessarily change over
time, and the transition SHOULD happen before the algorithms in the time, and the transition SHOULD happen before the algorithms in the
current set have weakened to the breaking point. current set have weakened to the breaking point.
Guidelines for Cryptographic Algorithm Agility August 2015
2.2.1. Platform Specifications 2.2.1. Platform Specifications
Note that mandatory-to-implement algorithms or suites are not Note that mandatory-to-implement algorithms or suites are not
specified for protocols that are embedded in other protocols; in specified for protocols that are embedded in other protocols; in
these cases the system-level protocol specification identifies the these cases the system-level protocol specification identifies the
mandatory-to-implement algorithm or suite. For example, S/MIME mandatory-to-implement algorithm or suite. For example, S/MIME
[RFC5751] makes use of the cryptographic message Syntax (CMS) [RFC5751] makes use of the cryptographic message Syntax (CMS)
[RFC5652], and S/MIME specifies the mandatory-to-implement [RFC5652], and S/MIME specifies the mandatory-to-implement
algorithms, not CMS. This approach allows other protocols can make algorithms, not CMS. This approach allows other protocols can make
use of CMS and make different mandatory-to-implement algorithm use of CMS and make different mandatory-to-implement algorithm
skipping to change at page 6, line 5 skipping to change at page 6, line 5
SHOULD-, and MUST- in the specification of algorithms. SHOULD-, and MUST- in the specification of algorithms.
SHOULD+ This term means the same as SHOULD. However, it is SHOULD+ This term means the same as SHOULD. However, it is
likely that an algorithm marked as SHOULD+ will be likely that an algorithm marked as SHOULD+ will be
promoted to a MUST in the future. promoted to a MUST in the future.
SHOULD- This term means the same as SHOULD. However, it is SHOULD- This term means the same as SHOULD. However, it is
likely that an algorithm marked as SHOULD- will be likely that an algorithm marked as SHOULD- will be
deprecated to a MAY or worse in the future. deprecated to a MAY or worse in the future.
Guidelines for Cryptographic Algorithm Agility August 2015
MUST- This term means the same as MUST. However, it is MUST- This term means the same as MUST. However, it is
expected that an algorithm marked as MUST- will be expected that an algorithm marked as MUST- will be
downgraded in the future. Although the status of the downgraded in the future. Although the status of the
algorithm will be determined at a later time, it is algorithm will be determined at a later time, it is
reasonable to expect that a the status of a MUST- reasonable to expect that a the status of a MUST-
algorithm will remain at least a SHOULD or a SHOULD-. 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
skipping to change at page 7, line 5 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.
Guidelines for Cryptographic Algorithm Agility August 2015
2.4. Algorithm Transition Mechanisms 2.4. Algorithm Transition 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 Transition mechanisms SHOULD consider the algorithm that is used to
skipping to change at page 8, line 4 skipping to change at page 8, line 4
Some environments will restrict the key management approaches by Some environments will restrict the key management approaches by
policy. Such policies tend to improve interoperability within a policy. Such policies tend to improve interoperability within a
particular environment, but they cause problems for individuals that particular environment, but they cause problems for individuals that
need to work in multiple incompatible environments. need to work in multiple incompatible environments.
2.6. Preserving Interoperability 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
Guidelines for Cryptographic Algorithm Agility August 2015
impacts of legacy software and 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, and the browser vendor 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 in order to
interoperability. preserve interoperability.
Transition in Internet infrastructure is particularly difficult. The Transition in Internet infrastructure is particularly difficult. The
digital signature on a trust anchor certificate [RFC5280] is often digital signature on a trust anchor certificate [RFC5280] is often
expected to last decades, which hinders the transition away from a expected to last decades, which hinders the transition away from a
weak signature algorithm or short key length. Once a long-lived weak signature algorithm or short key length. Once a long-lived
certificate is issued with a particular signature algorithm, that certificate is issued with a particular signature algorithm, that
algorithm will be used by many relying parties, and none of them can algorithm will be used by many relying parties, and none of them can
stop supporting it without invalidating all of the subordinate stop supporting it without invalidating all of the subordinate
certificates. In a hierarchal system, many subordinate certificates certificates. In a hierarchical system, many subordinate
could be impacted by the decision to drop support for a weak certificates could be impacted by the decision to drop support for a
signature algorithm or an associated hash function. weak signature algorithm or an associated hash function.
Institutions, being large or dominate users within a large user base, Institutions, being large or dominant 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.
2.7. Balance Security Strength 2.7. Balance Security Strength
When selecting or negotiating a suite of cryptographic algorithms, When selecting or negotiating a suite of cryptographic algorithms,
the strength of each algorithm SHOULD be considered. The algorithms the strength of each algorithm SHOULD be considered. The algorithms
in a suite SHOULD be roughly equal; however, the security service in a suite SHOULD be roughly equal; however, the security service
provided by each algorithm in a particular context needs to be provided by each algorithm in a particular context needs to be
considered in making the selection. Algorithm strength needs to be considered in making the selection. Algorithm strength needs to be
skipping to change at page 9, line 4 skipping to change at page 9, line 4
deploying and configuring a protocol implementation. For this deploying and configuring a protocol implementation. For this
reason, protocol designers SHOULD provide clear guidance to reason, protocol designers SHOULD provide clear guidance to
implementors, leading to balanced options being available at the time implementors, leading to balanced options being available at the time
of deployment and configuration. of deployment and configuration.
Performance is always a factor is selecting cryptographic algorithms. Performance is always a factor is selecting cryptographic algorithms.
Performance and security need to be balanced. Some algorithms offer Performance and security need to be balanced. Some algorithms offer
flexibility in their strength by adjusting the key size, number of flexibility in their strength by adjusting the key size, number of
rounds, authentication tag size, prime group size, and so on. For rounds, authentication tag size, prime group size, and so on. For
example, cipher suites include Diffie-Hellman or RSA without example, cipher suites include Diffie-Hellman or RSA without
Guidelines for Cryptographic Algorithm Agility August 2015
specifying a particular public key length. If the algorithm specifying a particular public key length. If the algorithm
identifier or suite identifier named a particular public key length, identifier or suite identifier named a particular public key length,
migration to longer ones would be more difficult. On the other hand, 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 inclusion of a public key length would make it easier to migrate away
from short ones when computational resources available to attacker from short ones when computational resources available to attacker
dictate the need to do so. Therefore, flexibility on asymmetric key dictate the need to do so. Therefore, flexibility on asymmetric key
length is both desirable and undesirable at the same time. length is both desirable and undesirable at the same time.
In CMS [RFC5652], a previously distributed symmetric key-encryption In CMS [RFC5652], a previously distributed symmetric key-encryption
key can be used to encrypt a content-encryption key, which is in turn key can be used to encrypt a content-encryption key, which is in turn
skipping to change at page 10, line 5 skipping to change at page 10, line 5
SHOULD also be considered, especially at the time a protocol SHOULD also be considered, especially at the time a protocol
implementation is deployed and configured. Using algorithms that are implementation is deployed and configured. Using algorithms that are
weak against advanced attackers but sufficient against others is a weak against advanced attackers but sufficient against others is a
way to make pervasive surveillance significantly more difficult. As way to make pervasive surveillance significantly more difficult. As
a result, algorithms that would not be acceptable in many negotiated a result, algorithms that would not be acceptable in many negotiated
situations are acceptable for opportunistic security. Similarly, situations are acceptable for opportunistic security. Similarly,
weaker algorithms and shorter key sizes are also acceptable for weaker algorithms and shorter key sizes are also acceptable for
opportunistic security. That said, the use of strong algorithms is opportunistic security. That said, the use of strong algorithms is
always preferable. always preferable.
Guidelines for Cryptographic Algorithm Agility August 2015
3. Cryptographic Algorithm Specifications 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 and the time to deploy a new algorithm. This that are supported and the time to deploy a new algorithm. This
section provides some of the insights about the tradeoff faced by section provides some of the insights about the 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.
3.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 may seem as if the ability to use an algorithm of one's own
is very desirable; however, the selection is often better left to choosing is very desirable; however, the selection is often better
experts. Further, any and all cryptographic algorithm choices ought left to experts. Further, any and all cryptographic algorithm
not be available in every implementation. Mandatory-to-implement choices ought not be available in every implementation. Mandatory-
algorithms ought to have a public stable specification and public to-implement algorithms ought to have a public stable specification
documentation that it has been well studied, giving rise to and public documentation that it has been well studied, giving rise
significant confidence. The IETF has alway had a preference for to 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.
There is significant benefit in selecting the same algorithms and There is significant benefit in selecting the same algorithms and
suites for different protocols. Using the same algorithms can suites for different protocols. Using the same algorithms can
skipping to change at page 11, line 4 skipping to change at page 11, line 4
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.
3.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
Guidelines for Cryptographic Algorithm Agility August 2015
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
implementations well beyond their useful lifetime. implementations well beyond their useful lifetime.
In order to manage the proliferation of algorithm choices and provide In order to manage the proliferation of algorithm choices and provide
skipping to change at page 11, line 50 skipping to change at page 11, line 53
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.
3.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 weak with
age. Either way, the design should enable transition. age. Either way, the design should enable transition.
Guidelines for Cryptographic Algorithm Agility August 2015
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
age, the selection cannot be stable forever. Even the most simple age, the selection cannot be stable forever. Even the most simple
protocol needs a version number to signal which algorithm that is protocol needs a version number to signal which algorithm is being
being used. This approach has at least two desirable consequences. used. This approach has at least two desirable consequences. First,
First, the protocol is simpler because there is no need for algorithm the protocol is simpler because there is no need for algorithm
negotiation. Second, system administrators do not need to make any negotiation. Second, system administrators do not need to make any
algorithm-related configuration decisions. However, the only way to algorithm-related configuration decisions. However, the only way to
respond to news that the an algorithm that is part of the one true respond to news that the an algorithm that is part of the one true
cipher suite has been broken is to update the protocol specification cipher suite has been broken is to update the protocol specification
to the next version, implement the new specification, and then get it to the next version, implement the new specification, and then get it
deployed. deployed.
The first IEEE 802.11 [WiFi] specification included the Wired The first IEEE 802.11 [WiFi] specification included Wired Equivalent
Equivalent Privacy (WEP) as the only encryption technique. Many of Privacy (WEP) as the only encryption technique. Many of the protocol
the protocol details were driven by the selected algorithm. WEP was details were driven by the selected algorithm. WEP was found to be
found to be quite weak [WEP], and a very large effort was needed to quite weak [WEP], and a very large effort was needed to specify,
specify, implement, and deploy the alternative encryption techniques. implement, and deploy the alternative encryption techniques. This
This effort was made even harder by the protocol design choices that effort was made even harder by the protocol design choices that were
were tied to the initial algorithm selection and the desire for tied to the initial algorithm selection and the desire for backward
backward compatibility. compatibility.
Experience with the transition from SHA-1 to SHA-256 indicates that Experience with the transition from SHA-1 to SHA-256 indicates that
the time from protocol specificate to widespread use takes more than the time from protocol specification to widespread use takes more
five years. In this case, the protocol specifications and than five years. In this case, the protocol specifications and
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.
3.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 gets
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
interface, an administrator action may only be possible at the time interface, an administrator action may only be possible at the time
the device is purchased. the device is purchased.
Guidelines for Cryptographic Algorithm Agility August 2015
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. Security Considerations 4. Security Considerations
skipping to change at page 14, line 4 skipping to change at page 14, line 4
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
Guidelines for Cryptographic Algorithm Agility August 2015
computation of the message authentication code (MAC). This order of computation of the message authentication code (MAC). This order of
operations is called MAC-then-encrypt, which actually involves MAC operations is called MAC-then-encrypt, which actually involves MAC
computation, padding, and then encryption. This is no longer computation, padding, and then encryption. This is no longer
considered secure [BN][K]. As a result, a mechanism was specified to considered secure [BN][K]. As a result, a mechanism was specified to
use encrypt-then-MAC instead [RFC7366]. Future versions of TLS are use encrypt-then-MAC instead [RFC7366]. Future versions of TLS are
expected to use exclusively authenticated encryption algorithms expected to use exclusively authenticated encryption algorithms
[RFC5166], which should resolve the ordering discussion altogether. [RFC5166], which should resolve the ordering discussion altogether.
After discovery of such attacks, updating the cryptographic After discovery of such attacks, updating the cryptographic
algorithms is not likely to be sufficient to thwart the new attack. algorithms is not likely to be sufficient to thwart the new attack.
It may necessary to make significant changes to the protocol. It may necessary to make significant changes to the protocol.
Some protocols are used to protected stored data. For example, Some protocols are used to protect stored data. For example, S/MIME
S/MIME [RFC5751] can protect a message kept in a mailbox. To recover [RFC5751] can protect a message kept in a mailbox. To recover the
the protected stored data, protocol implementations need to support protected stored data, protocol implementations need to support older
older algorithms, even when they no longer use the older algorithms algorithms, even when they no longer use the older algorithms for the
for the protection of new stored data. protection of new stored data.
Support for too many algorithms can lead to implementation Support for too many algorithms can lead to implementation
vulnerabilities. When many algorithms are supported, some of them vulnerabilities. When many algorithms are supported, some of them
will be rarely used. Any code that is rarely used can contain will be rarely used. Any code that is rarely used can contain
undetected bugs, and algorithm implementations are no different. undetected bugs, and algorithm implementations are no different.
Measurements SHOULD be used to determine whether implemented Measurements SHOULD be used to determine whether implemented
algorithms are actually being used, and if they are not, future algorithms are actually being used, and if they are not, future
releases should remove them. In addition, unused algorithms or releases should remove them. In addition, unused algorithms or
suites SHOULD be marked as deprecated in the IANA registry. In suites SHOULD be marked as deprecated in the IANA registry. In
short, eliminate the cruft. short, eliminate the cruft.
skipping to change at page 15, line 5 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.
Guidelines for Cryptographic Algorithm Agility August 2015
5. 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
skipping to change at page 16, line 5 skipping to change at page 16, line 5
Proceedings of Crypto '01, Springer-Verlag LNCS No. 2139, Proceedings of Crypto '01, Springer-Verlag LNCS No. 2139,
p. 310, August 2001. p. 310, August 2001.
[RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic
Technology and the Internet", RFC 1984, August 1996. Technology and the Internet", RFC 1984, August 1996.
[RFC3365] Schiller, J., "Strong Security Requirements for Internet [RFC3365] Schiller, J., "Strong Security Requirements for Internet
Engineering Task Force Standard Protocols", BCP 61, RFC Engineering Task Force Standard Protocols", BCP 61, RFC
3365, August 2002. 3365, August 2002.
Guidelines for Cryptographic Algorithm Agility August 2015
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
CBC-MAC (CCM)", RFC 3610, September 2003. CBC-MAC (CCM)", RFC 3610, September 2003.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005. 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
skipping to change at page 17, line 5 skipping to change at page 17, line 5
(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
(IKEv2)", STD 79, RFC 7296, October 2014. (IKEv2)", STD 79, RFC 7296, October 2014.
Guidelines for Cryptographic Algorithm Agility August 2015
[RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer Security [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer Security
(TLS) and Datagram Transport Layer Security (DTLS)", (TLS) and Datagram Transport Layer Security (DTLS)",
RFC 7366, September 2014. RFC 7366, September 2014.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most
of the Time", RFC 7435, December 2014. of the Time", RFC 7435, December 2014.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations
for Secure Use of Transport Layer Security (TLS) and for Secure Use of Transport Layer Security (TLS) and
Datagram Transport Layer Security (DTLS)", RFC 7525, Datagram Transport Layer Security (DTLS)", RFC 7525,
skipping to change at page 17, line 30 skipping to change at page 17, line 32
Physical Layer (PHY) Specifications, IEEE Std 802.11-1997, Physical Layer (PHY) Specifications, IEEE Std 802.11-1997,
1997. 1997.
Acknowledgements Acknowledgements
Thanks to Bernard Aboba, Derek Atkins, David Black, Randy Bush, Jon Thanks to Bernard Aboba, Derek Atkins, David Black, Randy Bush, Jon
Callas, Andrew Chi, Steve Crocker, Viktor Dukhovni, Stephen Farrell, Callas, Andrew Chi, Steve Crocker, Viktor Dukhovni, Stephen Farrell,
Tony Finch, Ian Grigg, Peter Gutmann, Wes Hardaker, Joe Hildebrand, Tony Finch, Ian Grigg, Peter Gutmann, Wes Hardaker, Joe Hildebrand,
Paul Hoffman, Phillip Hallam-Baker, Christian Huitema, Watson Ladd, Paul Hoffman, Phillip Hallam-Baker, Christian Huitema, Watson Ladd,
Paul Lambert, Ben Laurie, Eliot Lear, Nikos Mavrogiannopoulos, Yoav Paul Lambert, Ben Laurie, Eliot Lear, Nikos Mavrogiannopoulos, Yoav
Nir, Rich Salz, Rene Struik, Kristof Teichel, Martin Thompson, Nir, Wendy Seltzer, Rich Salz, Rene Struik, Kristof Teichel, Martin
Jeffrey Walton, Nico Williams, and Peter Yee for their review and Thompson, Jeffrey Walton, Nico Williams, and Peter Yee for their
insightful comments. While some of these people do not agree with review and insightful comments. While some of these people do not
some aspects of this document, the discussion that resulted for their agree with some aspects of this document, the discussion that
comments has certainly resulted in a better document. resulted for their comments has certainly resulted in a better
document.
Author's Address Author's Address
Russ Housley Russ Housley
Vigil Security, LLC Vigil Security, LLC
918 Spring Knoll Drive 918 Spring Knoll Drive
Herndon, VA 20170 Herndon, VA 20170
USA USA
EMail: housley@vigilsec.com EMail: housley@vigilsec.com
 End of changes. 29 change blocks. 
41 lines changed or deleted 80 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/