< draft-iab-crypto-alg-agility-03.txt   draft-iab-crypto-alg-agility-04.txt >
Internet-Draft R. Housley Internet-Draft R. Housley
Intended Status: Best Current Practice Vigil Security Intended Status: Best Current Practice Vigil Security
Expires: 2 November 2015 1 May 2015 Expires: 23 November 2015 22 May 2015
Guidelines for Cryptographic Algorithm Agility Guidelines for Cryptographic Algorithm Agility
<draft-iab-crypto-alg-agility-03.txt> and Selecting Mandatory-to-Implement Algorithms
<draft-iab-crypto-alg-agility-04.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 algorithm suite to another over time. one mandatory-to-implement algorithm suite to another over time.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 24 skipping to change at page 2, line 24
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. algorithm suite or cipher suite. In a protocol, algorithm
identifiers might name a single cryptographic algorithm or a full
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. For the protocol designer, this means that one suites of algorithms. Ideally, implementations will also provide a
or more algorithm identifier must be carried, the set of mandatory- way to measure when deployed implementations have shifted away from
to-implement algorithms will change over time, and an IANA registry the old algorithms and to the better ones. For the protocol
of algorithm identifiers will be needed. These algorithm identifiers designer, algorithm agility means that one or more algorithm
might name a single cryptographic algorithm or a suite of algorithms. identifier must be supported, the set of mandatory-to-implement
algorithms will change over time, and an IANA registry of algorithm
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. Ideally, and to deprecate or disable older, less desirable ones. In a perfect
this takes place before the older algorithm or suite of algorithms is world, this takes place before the older algorithm or suite of
catastrophically weakened. Experience shows that many people are algorithms is catastrophically weakened. However, experience has
unwilling to disable older weaker algorithms; it seems that these shown that many people are unwilling to disable older weaker
people prefer to live with weaker algorithms, sometimes seriously algorithms; it seems that these people prefer to live with weaker
flawed ones, to maintain interoperability with older software well algorithms, sometimes seriously flawed ones, to maintain
after experts recommend migration. interoperability with older software well after experts recommend
migration.
1.1. Terminology 1.1. Terminology
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document, are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Algorithm Agility Guidelines 2. Algorithm Agility Guidelines
These guidelines are for use by IETF working groups and protocol These guidelines are for use by IETF working groups and protocol
authors for IETF protocols that make use of cryptographic algorithms. authors for IETF protocols that make use of cryptographic algorithms.
2.1. Algorithm Identifiers 2.1. Algorithm Identifiers
IETF protocols that make use of cryptographic algorithms MUST carry IETF protocols that make use of cryptographic algorithms MUST support
one or more algorithm or suite identifier. one or more algorithm or suite identifier. The identifier might be
explicitly carried in the protocol. Alternatively, it can configured
by a management mechanism. For example, an entry in a key table that
includes a key value and an algorithm identifier might be sufficient.
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 suite of algorithms. Other approaches carry one identifier for a full suite of algorithms.
Both approaches are used in IETF protocols. Designers are encouraged Both approaches are used in IETF protocols. Designers are encouraged
to pick one of these approaches and use it consistently throughout to pick one of these approaches and use it consistently throughout
the protocol or family of protocols. Suite identifiers make it the protocol or family of protocols. Suite identifiers make it
easier for the protocol designer to ensure that the algorithm easier for the protocol designer to ensure that the algorithm
selections are complete and compatible for future assignments. selections are complete and compatible for future assignments.
However, suite identifiers inherently face a combinatoric explosion However, suite identifiers inherently face a combinatoric explosion
as new algorithms are defined. Algorithm identifiers, on the other as new algorithms are defined. Algorithm identifiers, on the other
hand, impose a burden on implementations by forcing a determination hand, impose a burden on implementations by forcing a determination
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.
In the IPsec protocol suite, IKE [RFC2409][RFC4306] carries the In the IPsec protocol suite, IKEv2 [RFC7296] carries the algorithm
algorithm identifiers for AH and ESP [RFC4302][RFC4303]. Such identifiers for AH [RFC4302] and ESP [RFC4303]. Such separation is a
separation is a completely fine design choice. In contrast, TLS completely fine design choice. In contrast, TLS [RFC5246] carries
[RFC5246] carries cipher suite identifiers, which is also a cipher suite identifiers, which is also a completely fine design
completely fine design choice. choice.
An IANA registry SHOULD be used for these algorithm or suite An IANA registry SHOULD be used for these algorithm or suite
identifiers. identifiers. Once an algorithm identifier is added to the registry,
it should not be changed or removed. However, it is desirable to
mark a registry entry as deprecated when implementation is no longer
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 mandatory-to-implement algorithm or
suite. Note that this is not done for protocols that are embedded in suite. Note that this is not done for protocols that are embedded in
other protocols, where the system-level protocol specification other protocols, where the system-level protocol specification
identifies the mandatory-to-implement algorithm or suite. For identifies the mandatory-to-implement algorithm or suite. For
skipping to change at page 4, line 22 skipping to change at page 4, line 33
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
small. To do so, the set of algorithms will necessarily change over
time, and the transition SHOULD happen before the algorithms in the
current set have weakened to the breaking point.
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].
Symmetric keys used for protection of long-term values SHOULD be at Guidance on cryptographic key size for symmetric keys can be found in
least 128 bits. BCP 195 [RFC7525].
2.3. Transition from Weak Algorithms 2.3. Transition from Weak Algorithms
Transition from an old algorithm that is found to be weak can be Transition from an old algorithm that is found to be weak can be
tricky. It is of course straightforward to specify the use of a new, tricky. It is of course straightforward to specify the use of a new,
better algorithm. And then, when the new algorithm is widely better algorithm. And then, when the new algorithm is widely
deployed, the old algorithm ought no longer be used. However, deployed, the old algorithm ought no longer be used. However,
knowledge about the implementation and deployment of the new knowledge about the implementation and deployment of the new
algorithm will always be imperfect, so one cannot be completely algorithm will always be imperfect, so one cannot be completely
assured of interoperability with the new algorithm. assured of interoperability with the new algorithm.
To facilitate transition, protocols MUST be able to advertise which Algorithm transition is naturally facilitated as part of an algorithm
algorithms are supported. This may naturally occur as part of an selection or negotiation mechanism. Protocols MUST facilitate the
algorithm selection or negotiation mechanism, and other times a selection to the best algorithm or suite that is supported by all
mechanism is needed to determine whether the new algorithm has been communicating peers. In addition, a mechanism is needed to determine
deployed. For example, the DNSSEC EDNS0 option [RFC6975] measures whether the new algorithm has been deployed. For example, the DNSSEC
the acceptance and use of new digital signing algorithms. EDNS0 option [RFC6975] measures the acceptance and use of new digital
signing algorithms.
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.
skipping to change at page 5, line 28 skipping to change at page 5, line 46
2.4. Balance Security Strength 2.4. Balance Security Strength
When selecting a suite of cryptographic algorithms, the strength of When selecting a suite of cryptographic algorithms, the strength of
each algorithm SHOULD be considered. It needs to be considered at each algorithm SHOULD be considered. It needs to be considered at
the time a protocol is designed. It also needs to be considered at the time a protocol is designed. It also needs to be considered at
the time a protocol implementation is deployed and configured. the time a protocol implementation is deployed and configured.
Advice from from experts is useful, but in reality, it is not often Advice from from experts is useful, but in reality, it is not often
available to system administrators that are deploying and configuring available to system administrators that are deploying and configuring
a protocol implementation. For this reason, protocol designers a protocol implementation. For this reason, protocol designers
SHOULD provide clear guidance to implementors, leading to balanced SHOULD provide clear guidance to implementors, leading to balanced
options being available at the time of deployment and configuration. options being available at the time of deployment and configuration.
Cipher suites include Diffie-Hellman or RSA without specifying a Cipher suites include Diffie-Hellman or RSA without specifying a
particular public key length. If the algorithm identifier or suite particular public key length. If the algorithm identifier or suite
identifier named a particular public key length, migration to longer identifier named a particular public key length, migration to longer
ones would be more difficult. On the other hand, inclusion of a ones would be more difficult. On the other hand, inclusion of a
public key length would make it easier to migrate away from short public key length would make it easier to migrate away from short
ones when computational resources available to attacker dictate the ones when computational resources available to attacker dictate the
need to do so. Therefore, flexibility on asymmetric key length is need to do so. Therefore, flexibility on asymmetric key length is
both desirable and undesirable at the same time. both desirable and undesirable at the same time.
skipping to change at page 7, line 20 skipping to change at page 7, line 36
cryptographic algorithms. In this situation, a flaw in the cryptographic algorithms. In this situation, a flaw in the
mandatory-to-implement algorithm may allow an attacker to influence mandatory-to-implement algorithm may allow an attacker to influence
the choices of the other algorithms. the choices of the other algorithms.
Performance is always a factor is selecting cryptographic algorithms. Performance is always a factor is selecting cryptographic algorithms.
In many algorithms, shorter keys offer higher performance, but less In many algorithms, shorter keys offer higher performance, but less
security. Performance and security need to be balanced. Yet, all security. Performance and security need to be balanced. Yet, all
algorithms age, and the advances in computing power available to the algorithms age, and the advances in computing power available to the
attacker will eventually make any algorithm obsolete. For this attacker will eventually make any algorithm obsolete. For this
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 develop, deploy, and configure new
algorithms. algorithms.
skipping to change at page 8, line 12 skipping to change at page 8, line 29
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.
4. Cryptographic Algorithm Specifications 4. Cryptographic Algorithm Specifications
There are tradeoffs between the number of cryptographic algorithms There are tradeoffs between the number of cryptographic algorithms
that are supported, time to deploy a new algorithm, and protocol that are supported, time to deploy a new algorithm, and protocol
complexity. This section provides some of the insights about the complexity. This section provides some of the insights about the
tradeoff faced by protocol designers. tradeoff faced by protocol designers.
Ideally, two independent sets of mandatory-to-implement algorithms
will be specified, allowing for a primary suite and a secondary
suite. This approach ensures that the secondary suite is widely
deployed if a flaw is found in the primary one.
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 be well studied, giving rise to significant algorithms ought to have a public stable specification and public
confidence. The selected algorithms need to be resistant to side- documentation that it has been well studied, giving rise to
channel attacks as well as meeting the performance, power, and code significant confidence. The IETF has alway had a preference for
size requirements on a wide variety of platforms. In addition, unencumbered algorithms. The selected algorithms need to be
inclusion of too many alternatives may add complexity to algorithm resistant to side-channel attacks as well as meeting the performance,
selection or negotiation. power, and code size requirements on a wide variety of platforms. In
addition, inclusion of too many alternatives may add complexity to
algorithm selection or negotiation.
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 9, line 32 skipping to change at page 10, line 9
the selected algorithms need to be routinely exercised to ensure the selected algorithms need to be routinely exercised to ensure
quality implementation. This is not always easy to do, especially if quality implementation. This is not always easy to do, especially if
the various selected algorithms require different credentials. the various selected algorithms require different credentials.
Obtaining multiple credentials for the same installation is an Obtaining multiple credentials for the same installation is an
unacceptable burden on system administrators. Also, the manner by unacceptable burden on system administrators. Also, the manner by
which system administrators are advised to switch algorithms or which system administrators are advised to switch algorithms or
suites is at best ad hoc, and at worst entirely absent. suites is at best ad hoc, and at worst entirely absent.
4.3. Picking One True Cipher Suite Can Be Harmful 4.3. Picking One True Cipher Suite Can Be Harmful
After careful study and evaluation, the protocol designer could In the past, protocol designers have chosen one cryptographic
select the one true cipher suite. Since algorithms age, such a algorithm or suite, and then tied many protocol details to that
decision cannot be stable forever, so a version number is needed to selection. It is much better to plan for algorithm transition,
signal which algorithm that is being used. This has at least two either because a mistake is made in the initial selection or because
desirable consequences. First, the protocol is simpler since there the protocol is successfully used for a long time and the algorithm
is no need for algorithm negotiation. Second, system administrators becomes week with age. Either way, the design should enable
do not need to make any algorithm-related configuration decisions. transition.
However, the only way to respond to news that the an algorithm that
is part of the one true cipher suite has been broken is to update the Protocol designers are sometimes mislead by the simplicity that
protocol specification to the next version, implement the new results from selecting one true algorithm or suite. Since algorithms
specification, and then get it deployed. age, the selection cannot be stable forever. Even the most simple
protocol needs a version number to signal which algorithm that is
being used. This approach has at least two desirable consequences.
First, the protocol is simpler because there is no need for algorithm
negotiation. Second, system administrators do not need to make any
algorithm-related configuration decisions. However, the only way to
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
to the next version, implement the new specification, and then get it
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. 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.
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
skipping to change at page 10, line 40 skipping to change at page 11, line 26
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
attacks. Support for many algorithm alternatives is also harmful, as attacks. Support for many algorithm alternatives is also harmful, as
discussed in Section 4.1. Both of these can lead to portions of the discussed in Section 4.1. Both of these can lead to portions of the
implementation that are rarely used, increasing the opportunity for implementation that are rarely used, increasing the opportunity for
undiscovered exploitable implementation bugs. undiscovered exploitable implementation bugs.
4.6. Providing Notice
Fortunately, catastrophic algorithm failures without warning are
rare. More often, algorithm transition is the result of age. For
example, the transition from DES to Triple-DES to AES took place over
decades, causing a shift in symmetric block cipher strength from 56
bits to 112 bits to 128 bits. Where possible, authors SHOULD provide
notice to implementers about expected algorithm transitions. One
approach is to use SHOULD+, SHOULD-, and MUST- in the specification
of algorithms.
SHOULD+ This term means the same as SHOULD. However, it is
likely that an algorithm marked as SHOULD+ will be
promoted to a MUST in the future.
SHOULD- This term means the same as SHOULD. However, it is
likely that an algorithm marked as SHOULD- will be
deprecated to a MAY or worse in the future.
MUST- This term means the same as MUST. However, it is
expected that an algorithm marked as MUST- will be
downgraded in the future. Although the status of the
algorithm will be determined at a later time, it is
reasonable to expect that a the status of a MUST-
algorithm will remain at least a SHOULD or a SHOULD-.
5. Security Considerations 5. Security Considerations
This document provides guidance to working groups and protocol This document provides guidance to working groups and protocol
designers. The security of the Internet is improved when broken or designers. The security of the Internet is improved when broken or
weak cryptographic algorithms can be easily replaced with strong weak cryptographic algorithms can be easily replaced with strong
ones. ones.
From a software development and maintenance perspective, From a software development and maintenance perspective,
cryptographic algorithms can often be added and removed without cryptographic algorithms can often be added and removed without
making changes to surrounding data structures, protocol parsing making changes to surrounding data structures, protocol parsing
routines, or state machines. This approach separates the routines, or state machines. This approach separates the
cryptographic algorithm implementation from the rest of the code, cryptographic algorithm implementation from the rest of the code,
which makes it easier to tackle special security concerns such as key which makes it easier to tackle special security concerns such as key
exposure and constant-time execution. exposure and constant-time execution.
The situation is different for hardware, for both tiny devices and The situation is different for hardware, for both tiny devices and
very high-end data center equipment. Many tiny devices do not very high-end data center equipment. Many tiny devices do not
include the ability to update the firmware at all. Even if the include the ability to update the firmware at all. Even if the
firmware can be updated, tiny devices are often deployed in places firmware can be updated, tiny devices are often deployed in places
that make it very inconvenient to do so. High-end data center that make it very inconvenient to do so. High-end data center
skipping to change at page 11, line 24 skipping to change at page 12, line 37
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
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, and it is no longer considered operations is called MAC-then-encrypt, which actually involves MAC
secure [BN][K]. As a result, a mechanism was specified to use computation, padding, and then encryption. This is no longer
encrypt-then-MAC instead [RFC7366]. Future versions of TLS are considered secure [BN][K]. As a result, a mechanism was specified to
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 protected stored data. For example,
S/MIME [RFC5751] can protect a message kept in a mailbox. To recover S/MIME [RFC5751] can protect a message kept in a mailbox. To recover
the protected stored data, protocol implementations need to support the protected stored data, protocol implementations need to support
older algorithms, even when they no longer use the older algorithms older algorithms, even when they no longer use the older algorithms
for the protection of new stored data. for the 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
algorithms are actually being used, and if they are not, future
releases should remove them. In addition, unused algorithms or
suites SHOULD be marked as deprecated in the IANA registry. In
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.
6. Normative References 6. IANA Considerations
This document does not establish any new IANA registries, nor does it
add any entries to existing registries.
This document does RECOMMEND a convention for new registries for
cryptographic algorithm or suite identifiers. Once an algorithm or
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
registry entry as deprecated when implementation is no longer
advisable.
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public
Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766,
April 2004. April 2004.
7. Informative References 8. Informative References
[BEAST] http://en.wikipedia.org/wiki/ [BEAST] http://en.wikipedia.org/wiki/
Transport_Layer_Security#BEAST_attack. Transport_Layer_Security#BEAST_attack.
[BN] Bellare, M. and C. Namprempre, "Authenticated Encryption: [BN] Bellare, M. and C. Namprempre, "Authenticated Encryption:
Relations among notions and analysis of the generic Relations among notions and analysis of the generic
composition paradigm", Proceedings of AsiaCrypt '00, composition paradigm", Proceedings of AsiaCrypt '00,
Springer-Verlag LNCS No. 1976, p. 531, December 2000. Springer-Verlag LNCS No. 1976, p. 531, December 2000.
[GCM] Dworkin, M, "Recommendation for Block Cipher Modes of [GCM] Dworkin, M, "Recommendation for Block Cipher Modes of
skipping to change at page 12, line 36 skipping to change at page 14, line 17
Special Publication 800-30D, November 2007. Special Publication 800-30D, November 2007.
[K] Krawczyk, H., "The Order of Encryption and Authentication [K] Krawczyk, H., "The Order of Encryption and Authentication
for Protecting Communications (or: How Secure Is SSL?)", for Protecting Communications (or: How Secure Is SSL?)",
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.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[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.
[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.
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, 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.
[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.
Kivinen, "Internet Key Exchange Protocol Version 2
(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)",
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
for Secure Use of Transport Layer Security (TLS) and
Datagram Transport Layer Security (DTLS)", RFC 7525,
BCP 195, May 2015.
[WEP] http://en.wikipedia.org/wiki/Wired_Equivalent_Privacy [WEP] http://en.wikipedia.org/wiki/Wired_Equivalent_Privacy
[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,
 End of changes. 29 change blocks. 
67 lines changed or deleted 148 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/