Internet Engineering Task Force (IETF) P. Gutmann
Request for Comments: 7366 University of Auckland
Category: Standards Track September 2014
ISSN: 2070-1721
Internet Engineering Task Force (IETF) P. Gutmann
Request for Comments: 7366 University of Auckland
Category: Standards Track September 2014
ISSN: 2070-1721
Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
然后加密MAC以实现传输层安全性（TLS）和数据报传输层安全性（DTLS）
Abstract
摘要
This document describes a means of negotiating the use of the encrypt-then-MAC security mechanism in place of the existing MAC-then-encrypt mechanism in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The MAC-then-encrypt mechanism has been the subject of a number of security vulnerabilities over a period of many years.
本文档描述了协商使用加密然后MAC安全机制代替传输层安全（TLS）和数据报传输层安全（DTLS）中现有的MAC然后加密机制的方法。MAC-then加密机制多年来一直是许多安全漏洞的主题。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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 Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见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/rfc7366.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7366.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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. Conventions Used in This Document . . . . . . . . . . . . 2
2. Negotiating Encrypt-then-MAC . . . . . . . . . . . . . . . . 2
2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applying Encrypt-then-MAC . . . . . . . . . . . . . . . . . . 3
3.1. Rehandshake Issues . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 2
2. Negotiating Encrypt-then-MAC . . . . . . . . . . . . . . . . 2
2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applying Encrypt-then-MAC . . . . . . . . . . . . . . . . . . 3
3.1. Rehandshake Issues . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7
TLS [2] and DTLS [4] use a MAC-then-encrypt construction that was regarded as secure at the time the original Secure Socket Layer (SSL) protocol was specified in the mid-1990s, but that is no longer regarded as secure [5] [6]. This construction, as used in TLS and later DTLS, has been the subject of numerous security vulnerabilities and attacks stretching over a period of many years. This document specifies a means of switching to the more secure encrypt-then-MAC construction as part of the TLS/DTLS handshake, replacing the current MAC-then-encrypt construction. (In this document, "MAC" refers to "Message Authentication Code".)
TLS[2]和DTL[4]使用MAC-then加密结构，该结构在20世纪90年代中期指定原始安全套接字层（SSL）协议时被视为安全的，但不再被视为安全的[5][6]。在TLS和后来的DTL中使用的这种结构，多年来一直受到许多安全漏洞和攻击。本文档指定了一种切换到更安全的加密然后MAC结构的方法，作为TLS/DTLS握手的一部分，取代当前的MAC然后加密结构。（在本文件中，“MAC”指“消息验证码”。）
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 [1].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[1]中所述进行解释。
The use of encrypt-then-MAC is negotiated via TLS/DTLS extensions as defined in TLS [2]. On connecting, the client includes the encrypt_then_mac extension in its client_hello if it wishes to use encrypt-then-MAC rather than the default MAC-then-encrypt. If the server is capable of meeting this requirement, it responds with an encrypt_then_mac in its server_hello. The "extension_type" value for this extension SHALL be 22 (0x16), and the "extension_data" field of this extension SHALL be empty. The client and server MUST NOT use encrypt-then-MAC unless both sides have successfully exchanged encrypt_then_mac extensions.
加密然后MAC的使用通过TLS/DTLS扩展协商，如TLS[2]中所定义。在连接时，如果客户端希望使用encrypt then mac而不是默认的mac then encrypt，则在其客户端hello中包含encrypt then mac扩展。如果服务器能够满足此要求，它将在其服务器中使用加密\u然后\u mac进行响应。此扩展的“扩展类型”值应为22（0x16），且此扩展的“扩展数据”字段应为空。客户端和服务器不得使用encrypt then MAC，除非双方已成功交换encrypt then MAC扩展。
The use of TLS/DTLS extensions to negotiate an overall switch is preferable to defining new ciphersuites because the latter would result in a Cartesian explosion of suites, potentially requiring duplicating every single existing suite with a new one that uses encrypt-then-MAC. In contrast, the approach presented here requires just a single new extension type with a corresponding minimal-length extension sent by client and server.
使用TLS/DTLS扩展来协商整体交换比定义新的密码套件更可取，因为后者将导致套件的笛卡尔爆炸，可能需要使用使用加密然后MAC的新套件复制每个现有套件。相比之下，这里介绍的方法只需要一个新的扩展类型，由客户端和服务器发送相应的最小长度扩展。
Another possibility for introducing encrypt-then-MAC would be to make it part of TLS 1.3; however, this would require the implementation and deployment of all of TLS 1.2 just to support a trivial code change in the order of encryption and MAC'ing. In contrast, deploying encrypt-then-MAC via the TLS/DTLS extension mechanism required changing less than a dozen lines of code in one implementation (not including the handling for the new extension type, which was a further 50 or so lines of code).
引入encrypt then MAC的另一种可能性是使其成为TLS 1.3的一部分；然而，这将需要实现和部署所有TLS1.2，以支持按照加密和MAC的顺序对代码进行细微的更改。相比之下，通过TLS/DTLS扩展机制部署encrypt-then-MAC需要在一个实现中更改不到十几行代码（不包括对新扩展类型的处理，这是另外50行左右的代码）。
The use of extensions precludes use with SSL 3.0, but then it's likely that anything still using that protocol, which is nearly two decades old, will be vulnerable to any number of other attacks anyway, so there seems little point in bending over backwards to accommodate SSL 3.0.
扩展的使用排除了SSL 3.0的使用，但是仍然使用该协议的任何东西（已经有近二十年的历史）都很可能会受到任何数量的其他攻击，因此向后弯曲以适应SSL 3.0似乎没有什么意义。
Once the use of encrypt-then-MAC has been negotiated, processing of TLS/DTLS packets switches from the standard:
一旦协商使用encrypt then MAC，TLS/DTLS数据包的处理将从标准转换为：
encrypt( data || MAC || pad )
加密（数据| | MAC | | pad）
to the new:
对于新的：
encrypt( data || pad ) || MAC
加密（数据| | pad）| | MAC
with the MAC covering the entire packet up to the start of the MAC value. In TLS [2] notation, the MAC calculation for TLS 1.0 without the explicit Initialization Vector (IV) is:
MAC覆盖整个数据包，直到MAC值开始。在TLS[2]表示法中，没有显式初始化向量（IV）的TLS 1.0的MAC计算为：
MAC(MAC_write_key, seq_num +
TLSCipherText.type +
TLSCipherText.version +
TLSCipherText.length +
ENC(content + padding + padding_length));
MAC(MAC_write_key, seq_num +
TLSCipherText.type +
TLSCipherText.version +
TLSCipherText.length +
ENC(content + padding + padding_length));
and for TLS 1.1 and greater with an explicit IV is:
对于TLS 1.1及更高版本，明确IV为：
MAC(MAC_write_key, seq_num +
TLSCipherText.type +
TLSCipherText.version +
TLSCipherText.length +
IV +
ENC(content + padding + padding_length));
MAC(MAC_write_key, seq_num +
TLSCipherText.type +
TLSCipherText.version +
TLSCipherText.length +
IV +
ENC(content + padding + padding_length));
(For DTLS, the sequence number is replaced by the combined epoch and sequence number as per DTLS [4].) The final MAC value is then appended to the encrypted data and padding. This calculation is identical to the existing one, with the exception that the MAC calculation is run over the payload ciphertext (the TLSCipherText PDU) rather than the plaintext (the TLSCompressed PDU).
（对于DTLS，根据DTLS[4]，序列号由组合的历元和序列号替换）。然后将最终MAC值附加到加密数据和填充中。此计算与现有计算相同，但MAC计算是在有效负载密文（TLSCipherText PDU）而不是明文（TLSCompressed PDU）上运行的。
The overall TLS packet [2] is then:
然后，整个TLS分组[2]是：
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
GenericBlockCipher fragment;
opaque MAC;
} TLSCiphertext;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
GenericBlockCipher fragment;
opaque MAC;
} TLSCiphertext;
The equivalent DTLS packet [4] is then:
等效的DTLS数据包[4]是：
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch;
uint48 sequence_number;
uint16 length;
GenericBlockCipher fragment;
opaque MAC;
} TLSCiphertext;
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch;
uint48 sequence_number;
uint16 length;
GenericBlockCipher fragment;
opaque MAC;
} TLSCiphertext;
This is identical to the existing TLS/DTLS layout, with the only difference being that the MAC value is moved outside the encrypted data.
这与现有的TLS/DTLS布局相同，唯一的区别是MAC值被移动到加密数据之外。
Note from the GenericBlockCipher annotation that this only applies to standard block ciphers that have distinct encrypt and MAC operations. It does not apply to GenericStreamCiphers or to GenericAEADCiphers that already include integrity protection with the cipher. If a server receives an encrypt-then-MAC request extension from a client and then selects a stream or Authenticated Encryption with Associated
从GenericBlockCipher注释中注意，这仅适用于具有不同加密和MAC操作的标准分组密码。它不适用于已包含密码完整性保护的GenericStreamiPhone或GenericeAdCipher。如果服务器从客户端接收到一个加密然后MAC请求扩展，然后选择一个流或与相关的
Data (AEAD) ciphersuite, it MUST NOT send an encrypt-then-MAC response extension back to the client.
数据（AEAD）密码套件，它不能将加密然后MAC响应扩展发送回客户端。
Decryption reverses this processing. The MAC SHALL be evaluated before any further processing such as decryption is performed, and if the MAC verification fails, then processing SHALL terminate immediately. For TLS, a fatal bad_record_mac MUST be generated [2]. For DTLS, the record MUST be discarded, and a fatal bad_record_mac MAY be generated [4]. This immediate response to a bad MAC eliminates any timing channels that may be available through the use of manipulated packet data.
解密会反转此处理。在执行任何进一步处理（如解密）之前，应对MAC进行评估，如果MAC验证失败，则处理应立即终止。对于TLS，必须生成致命的坏记录\u mac[2]。对于DTL，必须丢弃记录，并可能生成致命的坏记录\u mac[4]。这种对坏MAC的即时响应消除了可能通过使用被操纵的分组数据而可用的任何定时信道。
Some implementations may prefer to use a truncated MAC rather than a full-length one. In this case, they MAY negotiate the use of a truncated MAC through the TLS truncated_hmac extension as defined in TLS-Ext [3].
有些实现可能更喜欢使用截断的MAC，而不是全长的MAC。在这种情况下，他们可以通过TLS Ext[3]中定义的TLS truncated_hmac扩展协商使用截断MAC。
The status of encrypt-then-MAC vs. MAC-then-encrypt can potentially change during one or more rehandshakes. Implementations SHOULD retain the current session state across all rehandshakes for that session. (In other words, if the mechanism for the current session is X, then the renegotiated session should also use X.) Although implementations SHOULD NOT change the state during a rehandshake, if they wish to be more flexible, then the following rules apply:
在一次或多次重新握手期间，encrypt then MAC与MAC then encrypt的状态可能会发生变化。实现应该在该会话的所有Rehandshake中保留当前会话状态。（换句话说，如果当前会话的机制是X，那么重新协商的会话也应该使用X。）虽然实现不应该在重新握手期间更改状态，但如果它们希望更灵活，则适用以下规则：
+------------------+---------------------+--------------------------+
| Current Session | Renegotiated | Action to take |
| | Session | |
+------------------+---------------------+--------------------------+
| MAC-then-encrypt | MAC-then-encrypt | No change |
| | | |
| MAC-then-encrypt | Encrypt-then-MAC | Upgrade to |
| | | Encrypt-then-MAC |
| | | |
| Encrypt-then-MAC | MAC-then-encrypt | Error |
| | | |
| Encrypt-then-MAC | Encrypt-then-MAC | No change |
+------------------+---------------------+--------------------------+
+------------------+---------------------+--------------------------+
| Current Session | Renegotiated | Action to take |
| | Session | |
+------------------+---------------------+--------------------------+
| MAC-then-encrypt | MAC-then-encrypt | No change |
| | | |
| MAC-then-encrypt | Encrypt-then-MAC | Upgrade to |
| | | Encrypt-then-MAC |
| | | |
| Encrypt-then-MAC | MAC-then-encrypt | Error |
| | | |
| Encrypt-then-MAC | Encrypt-then-MAC | No change |
+------------------+---------------------+--------------------------+
Table 1: Encrypt-then-MAC with Renegotiation
表1：加密然后重新协商MAC
As the above table points out, implementations MUST NOT renegotiate a downgrade from encrypt-then-MAC to MAC-then-encrypt. Note that a client or server that doesn't wish to implement the mechanism-change-during-rehandshake ability can (as a client) not request a mechanism change and (as a server) deny the mechanism change.
正如上表所指出的，实现不能重新协商从加密然后MAC到MAC再加密的降级。请注意，不希望在rehandshake功能期间实现机制更改的客户端或服务器可以（作为客户端）不请求机制更改，并且（作为服务器）拒绝机制更改。
Note that these rules apply across potentially many rehandshakes. For example, if a session were in the encrypt-then-MAC state and a rehandshake selected a GenericAEADCiphers ciphersuite and a subsequent rehandshake then selected a MAC-then-encrypt ciphersuite, this would be an error since the renegotiation process has resulted in a downgrade from encrypt-then-MAC to MAC-then-encrypt (via the AEAD ciphersuite).
请注意，这些规则可能适用于多个Rehandshake。例如，如果会话处于加密然后MAC状态，并且rehandshake选择了一个GenericaLeadCiphers密码套件，随后的rehandshake选择了一个MAC然后加密密码套件，这将是一个错误，因为重新协商过程导致从encrypt-then-MAC降级为MAC-then-encrypt（通过AEAD密码套件）。
(As the text above has already pointed out, implementations SHOULD avoid having to deal with these ciphersuite calisthenics by retaining the initially negotiated mechanism across all rehandshakes.)
（正如上面的文本已经指出的，通过在所有Rehandshake中保留最初协商的机制，实现应该避免处理这些密码套件健美操。）
If an upgrade from MAC-then-encrypt to encrypt-then-MAC is negotiated as per the second line in the table above, then the change will take place in the first message that follows the Change Cipher Spec (CCS) message. In other words, all messages up to and including the CCS will use MAC-then-encrypt, and then the message that follows will continue with encrypt-then-MAC.
如果根据上表中的第二行协商从MAC加密升级到加密，则更改将发生在更改密码规范（CCS）消息之后的第一条消息中。换句话说，CCS之前和包括CCS在内的所有消息都将使用MAC然后加密，随后的消息将继续使用encrypt然后MAC。
This document defines encrypt-then-MAC, an improved security mechanism to replace the current MAC-then-encrypt one. Encrypt-then-MAC is regarded as more secure than the current mechanism [5] [6] and should mitigate or eliminate a number of attacks on the current mechanism, provided that the instructions on MAC processing given in Section 3 are applied.
本文档定义了encrypt then MAC，这是一种改进的安全机制，用于取代当前的MAC then encrypt机制。Encrypt then MAC被视为比当前机制更安全[5][6]，并应减轻或消除对当前机制的一些攻击，前提是应用第3节中给出的MAC处理说明。
An active attacker who can emulate a client or server with extension intolerance may cause some implementations to fall back to older protocol versions that don't support extensions, which will in turn force a fallback to non-encrypt-then-MAC behaviour. A straightforward solution to this problem is to avoid fallback to older, less secure protocol versions. If fallback behaviour is unavoidable, then mechanisms to address this issue, which affects all capabilities that are negotiated via TLS extensions, are being developed by the TLS working group [7]. Anyone concerned about this type of attack should consult the TLS working group documents for guidance on appropriate defence mechanisms.
能够模拟具有扩展不容忍的客户端或服务器的主动攻击者可能会导致某些实现退回到不支持扩展的较旧协议版本，这反过来将强制退回到非加密然后MAC行为。这个问题的一个简单解决方案是避免回退到较旧、较不安全的协议版本。如果回退行为不可避免，那么TLS工作组正在开发解决该问题的机制，该问题影响通过TLS扩展协商的所有能力[7]。任何关注此类攻击的人都应查阅TLS工作组文件，以获得有关适当防御机制的指导。
IANA has added the extension code point 22 (0x16) for the encrypt_then_mac extension to the TLS "ExtensionType Values" registry as specified in TLS [2].
IANA已将encrypt\u then\u mac扩展的扩展代码点22（0x16）添加到TLS“ExtensionType Values”注册表中，如TLS[2]中所述。
The author would like to thank Martin Rex, Dan Shumow, and the members of the TLS mailing list for their feedback on this document.
作者感谢Martin Rex、Dan Shumow和TLS邮件列表的成员对本文件的反馈。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[2] Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[3] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[3] Eastlake，D.，“传输层安全（TLS）扩展：扩展定义”，RFC6062011年1月。
[4] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[4] Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，2012年1月。
[5] 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, December 2000.
[5] Bellare，M.和C.Namprempre，“认证加密：概念之间的关系和通用组合范式的分析”，《亚洲加密会议录》00年，Springer Verlag LNCS第1976号，第页。2000年12月531日。
[6] 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, August 2001.
[6] Krawczyk，H.，“保护通信的加密和认证顺序（或：SSL有多安全？），《加密学报》01，Springer Verlag LNCS第2139号，第页。2001年8月31日。
[7] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks", Work in Progress, July 2014.
[7] Moeller，B.和A.Langley，“用于防止协议降级攻击的TLS回退信令密码套件值（SCSV）”，正在进行的工作，2014年7月。
Author's Address
作者地址
Peter Gutmann University of Auckland Department of Computer Science New Zealand
古特曼奥克兰大学新西兰计算机系
EMail: pgut001@cs.auckland.ac.nz
EMail: pgut001@cs.auckland.ac.nz