< draft-iab-crypto-alg-agility-04.txt   draft-iab-crypto-alg-agility-05.txt >
Internet-Draft R. Housley Internet-Draft R. Housley
Intended Status: Best Current Practice Vigil Security Intended Status: Best Current Practice Vigil Security
Expires: 23 November 2015 22 May 2015 Expires: 6 December 2015 4 June 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-04.txt> <draft-iab-crypto-alg-agility-05.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 or become more feasible for more attackers.
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
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. In a perfect and to deprecate or disable older, less desirable ones. For various
world, this takes place before the older algorithm or suite of reasons, most notably interoperability concerns, experience has shown
algorithms is catastrophically weakened. However, experience has that it has proven difficult for implementors and administrators to
shown that many people are unwilling to disable older weaker remove or disable weak algorithms. Further, the inability of legacy
algorithms; it seems that these people prefer to live with weaker systems and resource-constrained devices to support new algorithms
algorithms, sometimes seriously flawed ones, to maintain adds to those concerns. As a result, people live with weaker
interoperability with older software well after experts recommend algorithms, sometimes seriously flawed ones, well after experts
migration. recommend migration.
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
skipping to change at page 4, line 13 skipping to change at page 4, line 33
identifiers. Once an algorithm identifier is added to the registry, identifiers. Once an algorithm identifier is added to the registry,
it should not be changed or removed. However, it is desirable to it should not be changed or removed. However, it is desirable to
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 mandatory-to-implement algorithm or protocol MUST specify one or more strong mandatory-to-implement
suite. Note that this is not done for protocols that are embedded in algorithm or suite. This does not require all deployments to use
other protocols, where the system-level protocol specification this algorithm or suite, but it does require that are available to
identifies the mandatory-to-implement algorithm or suite. For all deployments.
example, S/MIME [RFC5751] makes use of the cryptographic message
Syntax (CMS) [RFC5652], and S/MIME specifies the mandatory-to-
implement algorithms, not CMS. This approach allows other protocols
can make use of CMS and make different mandatory-to-implement
algorithm choices.
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
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.
2.2.1. Platform Specifications
Note that mandatory-to-implement algorithms or suites are not
specified for protocols that are embedded in other protocols; in
these cases the system-level protocol specification identifies the
mandatory-to-implement algorithm or suite. For example, S/MIME
[RFC5751] makes use of the cryptographic message Syntax (CMS)
[RFC5652], and S/MIME specifies the mandatory-to-implement
algorithms, not CMS. This approach allows other protocols can make
use of CMS and make different mandatory-to-implement algorithm
choices.
2.2.2. Cryptographic Key Size
Some cryptographic algorithms are inherently tied to a specific key Some cryptographic algorithms are inherently tied to a specific key
size, but others allow many different key sizes. Likewise, some size, but others allow many different key sizes. Likewise, some
algorithms support parameters of different sizes, such as integrity algorithms support parameters of different sizes, such as integrity
check values or nonces. The algorithm specification MUST identify check values or nonces. The algorithm specification MUST identify
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].
skipping to change at page 5, line 16 skipping to change at page 5, line 44
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.
Algorithm transition is naturally facilitated as part of an algorithm Algorithm transition is naturally facilitated as part of an algorithm
selection or negotiation mechanism. Protocols MUST facilitate the selection or negotiation mechanism. Protocols traditionally select
selection to the best algorithm or suite that is supported by all the best algorithm or suite that is supported by all communicating
communicating peers. In addition, a mechanism is needed to determine peers and acceptable by their policies. In addition, a mechanism is
whether the new algorithm has been deployed. For example, the DNSSEC needed to determine whether the new algorithm has been deployed. For
EDNS0 option [RFC6975] measures the acceptance and use of new digital example, SMIMECapabilities [RFC5751] allows S/MIME mail user agents
signing algorithms. to share the list of algorithms that they are willing to use in
preference order. For another example, the DNSSEC EDNS0 option
[RFC6975] measures the acceptance and use of new digital signing
algorithms.
In the Resource Public Key Infrastructure (RPKI), a globally-
recognized digital signature is needed. BCP 182 [RFC6916] provides
an approach to transition where a second signature algorithm is
introduced and then the original one is phased out.
In the worst case, the old algorithm may be found to be tragically In the worst case, the old algorithm may be found to be tragically
flawed, permitting a casual attacker to download a simple script to flawed, permitting a casual attacker to download a simple script to
break it. Sadly, this has happened when a secure algorithm is used break it. Sadly, this has happened when a secure algorithm is used
incorrectly or used with poor key management, resulting in a weak incorrectly or used with poor key management, resulting in a weak
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. Balance Security Strength
When selecting a suite of cryptographic algorithms, the strength of When selecting or negotiating a suite of cryptographic algorithms,
each algorithm SHOULD be considered. It needs to be considered at the strength of each algorithm SHOULD be considered. The algorithms
the time a protocol is designed. It also needs to be considered at in a suite SHOULD be roughly equal; however, the security service
the time a protocol implementation is deployed and configured. provided by each algorithm in a particular context needs to be
Advice from from experts is useful, but in reality, it is not often considered in making the selection. Algorithm strength needs to be
available to system administrators that are deploying and configuring considered at the time a protocol is designed. It also needs to be
a protocol implementation. For this reason, protocol designers considered at the time a protocol implementation is deployed and
SHOULD provide clear guidance to implementors, leading to balanced configured. Advice from from experts is useful, but in reality, it
options being available at the time of deployment and configuration. 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.
Cipher suites include Diffie-Hellman or RSA without specifying a Some algorithms offer flexibility in their strength by adjusting the
particular public key length. If the algorithm identifier or suite key size, number of rounds, authentication tag size, prime group
identifier named a particular public key length, migration to longer size, and so on. For example, cipher suites include Diffie-Hellman
ones would be more difficult. On the other hand, inclusion of a or RSA without specifying a particular public key length. If the
public key length would make it easier to migrate away from short algorithm identifier or suite identifier named a particular public
ones when computational resources available to attacker dictate the key length, migration to longer ones would be more difficult. On the
need to do so. Therefore, flexibility on asymmetric key length is other hand, inclusion of a public key length would make it easier to
both desirable and undesirable at the same time. 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 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
used to encrypt the content. The key-encryption and content- used to encrypt the content. The key-encryption and content-
encryption algorithms are often different. If, for example, a encryption algorithms are often different. If, for example, a
message content is encrypted with 128-bit AES key and the content- 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 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 bits of protection is provided. In this situation, the algorithm and
key size selections should ensure that the key encryption is at least key size selections should ensure that the key encryption is at least
as strong as the content encryption. In general, wrapping one key as strong as the content encryption. In general, wrapping one key
with another key of a different size yields the security strength of with another key of a different size yields the security strength of
the shorter key. the shorter key.
2.5. Opportunistic Security 2.5. Opportunistic Security
Despite the guidance in Section 2.4, opportunistic security [RFC7435] Despite the guidance in Section 2.4, opportunistic security [RFC7435]
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. While RSA with a 2048-bit implementation is deployed and configured. Using algorithms that are
public key is quite a bit stronger than SHA-1, it is quite reasonable weak against advanced attackers but sufficient against others is a
to use them together if the alternative is no authentication way to make pervasive surveillance significantly more difficult. As
whatsoever. That said, the use of strong algorithms is always a result, algorithms that would not be acceptable in many negotiated
preferable. 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 3. Algorithm Agility in Protocol Design
Some attempts at algorithm agility have not been completely Some attempts at algorithm agility have not been completely
successful. This section provides some of the insights based on successful. This section provides some of the insights based on
protocol designs and deployments. protocol designs and deployments.
3.1. Algorithm Identifiers 3.1. Algorithm Identifiers
If a protocol does not carry an algorithm identifier, then the If a protocol does not carry an algorithm identifier, then the
skipping to change at page 7, line 45 skipping to change at page 8, line 42
reason, protocols need mechanisms to migrate from one algorithm suite reason, protocols need mechanisms to migrate from one algorithm suite
to another over time, including the algorithm used to provide to another over time, including the algorithm used to provide
integrity protection for algorithm negotiation. integrity protection for algorithm negotiation.
3.3. Preserving Interoperability 3.3. 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 develop, deploy, and configure new reduced by making it easy to rollover from old algorithms and suites
algorithms. to new ones.
Without clear mechanisms for algorithm and suite rollover, preserving
interoperability becomes a difficult social problem. For example,
consider web browsers. Dropping support for an algorithm suite can
break connectivity to some web sites because, and the browser will
lose users by doing so. This situation creates incentives to support
algorithm suites that would otherwise be deprecated, but preserving
interoperability.
Institutions, being large or dominate users within a large user base,
can assist by coordinating the demise of an algorithm suite, making
the rollover easier for their own users as well as others.
3.4. Cryptographic Key Management 3.4. Cryptographic Key Management
Traditionally, protocol designers have avoided more than one approach Traditionally, protocol designers have avoided more than one approach
to key management because it makes the security analysis of the to key management because it makes the security analysis of the
overall protocol more difficult. When frameworks such as EAP and overall protocol more difficult. When frameworks such as EAP and
GSSAPI are employed, the key management is very flexible, often GSSAPI are employed, the key management is very flexible, often
hiding many of the details from the application. This results in hiding many of the details from the application. This results in
protocols that support multiple key management approaches. In fact, protocols that support multiple key management approaches. In fact,
the key management approach itself may be negotiable, which creates a the key management approach itself may be negotiable, which creates a
skipping to change at page 8, line 43 skipping to change at page 9, line 52
4.1. Choosing Mandatory-to-Implement Algorithms 4.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. The selected algorithms need to be unencumbered algorithms. There are significant benefits in selecting
resistant to side-channel attacks as well as meeting the performance, algorithms and suites that are widely deployed. The selected
power, and code size requirements on a wide variety of platforms. In algorithms need to be resistant to side-channel attacks as well as
addition, inclusion of too many alternatives may add complexity to meeting the performance, power, and code size requirements on a wide
algorithm selection or negotiation. variety of platforms. In addition, inclusion of too many
alternatives may add complexity to algorithm selection or
negotiation.
Section 4.1 neglects to mention the obvious benefit in selecting
something that lots of other people are using too. That's a non-
trivial advantage over and above the reasons cited (though many of
them might be considered different ways of saying the same thing).
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.
skipping to change at page 10, line 11 skipping to change at page 11, line 26
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 4.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. It is much better to plan for algorithm transition, selection. Plan for algorithm transition, either because a mistake
either because a mistake is made in the initial selection or because is made in the initial selection or because the protocol is
the protocol is successfully used for a long time and the algorithm successfully used for a long time and the algorithm becomes week with
becomes week with age. Either way, the design should enable age. Either way, the design should enable transition.
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
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 that is
being used. This approach has at least two desirable consequences. being used. This approach has at least two desirable consequences.
First, the protocol is simpler because there is no need for algorithm First, 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 the Wired
Equivalent Privacy (WEP) as the only encryption technique. WEP was Equivalent Privacy (WEP) as the only encryption technique. Many of
the protocol details were driven by the selected algorithm. WEP was
found to be quite weak [WEP], and a very large effort was needed to found to be quite weak [WEP], and a very large effort was needed to
specify, implement, and deploy the alternative encryption techniques. specify, implement, and deploy the alternative encryption techniques.
This effort was made even harder by the protocol design choices that
were tied to the initial algorithm selection and the desire for
backward 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 specificate to widespread use takes more than
five years. In this case, the protocol specifications and 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
skipping to change at page 11, line 7 skipping to change at page 12, line 25
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 4.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-side specified, implemented, and deployed. The default server or
configuration SHOULD disable such algorithms; in this way, explicit responder configuration SHOULD disable such algorithms; in this way,
action by the system administrator is needed to enable them where explicit action by the system administrator is needed to enable them
they are actually required. where they are actually required. For tiny devices with no user
interface, an administrator action may only be possible at the time
the device is purchased.
National algorithms can force an implementer to produce several
incompatible product releases for a different countries or regions,
which has significantly greater cost over development of a product
using a globally-acceptable algorithm. This situation could be even
worse if the various national algorithms impose different
requirements on the protocol, its key management, or its use of
random values.
4.5. Balance Protocol Complexity 4.5. Balance Protocol Complexity
Protocol designers MUST be prepared for the supported cryptographic Protocol designers MUST be prepared for the supported cryptographic
algorithm set to change over time. As shown by the discussion in the 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 previous two sections, there is a spectrum of ways to enable the
transition. transition.
Keep implementations as simple as possible. Complex protocol Keep implementations as simple as possible. Complex protocol
negotiation provides opportunities for attack, such as downgrade negotiation provides opportunities for attack, such as downgrade
skipping to change at page 11, line 34 skipping to change at page 13, line 13
undiscovered exploitable implementation bugs. undiscovered exploitable implementation bugs.
4.6. Providing Notice 4.6. Providing Notice
Fortunately, catastrophic algorithm failures without warning are Fortunately, catastrophic algorithm failures without warning are
rare. More often, algorithm transition is the result of age. For rare. More often, algorithm transition is the result of age. For
example, the transition from DES to Triple-DES to AES took place over example, the transition from DES to Triple-DES to AES took place over
decades, causing a shift in symmetric block cipher strength from 56 decades, causing a shift in symmetric block cipher strength from 56
bits to 112 bits to 128 bits. Where possible, authors SHOULD provide bits to 112 bits to 128 bits. Where possible, authors SHOULD provide
notice to implementers about expected algorithm transitions. One notice to implementers about expected algorithm transitions. One
approach is to use SHOULD+, SHOULD-, and MUST- in the specification approach that was first used in RFC 4307 [RFC4307] is to use SHOULD+,
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.
MUST- This term means the same as MUST. However, it is MUST- This term means the same as MUST. However, it is
skipping to change at page 13, line 22 skipping to change at page 14, line 47
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.
Section 2.3 talks about algorithm transition without considering any Section 2.3 talks about algorithm transition without considering any
other aspects of the protocol design. In practice, there are other aspects of the protocol design. In practice, there are
dependencies between the cryptographic algorithm and other aspects of dependencies between the cryptographic algorithm and other aspects of
the protocol. For example, the BEAST attack [BEAST] against TLS the protocol. For example, the BEAST attack [BEAST] against TLS
[RFC5246] caused many sites to turn off modern cryptographic [RFC5246] caused many sites to turn off modern cryptographic
algorithms in favor of older and clearly weaker algorithms. algorithms in favor of older and clearly weaker algorithms.
Mechanisms for timely update of devices are needed to deploy a
replacement algorithm or suite. It takes a long time to specify,
implement, and deploy a replacement, therefore the transition process
needs to begin when practically exploitable flaws become known. The
update processes on some devices involve certification, which further
increases the time to deploy a replacement. For example, devices
that are part of health or safety systems often require certification
before deployment. Embedded systems and SCADA systems often have
upgrade cycles stretching over many years, leading to similar time to
deployment issues. Prompt action is needed if a replacement has any
hope of being deployed before exploitation techniques become widely
available exploits.
6. IANA Considerations 6. 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 14, line 30 skipping to change at page 16, line 21
[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
Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
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.
[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.
[RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility
Procedure for the Resource Public Key Infrastructure
(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.
[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)",
skipping to change at page 15, line 28 skipping to change at page 17, line 24
[WiFi] IEEE , "Wireless LAN Medium Access Control (MAC) And [WiFi] IEEE , "Wireless LAN Medium Access Control (MAC) And
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,
Christian Huitema, Watson Ladd, Paul Lambert, Ben Laurie, Eliot Lear, Paul Hoffman, Phillip Hallam-Baker, Christian Huitema, Watson Ladd,
Nikos Mavrogiannopoulos, Yoav Nir, Rich Salz, Kristof Teichel, Paul Lambert, Ben Laurie, Eliot Lear, Nikos Mavrogiannopoulos, Yoav
Nir, Rich Salz, Rene Struik, Kristof Teichel, Martin Thompson,
Jeffrey Walton, Nico Williams, and Peter Yee for their review and Jeffrey Walton, Nico Williams, and Peter Yee for their review and
insightful comments. While some of these people do not agree with insightful comments. While some of these people do not agree with
some aspects of this document, the discussion that resulted for their some aspects of this document, the discussion that resulted for their
comments has certainly resulted in a better document. 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
 End of changes. 22 change blocks. 
69 lines changed or deleted 171 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/