Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 7696 Vigil Security
BCP: 201 November 2015
Category: Best Current Practice
ISSN: 2070-1721
Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 7696 Vigil Security
BCP: 201 November 2015
Category: Best Current Practice
ISSN: 2070-1721
Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms
密码算法敏捷性和选择强制算法实现指南
Abstract
摘要
Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature. Communicating peers must support a common set of cryptographic algorithms for these mechanisms to work properly. This memo provides guidelines to ensure that protocols have the ability to migrate from one mandatory-to-implement algorithm suite to another over time.
许多IETF协议使用加密算法来提供机密性、完整性、身份验证或数字签名。通信对等方必须支持一组通用的加密算法，才能使这些机制正常工作。本备忘录提供了指南，以确保协议能够随着时间的推移从一个强制实现算法套件迁移到另一个。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7696.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7696.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Algorithm Agility Guidelines . . . . . . . . . . . . . . . . . 3
2.1. Algorithm Identifiers . . . . . . . . . . . . . . . . . . 4
2.2. Mandatory-to-Implement Algorithms . . . . . . . . . . . . 5
2.2.1. Platform Specifications . . . . . . . . . . . . . . . 5
2.2.2. Cryptographic Key Size . . . . . . . . . . . . . . . . 5
2.2.3. Providing Notice of Expected Changes . . . . . . . . . 6
2.3. Transitioning from Weak Algorithms . . . . . . . . . . . . 6
2.4. Algorithm Transition Mechanisms . . . . . . . . . . . . . 7
2.5. Cryptographic Key Management . . . . . . . . . . . . . . . 8
2.6. Preserving Interoperability . . . . . . . . . . . . . . . 8
2.7. Balancing Security Strength . . . . . . . . . . . . . . . 9
2.8. Balancing Protocol Complexity . . . . . . . . . . . . . . 10
2.9. Opportunistic Security . . . . . . . . . . . . . . . . . . 10
3. Cryptographic Algorithm Specifications . . . . . . . . . . . . 11
3.1. Choosing Mandatory-to-Implement Algorithms . . . . . . . . 11
3.2. Too Many Choices Can Be Harmful . . . . . . . . . . . . . 12
3.3. Picking One True Cipher Suite Can Be Harmful . . . . . . . 13
3.4. National Cipher Suites . . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Normative References . . . . . . . . . . . . . . . . . . . . . 16
7. Informative References . . . . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Algorithm Agility Guidelines . . . . . . . . . . . . . . . . . 3
2.1. Algorithm Identifiers . . . . . . . . . . . . . . . . . . 4
2.2. Mandatory-to-Implement Algorithms . . . . . . . . . . . . 5
2.2.1. Platform Specifications . . . . . . . . . . . . . . . 5
2.2.2. Cryptographic Key Size . . . . . . . . . . . . . . . . 5
2.2.3. Providing Notice of Expected Changes . . . . . . . . . 6
2.3. Transitioning from Weak Algorithms . . . . . . . . . . . . 6
2.4. Algorithm Transition Mechanisms . . . . . . . . . . . . . 7
2.5. Cryptographic Key Management . . . . . . . . . . . . . . . 8
2.6. Preserving Interoperability . . . . . . . . . . . . . . . 8
2.7. Balancing Security Strength . . . . . . . . . . . . . . . 9
2.8. Balancing Protocol Complexity . . . . . . . . . . . . . . 10
2.9. Opportunistic Security . . . . . . . . . . . . . . . . . . 10
3. Cryptographic Algorithm Specifications . . . . . . . . . . . . 11
3.1. Choosing Mandatory-to-Implement Algorithms . . . . . . . . 11
3.2. Too Many Choices Can Be Harmful . . . . . . . . . . . . . 12
3.3. Picking One True Cipher Suite Can Be Harmful . . . . . . . 13
3.4. National Cipher Suites . . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Normative References . . . . . . . . . . . . . . . . . . . . . 16
7. Informative References . . . . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature. For interoperability, communicating peers must support a common set of cryptographic algorithms. In most cases, a combination of compatible cryptographic algorithms will be used to provide the desired security services. The set of cryptographic algorithms being used at a particular time is often referred to as a cryptographic algorithm suite or cipher suite. In a protocol, algorithm identifiers might name a single cryptographic algorithm or a full suite of algorithms.
许多IETF协议使用加密算法来提供机密性、完整性、身份验证或数字签名。为了实现互操作性，通信对等方必须支持一组通用的加密算法。在大多数情况下，将使用兼容加密算法的组合来提供所需的安全服务。在特定时间使用的一组加密算法通常被称为加密算法套件或密码套件。在协议中，算法标识符可以命名单个加密算法或一整套算法。
Cryptographic algorithms age; they become weaker with time. As new cryptanalysis techniques are developed and computing capabilities improve, the work required to break a particular cryptographic algorithm will reduce, making an attack on the algorithm more feasible for more attackers. While it is unknown how cryptoanalytic attacks will evolve, it is certain that they will get better. It is
密码算法时代；随着时间的推移，它们变得越来越弱。随着新的密码分析技术的发展和计算能力的提高，破解特定密码算法所需的工作量将减少，使得对该算法的攻击对于更多的攻击者来说更加可行。虽然还不知道密码分析攻击将如何演变，但可以肯定的是，它们会变得更好。它是
unknown how much better they will become or when the advances will happen. Protocol designers need to assume that advances in computing power or advances in cryptoanalytic techniques will eventually make any algorithm obsolete. For this reason, protocols need mechanisms to migrate from one algorithm suite to another over time.
不知道他们会变得好多少，也不知道什么时候会有进步。协议设计者需要假设计算能力的进步或密码分析技术的进步最终会使任何算法过时。出于这个原因，协议需要机制来随时间从一个算法套件迁移到另一个算法套件。
Algorithm agility is achieved when a protocol can easily migrate from one algorithm suite to another more desirable one, over time. For the protocol implementer, this means that implementations should be modular to easily accommodate the insertion of new algorithms or suites of algorithms. Ideally, implementations will also provide a way to measure when deployed implementations have shifted away from the old algorithms and to the better ones. For the protocol designer, algorithm agility means that one or more algorithm or suite identifiers must be supported, the set of mandatory-to-implement algorithms will change over time, and an IANA registry of algorithm identifiers will be needed.
当协议可以随时间从一个算法套件轻松迁移到另一个更理想的算法套件时，就可以实现算法敏捷性。对于协议实现者来说，这意味着实现应该是模块化的，以方便插入新的算法或算法套件。理想情况下，实现还将提供一种方法来衡量部署的实现何时从旧算法转移到更好的算法。对于协议设计者来说，算法敏捷性意味着必须支持一个或多个算法或套件标识符，实现算法的强制设置将随着时间的推移而改变，并且需要算法标识符的IANA注册表。
Algorithm identifiers by themselves are not sufficient to ensure easy migration. Action by people that maintain implementations and operate services is needed to develop, deploy, and adjust configuration settings to enable the new more desirable algorithms and to deprecate or disable older, less desirable ones. For various reasons, most notably interoperability concerns, experience has shown that it has proven difficult for implementers and administrators to remove or disable weak algorithms. Further, the inability of legacy systems and resource-constrained devices to support new algorithms adds to those concerns. As a result, people live with weaker algorithms, sometimes seriously flawed ones, well after experts recommend migration.
算法标识符本身不足以确保易于迁移。维护实现和操作服务的人员需要采取行动来开发、部署和调整配置设置，以启用新的更理想的算法，并弃用或禁用旧的、不太理想的算法。由于各种原因，尤其是互操作性问题，经验表明，实施者和管理员很难删除或禁用弱算法。此外，传统系统和资源受限设备无法支持新算法，这增加了这些担忧。因此，在专家推荐迁移之后，人们生活在较弱的算法中，有时是有严重缺陷的算法。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
These guidelines are for use by IETF working groups and protocol authors for IETF protocols that make use of cryptographic algorithms. Past attempts at algorithm agility have not been completely successful, and this section provides some insights from those experiences.
这些指南供IETF工作组和使用加密算法的IETF协议的协议作者使用。过去在算法敏捷性方面的尝试并没有完全成功，本节将从这些经验中提供一些见解。
IETF protocols that make use of cryptographic algorithms MUST support one or more algorithms or suites. The protocol MUST include a mechanism to identify the algorithm or suite that is being used. An algorithm identifier might be explicitly carried in the protocol. Alternatively, a management mechanism can be used to identify the algorithm. For example, an entry in a key table that includes a key value and an algorithm identifier might be sufficient.
使用加密算法的IETF协议必须支持一个或多个算法或套件。协议必须包括一种机制，用于识别正在使用的算法或套件。协议中可能会显式携带算法标识符。或者，可以使用管理机制来识别算法。例如，键表中包含键值和算法标识符的条目可能就足够了。
If a protocol does not carry an algorithm identifier, then the protocol version number or some other major change is needed to transition from one algorithm to another. The inclusion of an algorithm identifier is a minimal step toward cryptographic algorithm agility.
如果协议没有算法标识符，则需要协议版本号或其他一些重大更改，以从一种算法转换到另一种算法。包含算法标识符是实现密码算法敏捷性的最小步骤。
Sometimes a combination of protocol version number and explicit algorithm or suite identifiers is appropriate. For example, the Transport Layer Security (TLS) [RFC5246] version number names the default key derivation function, and the cipher suite identifier names the rest of the needed algorithms.
有时，协议版本号和显式算法或套件标识符的组合是合适的。例如，传输层安全性（TLS）[RFC5246]版本号命名默认密钥派生函数，密码套件标识符命名其余所需算法。
Some approaches carry one identifier for each algorithm that is used. Other approaches carry one identifier for a full suite of algorithms. Both approaches are used in IETF protocols. Designers are encouraged to pick one of these approaches and use it consistently throughout the protocol or family of protocols. Suite identifiers make it easier for the protocol designer to ensure that the algorithm selections are complete and compatible for future assignments. However, suite identifiers inherently face a combinatoric explosion as new algorithms are defined. Algorithm identifiers, on the other hand, impose a burden on implementations by forcing a determination at run-time regarding which algorithm combinations are acceptable.
有些方法为所使用的每个算法携带一个标识符。其他方法为一整套算法提供一个标识符。这两种方法都在IETF协议中使用。鼓励设计人员从这些方法中选择一种，并在整个协议或协议系列中始终如一地使用它。套件标识符使协议设计者更容易确保算法选择完整且兼容未来的分配。然而，随着新算法的定义，套件标识符必然面临组合爆炸。另一方面，算法标识符在运行时强制确定哪些算法组合是可接受的，从而给实现带来负担。
Regardless of the approach used, protocols historically negotiate the symmetric cipher and cipher mode together to ensure that they are compatible.
无论使用哪种方法，协议在历史上都会协商对称密码和密码模式，以确保它们兼容。
In the IPsec protocol suite, the Internet Key Exchange Protocol version 2 (IKEv2) [RFC7296] carries the algorithm identifiers for the Authentication Header (AH) [RFC4302] and the Encapsulating Security Payload (ESP) [RFC4303]. Such separation is a completely fine design choice. In contrast, TLS [RFC5246] carries cipher suite identifiers, which is also a completely fine design choice.
在IPsec协议套件中，Internet密钥交换协议版本2（IKEv2）[RFC7296]携带认证头（AH）[RFC4302]和封装安全有效负载（ESP）[RFC4303]的算法标识符。这种分离是一种完全精细的设计选择。相比之下，TLS[RFC5246]携带密码套件标识符，这也是一个非常好的设计选择。
An IANA registry SHOULD be used for these algorithm or suite 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.
IANA注册表应用于这些算法或套件标识符。将算法标识符添加到注册表后，不应更改或删除它。但是，当不再建议实现时，最好将注册表项标记为已弃用。
For secure interoperability, BCP 61 [RFC3365] recognizes that communicating peers that use cryptographic mechanisms must support a common set of strong cryptographic algorithms. For this reason, IETF protocols that employ cryptography MUST specify one or more strong mandatory-to-implement algorithms or suites. This does not require all deployments to use this algorithm or suite, but it does require that it be available to all deployments.
为了实现安全互操作性，BCP 61[RFC3365]认识到使用加密机制的通信对等方必须支持一组通用的强加密算法。因此，采用密码学的IETF协议必须指定一个或多个强制执行算法或套件。这并不要求所有部署都使用此算法或套件，但要求它对所有部署都可用。
The IETF needs to be able to change the mandatory-to-implement algorithms over time. It is highly desirable to make this change without updating the base protocol specification. To achieve this goal, it is RECOMMENDED that the base protocol specification includes a reference to a companion algorithms document, allowing the update of one document without necessarily requiring an update to the other. This division also facilitates the advancement of the base protocol specification on the standards maturity ladder even if the algorithm document changes frequently.
IETF需要能够随着时间的推移改变强制执行算法。非常希望在不更新基本协议规范的情况下进行此更改。为了实现这一目标，建议基本协议规范包括对配套算法文档的引用，允许更新一个文档而无需更新另一个文档。即使算法文档频繁更改，该划分也有助于在标准成熟度阶梯上推进基本协议规范。
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.
IETF应保持实现算法的强制集合较小。要做到这一点，算法集必然会随着时间的推移而改变，而这种转变应该在当前集合中的算法减弱到临界点之前发生。
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 to make use of CMS and make different mandatory-to-implement algorithm choices.
注意，对于嵌入在其他协议中的协议，未指定强制实现算法或套件；在这些情况下，系统级协议规范确定了实现算法或套件的必要条件。例如，S/MIME[RFC5751]使用加密消息语法（CMS）[RFC5652]，S/MIME指定实现算法的强制命令，而不是CMS。这种方法允许其他协议使用CMS并强制执行不同的算法选择。
Some cryptographic algorithms are inherently tied to a specific key size, but others allow many different key sizes. Likewise, some algorithms support parameters of different sizes, such as integrity
一些加密算法固有地与特定的密钥大小相关联，但另一些算法允许许多不同的密钥大小。同样，一些算法支持不同大小的参数，例如完整性
check values or nonces. The algorithm specification MUST identify the specific key sizes and parameter sizes that are to be supported. When more than one key size is available, expect the mandatory-to-implement key size to increase over time.
检查值或nonce。算法规范必须确定要支持的特定密钥大小和参数大小。当有多个密钥大小可用时，期望强制实现的密钥大小随时间增加。
Guidance on cryptographic key size for asymmetric keys can be found in BCP 86 [RFC3766].
有关非对称密钥的加密密钥大小的指导，请参见BCP 86[RFC3766]。
Guidance on cryptographic key size for symmetric keys can be found in BCP 195 [RFC7525].
有关对称密钥的加密密钥大小的指南，请参见BCP 195[RFC7525]。
Fortunately, algorithm failures without warning are rare. More often, algorithm transition is the result of age. For example, the transition from DES to Triple-DES to AES took place over decades, causing a shift in symmetric block cipher strength from 56 bits to 112 bits to 128 bits. Where possible, authors SHOULD provide notice to implementers about expected algorithm transitions. One approach that was first used in RFC 4307 [RFC4307] is to use SHOULD+, SHOULD-, and MUST- in the specification of algorithms. The definitions below are slightly modified from those in RFC 4307.
幸运的是，没有警告的算法故障很少。通常，算法转换是年龄的结果。例如，从DES到三重DES再到AES的转换发生了几十年，导致对称分组密码强度从56位转移到112位再到128位。在可能的情况下，作者应该向实现者提供关于预期算法转换的通知。RFC 4307[RFC4307]中首次使用的一种方法是在算法规范中使用SHOULD+、SHOULD-、MUST-。以下定义与RFC 4307中的定义略有不同。
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+这个词的意思与SHOULD相同。但是，标记为SHOULD+的算法很可能会在将来被提升为必选项。
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-.
必须-该术语的含义与必须相同。然而，预计标记为“必须”的算法将在将来降级。虽然算法的状态将在稍后确定，但可以合理地预期，必须算法的状态将至少保持为应该或应该。
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, better algorithm. And then, when the new algorithm is widely deployed, the old algorithm ought no longer be used. However, knowledge about the implementation and deployment of the new algorithm will always be imperfect, so one cannot be completely assured of interoperability with the new algorithm.
从一个被发现很弱的旧算法过渡可能很棘手。当然，指定使用新的、更好的算法是很简单的。然后，当新算法被广泛部署时，旧算法不应该再被使用。然而，关于新算法的实现和部署的知识总是不完善的，因此不能完全保证与新算法的互操作性。
Algorithm transition is naturally facilitated as part of an algorithm selection or negotiation mechanism. Protocols traditionally select the best algorithm or suite that is supported by all communicating peers and acceptable by their policies. In addition, a mechanism is needed to determine whether the new algorithm has been deployed. For example, SMIMECapabilities [RFC5751] allows S/MIME mail user agents 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.
作为算法选择或协商机制的一部分，算法转换自然会得到促进。传统上，协议选择所有通信对等方支持且其策略可接受的最佳算法或套件。此外，还需要一种机制来确定是否部署了新算法。例如，SMIMECapabilities[RFC5751]允许S/MIME邮件用户代理按优先顺序共享他们愿意使用的算法列表。例如，DNSSEC EDNS0选项[RFC6975]衡量新数字签名算法的接受和使用情况。
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.
在资源公钥基础设施（RPKI）中，需要一个全球公认的数字签名。BCP 182[RFC6916]提供了一种过渡方法，引入第二个签名算法，然后逐步淘汰原来的签名算法。
In the worst case, the old algorithm may be found to be tragically flawed, permitting a casual attacker to download a simple script to break it. Sadly, this has happened when a secure algorithm is used incorrectly or used with poor key management, resulting in a weak cryptographic algorithm suite. In such situations, the protection offered by the algorithm is severely compromised, perhaps to the point that one wants to stop using the weak suite altogether, rejecting offers to use the weak suite well before the new suite is widely deployed.
在最坏的情况下，可能会发现旧算法存在严重缺陷，允许偶然的攻击者下载一个简单的脚本来破坏它。不幸的是，当一个安全算法被错误地使用或密钥管理不好时，就会发生这种情况，导致加密算法套件很弱。在这种情况下，算法提供的保护受到严重损害，可能会导致人们希望完全停止使用弱套件，在新套件广泛部署之前拒绝使用弱套件。
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 installation can select a date on their own.
无论如何，总有一天，人们会拒绝使用旧的、脆弱的算法或套件。这可能发生在卖旗日，或者每个安装都可以自己选择一个日期。
Cryptographic algorithm selection or negotiation SHOULD be integrity protected. If selection is not integrity protected, then the protocol will be subject to a downgrade attack. Without integrity protection of algorithm or suite selection, the attempt to transition to a new algorithm or suite may introduce new opportunities for downgrade attacks.
加密算法选择或协商应受到完整性保护。如果选择不受完整性保护，则协议将受到降级攻击。如果没有算法或套件选择的完整性保护，尝试转换到新算法或套件可能会带来降级攻击的新机会。
Transition mechanisms need to consider the algorithm that is used to provide integrity protection for algorithm negotiation itself.
转换机制需要考虑用于为算法协商本身提供完整性保护的算法。
If a protocol specifies a single mandatory-to-implement integrity algorithm, eventually that algorithm will be found to be weak.
如果一个协议指定了一个强制实现完整性算法，那么最终会发现该算法很弱。
Extra care is needed when a mandatory-to-implement algorithm is used to provide integrity protection for the negotiation of other cryptographic algorithms. In this situation, a flaw in the mandatory-to-implement algorithm may allow an attacker to influence the choices of the other algorithms.
当使用强制实现算法为其他加密算法的协商提供完整性保护时，需要格外小心。在这种情况下，强制实现算法中的漏洞可能会允许攻击者影响其他算法的选择。
Traditionally, protocol designers have avoided more than one approach to exchanges that establish cryptographic keys because it makes the security analysis of the overall protocol more difficult. When frameworks such as the Extensible Authentication Protocol (EAP) [RFC3748] and Simple Authentication and Security Layer (SASL) [RFC4422] are employed, key establishment is very flexible, often hiding many of the details from the application. This results in protocols that support multiple key establishment approaches. In fact, the key establishment approach itself is negotiable, which creates a design challenge to protect the negotiation of the key establishment approach before it is used to produce cryptographic keys.
传统上，协议设计人员避免使用一种以上的方法来建立加密密钥的交换，因为这使得整个协议的安全性分析更加困难。当采用可扩展身份验证协议（EAP）[RFC3748]和简单身份验证和安全层（SASL）[RFC4422]等框架时，密钥建立非常灵活，通常对应用程序隐藏许多细节。这导致协议支持多种密钥建立方法。事实上，密钥建立方法本身是可协商的，这就产生了一个设计挑战，即在密钥建立方法用于生成加密密钥之前，保护密钥建立方法的协商。
Protocols can negotiate a key establishment approach, derive an initial cryptographic key, and then authenticate the negotiation. However, if the authentication fails, the only recourse is to start the negotiation over from the beginning.
协议可以协商密钥建立方法，导出初始加密密钥，然后对协商进行身份验证。但是，如果身份验证失败，唯一的办法是从头开始协商。
Some environments will restrict the key establishment approaches by policy. Such policies tend to improve interoperability within a particular environment, but they cause problems for individuals that need to work in multiple incompatible environments.
某些环境将通过政策限制关键的建立方法。这样的策略倾向于改善特定环境中的互操作性，但它们会给需要在多个不兼容环境中工作的个人带来问题。
Cryptographic algorithm deprecation is very difficult. People do not like to introduce interoperability problems, even to preserve security. As a result, flawed algorithms are supported for far too long. The impact of legacy software and long support tails on security can be reduced by making it easy to transition from old algorithms and suites to new ones. Social pressure is often needed to cause the transition to happen.
密码算法的弃用是非常困难的。人们不喜欢引入互操作性问题，甚至是为了维护安全性。因此，有缺陷的算法被支持的时间太长了。通过简化从旧算法和套件到新算法和套件的转换，可以减少遗留软件和长期支持对安全性的影响。通常需要社会压力才能促成转型。
Implementers have been reluctant to remove deprecated algorithms or suites from server software, and server administrators have been reluctant to disable them over concerns that some party will no longer have the ability to connect to their server. Implementers and administrators want to improve security by using the best supported algorithms, but their actions are tempered by the desire to preserve connectivity. Recently, some browser vendors have started to provide
实现者不愿意从服务器软件中删除不推荐的算法或套件，服务器管理员也不愿意禁用这些算法或套件，因为担心某一方将不再能够连接到他们的服务器。实现者和管理员希望通过使用受支持的最佳算法来提高安全性，但他们的行动因希望保持连接性而受到限制。最近，一些浏览器供应商开始提供
visual warnings when a deprecated algorithm or suite is used. These visual warnings provide a new incentive to transition away from deprecated algorithms and suites, prompting customers to ask for improved security.
使用不推荐使用的算法或套件时出现可视警告。这些视觉警告提供了一种新的动力，促使客户放弃不推荐的算法和套件，要求提高安全性。
Transition in Internet infrastructure is particularly difficult. The digital signature on the certificate for an intermediate certification authority (CA) [RFC5280] is often expected to last decades, which hinders the transition away from a weak signature algorithm or short key length. Once a long-lived certificate is issued with a particular signature algorithm, that algorithm will be used by many relying parties, and none of them can stop supporting it without invalidating all of the subordinate certificates. In a hierarchical system, many subordinate certificates could be impacted by the decision to drop support for a weak signature algorithm or an associated hash function.
互联网基础设施的转型尤其困难。中间证书颁发机构（CA）[RFC5280]证书上的数字签名通常会持续几十年，这阻碍了从弱签名算法或短密钥长度过渡。一旦使用特定的签名算法颁发了长期有效的证书，该算法将被许多依赖方使用，并且在不使所有从属证书失效的情况下，所有依赖方都无法停止支持该算法。在分层系统中，许多从属证书可能会受到放弃对弱签名算法或相关哈希函数支持的决定的影响。
Organizations that have a significant influence can assist by coordinating the demise of an algorithm suite, making the transition easier for their own users as well as others.
具有重大影响的组织可以通过协调算法套件的消亡来提供帮助，使其自身用户和其他用户的过渡更容易。
When selecting or negotiating a suite of cryptographic algorithms, the strength of each algorithm SHOULD be considered. The algorithms in a suite SHOULD be roughly equal by providing comparable best-known attack work factors. However, the security service provided by each algorithm in a particular context needs to be considered when making the selection. Algorithm strength needs to be considered at the time a protocol is designed. It also needs to be considered at the time a protocol implementation is deployed and configured. Advice from experts is useful, but, in reality, such advice is often unavailable to system administrators that are deploying a protocol implementation. For this reason, protocol designers SHOULD provide clear guidance to implementers, leading to balanced options being available at the time of deployment.
在选择或协商一套加密算法时，应考虑每种算法的强度。通过提供可比较的最著名的攻击功因子，套件中的算法应该大致相等。然而，在进行选择时，需要考虑每个算法在特定上下文中提供的安全服务。在设计协议时需要考虑算法强度。在部署和配置协议实现时还需要考虑它。专家的建议很有用，但实际上，部署协议实现的系统管理员通常无法获得此类建议。因此，协议设计者应该为实现者提供明确的指导，从而在部署时提供平衡的选项。
Performance is always a factor is selecting cryptographic algorithms. Performance and security need to be balanced. Some algorithms offer flexibility in their strength by adjusting the key size, number of rounds, authentication tag size, prime group size, and so on. For example, TLS cipher suites include Diffie-Hellman or RSA without specifying a particular public key length. If the algorithm identifier or suite identifier named a particular public key length, migration to longer ones would be more difficult. On the other hand, inclusion of a public key length would make it easier to migrate away from short ones when computational resources available to attacker dictate the need to do so. The flexibility on asymmetric key length
性能始终是选择加密算法的一个因素。性能和安全性需要平衡。一些算法通过调整密钥大小、轮数、身份验证标记大小、主组大小等，在强度上提供了灵活性。例如，TLS密码套件包括Diffie Hellman或RSA，但不指定特定的公钥长度。如果算法标识符或套件标识符指定了特定的公钥长度，则迁移到更长的公钥长度将更加困难。另一方面，当攻击者可用的计算资源决定需要这样做时，包含公钥长度将更容易从短密钥迁移出去。非对称密钥长度的灵活性
has led to interoperability problems, and to avoid these problems in the future any aspect of the algorithm not specified by the algorithm identifiers need to be negotiated, including key size and parameters.
导致了互操作性问题，为了避免将来出现这些问题，需要协商算法标识符未指定的算法的任何方面，包括密钥大小和参数。
In CMS [RFC5652], a previously distributed symmetric key-encryption key can be used to encrypt a content-encryption key, which in turn is used to encrypt the content. The key-encryption and content-encryption algorithms are often different. If, for example, a message content is encrypted with a 128-bit AES key and the content-encryption key is wrapped with a 256-bit AES key, then at most 128 bits of protection is provided. In this situation, the algorithm and key size selections should ensure that the key encryption is at least as strong as the content encryption. In general, wrapping one key with another key of a different size yields the security strength of the shorter key.
在CMS[RFC5652]中，先前分发的对称密钥加密密钥可用于加密内容加密密钥，而内容加密密钥又用于加密内容。密钥加密和内容加密算法通常是不同的。例如，如果消息内容使用128位AES密钥加密，并且内容加密密钥使用256位AES密钥包装，则最多提供128位保护。在这种情况下，算法和密钥大小选择应确保密钥加密至少与内容加密一样强大。一般来说，将一个密钥与另一个不同大小的密钥包装在一起会产生较短密钥的安全强度。
Protocol designs need to anticipate changes in the supported cryptographic algorithm set over time. There are a number of ways to enable the transition, and Section 3 discusses some of the related issues.
协议设计需要预测支持的加密算法集随时间的变化。有许多方法可以实现过渡，第3节讨论了一些相关问题。
Keep implementations as simple as possible. Complex protocol negotiation provides opportunities for attack, such as downgrade attacks. Support for many algorithm alternatives is also harmful. Both of these can lead to portions of the implementation that are rarely used, increasing the opportunity for undiscovered exploitable implementation bugs.
使实现尽可能简单。复杂的协议协商为攻击提供了机会，例如降级攻击。对许多算法备选方案的支持也是有害的。这两种情况都可能导致实现中很少使用的部分，从而增加了未被发现的可利用的实现错误的机会。
Despite the guidance in Section 2.4, opportunistic security [RFC7435] also deserves consideration, especially at the time a protocol implementation is deployed and configured. Opportunistic security, like other reasons for encrypting traffic, needs to make use of the strongest encryption algorithms that are implemented and allowed by policy. When communicating parties do not have strong algorithms in common, using algorithms that are weak against advanced attackers but sufficient against others is one way to make pervasive surveillance significantly more difficult. As a result, when communicating parties do not have strong algorithms in common, algorithms that would not be acceptable in many negotiated situations are acceptable for opportunistic security when legacy systems are in use for unauthenticated encrypted sessions (as discussed in Section 3 of [RFC7435]) as long as their use does not facilitate downgrade attacks. Similarly, weaker algorithms and shorter key sizes are also acceptable for opportunistic security with the same constraints.
尽管有第2.4节中的指导，机会主义安全[RFC7435]也值得考虑，尤其是在部署和配置协议实现时。与加密流量的其他原因一样，机会主义安全需要使用策略实现和允许的最强加密算法。当通信方没有共同的强算法时，使用对高级攻击者较弱但足以对付其他攻击者的算法是使普及监视变得更加困难的一种方法。因此，当通信方没有共同的强算法时，当遗留系统用于未经验证的加密会话时（如[RFC7435]第3节所述），在许多协商情况下不可接受的算法对于机会主义安全是可接受的只要它们的使用不利于降级攻击。同样，较弱的算法和较短的密钥大小对于具有相同约束的机会主义安全也是可以接受的。
That said, the use of strong algorithms is always preferable.
也就是说，使用强算法总是可取的。
There are tradeoffs between the number of cryptographic algorithms that are supported and the time to deploy a new algorithm. This section provides some of the insights about the 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.
理想情况下，将指定两组独立的强制实现算法，允许一个主套件和一个辅助套件。这种方法可以确保在主套件中发现缺陷时广泛部署辅助套件。
It may seem as if the ability to use an algorithm of one's own choosing is very desirable; however, the selection is often better left to experts. When there are choices, end-users might select between configuration profiles that have been defined by experts. Further, experts need not specify each and every cryptographic algorithm alternative. Specifying all possible choices will not lead to them all being available in every implementation. Mandatory-to-implement algorithms MUST have a stable public specification and public documentation that has been well studied, giving rise to significant confidence. The IETF has always had a preference for unencumbered algorithms. There are significant benefits in selecting algorithms and suites that are widely deployed. The selected algorithms need to be resistant to side-channel attacks and also meet the performance, 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. Specification of too many alternatives will likely hamper interoperability and may hamper security as well. When specifying new algorithms or suites, protocol designers would be prudent to consider whether existing ones can be deprecated.
似乎能够使用自己选择的算法是非常可取的；然而，选择往往最好留给专家。当有选择时，最终用户可能会在专家定义的配置概要文件之间进行选择。此外，专家无需指定每一种加密算法备选方案。指定所有可能的选择不会导致它们在每个实现中都可用。强制实现算法必须有一个稳定的公共规范和公共文档，这些规范和文档经过了很好的研究，从而产生了很大的可信度。IETF一直偏爱无阻碍算法。选择广泛部署的算法和套件有很大的好处。所选择的算法需要能够抵抗侧通道攻击，并满足各种平台上的性能、功耗和代码大小要求。此外，包含太多备选方案可能会增加算法选择或协商的复杂性。指定太多的替代方案可能会妨碍互操作性，也可能会妨碍安全性。当指定新的算法或套件时，协议设计者将慎重考虑是否可以删除现有的算法。
There is significant benefit in selecting the same algorithms and suites for different protocols. Using the same algorithms can simplify implementation when more than one of the protocols is used in the same device or system.
为不同的协议选择相同的算法和套件有很大的好处。当在同一设备或系统中使用多个协议时，使用相同的算法可以简化实现。
Sometimes more than one mandatory-to-implement algorithm is needed to increase the likelihood of interoperability among a diverse population. For example, authenticated encryption is provided by AES-CCM [RFC3610] and AES-GCM [GCM]. Both of these algorithms are considered to be secure. AES-CCM is available in hardware used by many small devices, and AES-GCM is parallelizable and well suited to
有时需要不止一个强制算法来实现，以增加不同群体之间互操作的可能性。例如，认证加密由AES-CCM[RFC3610]和AES-GCM[GCM]提供。这两种算法都被认为是安全的。AES-CCM可用于许多小型设备使用的硬件，AES-GCM可并行化，非常适合于
high-speed devices. Therefore, an application needing authenticated encryption might specify one of these algorithms or both of these algorithms, depending on the population.
高速设备。因此，需要认证加密的应用程序可能会指定这些算法中的一种或两种，具体取决于总体。
It is fairly easy to specify the use of any arbitrary cryptographic algorithm, and once the specification is available, the algorithm gets implemented and deployed. Some people say that the freedom to specify algorithms independently from the rest of the protocol has led to the specification of too many cryptographic algorithms. Once deployed, even with moderate uptake, it is quite difficult to remove algorithms because interoperability with some party will be impacted. As a result, weaker ciphers stick around far too long. Sometimes implementers are forced to maintain cryptographic algorithm implementations well beyond their useful lifetime.
指定任何任意加密算法的使用都相当容易，一旦规范可用，算法就会得到实现和部署。有人说，独立于协议的其他部分指定算法的自由导致了过多加密算法的指定。一旦部署，即使采用了适度的方法，也很难删除算法，因为与某一方的互操作性将受到影响。结果是，较弱的密码存在的时间太长。有时，实现者被迫在密码算法的有效生命周期之外维护密码算法的实现。
In order to manage the proliferation of algorithm choices and provide an expectation of interoperability, many protocols specify mandatory-to-implement algorithms or suites. All implementers are expected to support the mandatory-to-implement cryptographic algorithm, and they can include any others algorithms that they desire. The mandatory-to-implement algorithms are chosen to be highly secure and follow the guidance in RFC 1984 [RFC1984]. Of course, many other factors, including intellectual property rights, have an impact on the cryptographic algorithms that are selected by the community. Generally, the mandatory-to-implement algorithms ought to be preferred, and the other algorithms ought to be selected only in special situations. However, it can be very difficult for a skilled system administrator to determine the proper configuration to achieve these preferences.
为了管理算法选择的激增并提供互操作性的期望，许多协议规定必须实现算法或套件。所有实现者都应该支持强制实现密码算法，并且他们可以包括他们想要的任何其他算法。选择强制实现算法是为了高度安全，并遵循RFC 1984[RFC1984]中的指导。当然，许多其他因素，包括知识产权，都会对社区选择的加密算法产生影响。一般来说，应该优先选择强制实现算法，而只有在特殊情况下才应该选择其他算法。但是，对于熟练的系统管理员来说，确定实现这些首选项的正确配置可能非常困难。
In some cases, more than one mandatory-to-implement cryptographic algorithm has been specified. This is intended to ensure that at least one secure cryptographic algorithm will be available, even if other mandatory-to-implement algorithms are broken. To achieve this goal, the selected algorithms must be diverse, so that a cryptoanalytic advance against one of the algorithms does not also impact the other selected algorithms. The idea is to have an implemented and deployed algorithm as a fallback. However, all of the selected algorithms need to be routinely exercised to ensure quality implementation. This is not always easy to do, especially if the various selected algorithms require different credentials. Obtaining multiple credentials for the same installation is an unacceptable burden on system administrators. Also, the manner by which system administrators are advised to switch algorithms or suites is, at best, ad hoc and, at worst, entirely absent.
在某些情况下，指定了多个实现加密算法的强制选项。这是为了确保至少有一个安全加密算法可用，即使其他强制实现算法被破坏。为了实现这一目标，所选择的算法必须多样化，以便针对其中一种算法的密码分析进步不会影响其他所选择的算法。其想法是实现并部署一个算法作为后备方案。然而，所有选定的算法都需要定期执行，以确保实现的质量。这并不总是容易做到的，尤其是当各种选定的算法需要不同的凭证时。为同一安装获取多个凭据是系统管理员无法接受的负担。此外，建议系统管理员切换算法或套件的方式充其量是临时的，最坏的情况是完全没有。
In the past, protocol designers have chosen one cryptographic algorithm or suite, and then tied many protocol details to that selection. Plan for algorithm transition, either because a mistake is made in the initial selection or because the protocol is successfully used for a long time and the algorithm becomes weak with age. Either way, the design should enable transition.
在过去，协议设计者选择了一个加密算法或套件，然后将许多协议细节与该选择联系起来。计划算法转换，可能是因为在初始选择中出现错误，或者是因为协议成功使用了很长时间，并且算法随着时间的推移而变弱。无论哪种方式，设计都应该支持转换。
Protocol designers are sometimes misled by the simplicity that results from selecting one true algorithm or suite. Since algorithms age, the selection cannot be stable forever. Even the most simple protocol needs a version number to signal which algorithm 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 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 Wired 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 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.
第一个IEEE 802.11[WiFi]规范将有线等效隐私（WEP）作为唯一的加密技术。许多协议细节都是由选定的算法驱动的。人们发现WEP非常弱[WEP]，需要付出很大的努力来指定、实现和部署替代加密技术。由于协议设计的选择与初始算法的选择和向后兼容性的需求有关，这一努力变得更加困难。
Experience with the transition from SHA-1 to SHA-256 indicates that the time from protocol specification to widespread use takes more than five years. In this case, the protocol specifications and implementation were straightforward and fairly prompt. In many software products, the new algorithm was not considered an update to the existing release, so the roll-out of the next release, subsequent deployment, and finally adjustment of the configuration by system administrators took many years. In many consumer hardware products, firmware to implement the new algorithm was difficult to locate and install, or it was simply not available. Further, infrastructure providers were unwilling to make the transition until all of their potential clients were able to use the new algorithm.
从SHA-1到SHA-256的过渡经验表明，从协议规范到广泛使用需要五年以上的时间。在本例中，协议规范和实现非常简单和迅速。在许多软件产品中，新算法并不被视为对现有版本的更新，因此下一版本的推出、后续部署以及系统管理员对配置的最终调整都花费了多年时间。在许多消费类硬件产品中，实现新算法的固件很难定位和安装，或者根本不可用。此外，在所有潜在客户能够使用新算法之前，基础设施提供商不愿意进行转换。
Some nations specify cryptographic algorithms, and then require their use through legislation or regulations. These algorithms may not have wide public review, and they can have limited geographic scope in their deployment. Yet, the legislative or regulatory mandate creates a captive market. As a result, such algorithms will get specified, implemented, and deployed. The default server or responder configuration SHOULD disable such algorithms; in this way, explicit action by the system administrator is needed to enable them 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 different countries or regions; this 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.
国家算法可以强制实施者为不同的国家或地区生成多个不兼容的产品版本；这比使用全球可接受的算法开发产品的成本要高得多。如果不同的国家算法对协议、密钥管理或随机值的使用提出不同的要求，这种情况可能会更糟。
This document provides guidance to working groups and protocol designers. The security of the Internet is improved when broken or weak cryptographic algorithms can be easily replaced with strong ones.
本文件为工作组和协议设计者提供指导。当坏的或弱的密码算法可以很容易地被强密码算法取代时，互联网的安全性就得到了提高。
From a software development and maintenance perspective, cryptographic algorithms can often be added and removed without making changes to surrounding data structures, protocol parsing routines, or state machines. This approach separates the cryptographic algorithm implementation from the rest of the code, which makes it easier to tackle special security concerns such as key exposure and constant-time execution.
从软件开发和维护的角度来看，通常可以添加和删除加密算法，而无需更改周围的数据结构、协议解析例程或状态机。这种方法将加密算法实现与代码的其余部分分离，从而更容易处理特殊的安全问题，如密钥公开和恒定时间执行。
Sometimes application-layer protocols can make use of transport-layer security protocols, such as TLS [RFC5246] or Datagram TLS (DTLS) [RFC6347]. This insulates the application-layer protocol from the details of cryptography, but it is likely to still be necessary to handle the transition from unprotected traffic to protected traffic in the application-layer protocol. In addition, the application-layer protocol may need to handle the downgrade from encrypted communication to plaintext communication.
有时应用层协议可以使用传输层安全协议，如TLS[RFC5246]或数据报TLS（DTLS）[RFC6347]。这将应用层协议与加密的细节隔离开来，但仍有必要在应用层协议中处理从未受保护的通信量到受保护的通信量的转换。此外，应用层协议可能需要处理从加密通信到明文通信的降级。
Hardware offers challenges in the transition of algorithms, for both tiny devices and very high-end data center equipment. Many tiny devices do not include the ability to update the firmware at all. Even if the firmware can be updated, tiny devices are often deployed in places that make it very inconvenient to do so. High-end data center equipment may use special-purpose chips to achieve very high performance, which means that board-level replacement may be needed to change the algorithm. Cost and downtime are both factors in such an upgrade.
硬件为微型设备和高端数据中心设备的算法转换带来了挑战。许多微型设备根本不具备更新固件的能力。即使固件可以更新，微型设备也经常部署在不方便的地方。高端数据中心设备可能使用专用芯片来实现非常高的性能，这意味着可能需要更换板级芯片来改变算法。成本和停机时间都是此类升级的因素。
In most cases, the cryptographic algorithm remains strong, but an attack is found against the way that the strong algorithm is used in a particular protocol. In these cases, a protocol change will probably be needed. For example, the order of cryptographic operations in the TLS protocol has evolved as various attacks have been discovered. Originally, TLS performed encryption after computation of the message authentication code (MAC). This order of operations is called MAC-then-encrypt, which actually involves MAC computation, padding, and then encryption. This is no longer 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 [RFC5116], which should resolve the ordering discussion altogether. After discovery of such attacks, updating the cryptographic algorithms is not likely to be sufficient to thwart the new attack. It may necessary to make significant changes to the protocol.
在大多数情况下，加密算法仍然很强大，但会发现针对特定协议中使用强算法的方式的攻击。在这些情况下，可能需要更改协议。例如，随着各种攻击的发现，TLS协议中加密操作的顺序发生了变化。最初，TLS在计算消息认证码（MAC）后执行加密。这种操作顺序称为MAC-then-encrypt，实际上包括MAC计算、填充和加密。这不再被认为是安全的[BN][K]。因此，指定了一种使用加密然后MAC的机制[RFC7366]。TLS的未来版本预计将使用专门认证的加密算法[RFC5116]，这将完全解决订购问题。在发现此类攻击后，更新加密算法可能不足以阻止新的攻击。可能需要对协议进行重大更改。
Some protocols are used to protect stored data. For example, S/MIME [RFC5751] can protect a message kept in a mailbox. To recover the protected stored data, protocol implementations need to support older algorithms, even when they no longer use the older algorithms for the protection of new stored data.
一些协议用于保护存储的数据。例如，S/MIME[RFC5751]可以保护保存在邮箱中的邮件。要恢复受保护的存储数据，协议实现需要支持较旧的算法，即使它们不再使用较旧的算法来保护新存储的数据。
Support for too many algorithms can lead to implementation vulnerabilities. When many algorithms are supported, some of them will be rarely used. Any code that is rarely used can contain 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.
对太多算法的支持可能导致实现漏洞。当支持许多算法时，其中一些算法很少使用。任何很少使用的代码都可能包含未检测到的bug，算法实现也不例外。应该使用度量来确定是否实际使用了实现的算法，如果没有，未来的版本应该删除它们。此外，未使用的算法或套件应在IANA注册表中标记为已弃用。简言之，消除积垢。
Section 2.3 talks about algorithm transition without considering any other aspects of the protocol design. In practice, there are dependencies between the cryptographic algorithm and other aspects of
第2.3节讨论了算法转换，没有考虑协议设计的任何其他方面。在实践中，密码算法和密码的其他方面之间存在依赖关系
the protocol. For example, the BEAST attack [BEAST] against TLS [RFC5246] caused many sites to turn off modern cryptographic algorithms in favor of older and clearly weaker algorithms.
协议。例如，针对TLS[RFC5246]的BEAST攻击[BEAST]导致许多站点关闭现代加密算法，转而使用较旧且明显较弱的算法。
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 (supervisory control and data acquisition) 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.
需要及时更新设备的机制来部署替换算法或套件。指定、实现和部署替换需要很长时间；因此，过渡过程需要在实际可利用的缺陷已知时开始。某些设备上的更新过程涉及认证，这进一步增加了部署替换设备的时间。例如，作为健康或安全系统一部分的设备在部署前通常需要认证。嵌入式系统和SCADA（监控和数据采集）系统的升级周期通常长达多年，导致类似的部署时间问题。如果在开发技术广泛使用之前，有希望部署替代品，则需要立即采取行动。
This document does not establish any new IANA registries, nor does it add any entries to existing registries.
本文件未建立任何新的IANA登记册，也未向现有登记册添加任何条目。
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.
本文档确实建议为加密算法或套件标识符的新注册中心制定一个约定。将算法或套件标识符添加到注册表后，不应更改或删除它。然而，当不再建议实现时，最好包括一种将注册表项标记为已弃用的方法。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, DOI 10.17487/RFC3766, April 2004, <http://www.rfc-editor.org/info/rfc3766>.
[RFC3766]Orman，H.和P.Hoffman，“确定用于交换对称密钥的公钥的强度”，BCP 86，RFC 3766，DOI 10.17487/RFC3766，2004年4月<http://www.rfc-editor.org/info/rfc3766>.
[BEAST] Wikipedia, "BEAST attack" under "Transport Layer Security", November 2015, <https://en.wikipedia.org/w/index.php?title= Transport_Layer_Security&oldid=689441642#BEAST_attack>.
[BEAST]维基百科，“传输层安全”下的“BEAST攻击”，2015年11月<https://en.wikipedia.org/w/index.php?title= 传输层\安全性和旧ID=689441642 \野兽\攻击>。
[BN] Bellare, M. and C. Namprempre, "Authenticated Encryption: Relations among notions and analysis of the generic composition paradigm", Proceedings of AsiaCrypt '00, Springer-Verlag LNCS No. 1976, p. 531, DOI 10.1007/3-540-44448-3_41, December 2000.
[BN]Bellare，M.和C.Namprempre，“认证加密：概念之间的关系和通用组合范式的分析”，《亚洲加密会议录》00年，Springer Verlag LNCS第1976号，第页。531，DOI 10.1007/3-540-44448-3)412000年12月。
[GCM] Dworkin, M, "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special Publication 800-30D, November 2007.
[GCM]Dworkin，M，“分组密码操作模式的建议：Galois/计数器模式（GCM）和GMAC”，NIST特别出版物800-30D，2007年11月。
[K] Krawczyk, H., "The Order of Encryption and Authentication for Protecting Communications (or: How Secure Is SSL?)", Proceedings of Crypto '01, Springer-Verlag LNCS No. 2139, p. 310, DOI 10.1007/3-540-44647-8_19, August 2001.
[K] Krawczyk，H.，“保护通信的加密和认证顺序（或：SSL有多安全？），《加密学报》01，Springer Verlag LNCS第2139号，第页。310，DOI 10.1007/3-540-44647-8_，2001年8月19日。
[RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic Technology and the Internet", BCP 200, RFC 1984, DOI 10.17487/RFC1984, August 1996, <http://www.rfc-editor.org/info/rfc1984>.
[RFC1984]IAB和IESG，“IAB和IESG关于加密技术和互联网的声明”，BCP 200，RFC 1984，DOI 10.17487/RFC1984，1996年8月<http://www.rfc-editor.org/info/rfc1984>.
[RFC3365] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", BCP 61, RFC 3365, DOI 10.17487/RFC3365, August 2002, <http://www.rfc-editor.org/info/rfc3365>.
[RFC3365]Schiller，J.，“互联网工程任务组标准协议的强大安全要求”，BCP 61，RFC 3365，DOI 10.17487/RFC3365，2002年8月<http://www.rfc-editor.org/info/rfc3365>.
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 2003, <http://www.rfc-editor.org/info/rfc3610>.
[RFC3610]Whiting，D.，Housley，R.，和N.Ferguson，“CBC-MAC（CCM）计数器”，RFC 3610，DOI 10.17487/RFC3610，2003年9月<http://www.rfc-editor.org/info/rfc3610>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <http://www.rfc-editor.org/info/rfc3748>.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，编辑，“可扩展身份验证协议（EAP）”，RFC 3748，DOI 10.17487/RFC3748，2004年6月<http://www.rfc-editor.org/info/rfc3748>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, <http://www.rfc-editor.org/info/rfc4302>.
[RFC4302]Kent，S.，“IP认证头”，RFC 4302，DOI 10.17487/RFC4302，2005年12月<http://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <http://www.rfc-editor.org/info/rfc4303>.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，DOI 10.17487/RFC4303，2005年12月<http://www.rfc-editor.org/info/rfc4303>.
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, DOI 10.17487/RFC4307, December 2005, <http://www.rfc-editor.org/info/rfc4307>.
[RFC4307]Schiller，J.“互联网密钥交换版本2（IKEv2）中使用的加密算法”，RFC 4307，DOI 10.17487/RFC4307，2005年12月<http://www.rfc-editor.org/info/rfc4307>.
[RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006, <http://www.rfc-editor.org/info/rfc4422>.
[RFC4422]Melnikov，A.，Ed.，和K.Zeilenga，Ed.，“简单身份验证和安全层（SASL）”，RFC 4422，DOI 10.17487/RFC4422，2006年6月<http://www.rfc-editor.org/info/rfc4422>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <http://www.rfc-editor.org/info/rfc5116>.
[RFC5116]McGrew，D.“认证加密的接口和算法”，RFC 5116，DOI 10.17487/RFC5116，2008年1月<http://www.rfc-editor.org/info/rfc5116>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<http://www.rfc-editor.org/info/rfc5280>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <http://www.rfc-editor.org/info/rfc5652>.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 5652，DOI 10.17487/RFC5652，2009年9月<http://www.rfc-editor.org/info/rfc5652>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, <http://www.rfc-editor.org/info/rfc5751>.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 5751，DOI 10.17487/RFC5751，2010年1月<http://www.rfc-editor.org/info/rfc5751>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，DOI 10.17487/RFC6347，2012年1月<http://www.rfc-editor.org/info/rfc6347>.
[RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 2013, <http://www.rfc-editor.org/info/rfc6916>.
[RFC6916]Gagliano，R.，Kent，S.和S.Turner，“资源公钥基础设施（RPKI）的算法敏捷程序”，BCP 182，RFC 6916，DOI 10.17487/RFC6916，2013年4月<http://www.rfc-editor.org/info/rfc6916>.
[RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013, <http://www.rfc-editor.org/info/rfc6975>.
[RFC6975]Crocker，S.和S.Rose，“DNS安全扩展（DNSSEC）中的信号加密算法理解”，RFC 6975，DOI 10.17487/RFC6975，2013年7月<http://www.rfc-editor.org/info/rfc6975>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296]Kaufman，C.，Hoffman，P.，Nir，Y.，Eronen，P.，和T.Kivinen，“互联网密钥交换协议版本2（IKEv2）”，STD 79，RFC 7296，DOI 10.17487/RFC72962014年10月<http://www.rfc-editor.org/info/rfc7296>.
[RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014, <http://www.rfc-editor.org/info/rfc7366>.
[RFC7366]Gutmann，P.，“为传输层安全性（TLS）和数据报传输层安全性（DTLS）加密MAC”，RFC 7366，DOI 10.17487/RFC7366，2014年9月<http://www.rfc-editor.org/info/rfc7366>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7435]Dukhovni，V.，“机会主义安全：大部分时间的一些保护”，RFC 7435，DOI 10.17487/RFC7435，2014年12月<http://www.rfc-editor.org/info/rfc7435>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<http://www.rfc-editor.org/info/rfc7525>.
[WEP] Wikipedia, "Wired Equivalent Privacy", November 2015, <https://en.wikipedia.org/w/index.php? title=Wired_Equivalent_Privacy&oldid=688848497>.
[WEP]维基百科，“有线等效隐私”，2015年11月<https://en.wikipedia.org/w/index.php? title=Wired\u Equivalent\u Privacy&oldid=688848497>。
[WiFi] IEEE, "Wireless LAN Medium Access Control (MAC) And Physical Layer (PHY) Specifications", IEEE Std 802.11-1997, 1997.
[WiFi]IEEE，“无线局域网介质访问控制（MAC）和物理层（PHY）规范”，IEEE标准802.11-1997，1997。
Acknowledgements
致谢
Thanks to Bernard Aboba, Derek Atkins, David Black, Randy Bush, Jon Callas, Andrew Chi, Steve Crocker, Viktor Dukhovni, Stephen Farrell, Tony Finch, Ian Grigg, Peter Gutmann, Phillip Hallam-Baker, Wes Hardaker, Joe Hildebrand, Paul Hoffman, Christian Huitema, Leif Johansson, Suresh Krishnan, Watson Ladd, Paul Lambert, Ben Laurie, Eliot Lear, Nikos Mavrogiannopoulos, Kathleen Moriarty, Yoav Nir, Kenny Paterson, Rich Salz, Wendy Seltzer, Joel Sing, Rene Struik, Kristof Teichel, Martin Thompson, Jeffrey Walton, Nico Williams, and Peter Yee for their review and insightful comments. While some of these people do not agree with some aspects of this document, the discussion that resulted for their comments has certainly resulted in a better document.
感谢伯纳德·阿博巴、德里克·阿特金斯、大卫·布莱克、兰迪·布什、乔恩·卡拉斯、安德鲁·奇、史蒂夫·克罗克、维克托·杜霍夫尼、斯蒂芬·法雷尔、托尼·芬奇、伊恩·格里格、彼得·古特曼、菲利普·哈勒姆·贝克、韦斯·哈达克、乔·希尔德布兰德、保罗·霍夫曼、克里斯蒂安·惠特马、莱夫·约翰逊·约翰逊、苏雷什·克里希南、沃森·拉德、保罗·兰伯特、本·劳里、艾略特·李尔、，Nikos Mavrogiannopoulos、Kathleen Moriarty、Yoav Nir、Kenny Paterson、Rich Salz、Wendy Seltzer、Joel Sing、Rene Struik、Kristof Teichel、Martin Thompson、Jeffrey Walton、Nico Williams和Peter Yee，感谢他们的评论和深刻的评论。虽然其中一些人不同意本文件的某些方面，但他们提出意见的讨论肯定会产生一份更好的文件。
Author's Address
作者地址
Russ Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 United States
Russ Housley Vigil Security，LLC 918 Spring Knoll Drive Herndon，弗吉尼亚州，美国，20170
Email: housley@vigilsec.com
Email: housley@vigilsec.com