[要約] RFC 7366は、Transport Layer Security (TLS) および Datagram Transport Layer Security (DTLS) プロトコルにおいて、Encrypt-then-MAC (EtM) モードを導入することを提案しています。この文書の目的は、データの暗号化後にメッセージ認証コード (MAC) を適用することで、プロトコルのセキュリティを強化することです。この方式は、既存のMAC-then-Encrypt (MtE) モードの脆弱性に対処し、データの機密性と完全性をより効果的に保護します。利用場面としては、TLSやDTLSを使用するすべてのアプリケーションでのデータ転送のセキュリティ強化が挙げられます。関連するRFCには、TLSおよびDTLSを定義するRFC 5246 (TLS 1.2) やRFC 6347 (DTLS 1.2) などがあります。
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)
トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）用の暗号化後MAC
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.
このドキュメントでは、トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）の既存のMAC-then-encryptメカニズムの代わりに、encrypt-then-MACセキュリティメカニズムの使用をネゴシエートする方法について説明します。 MAC-then-encryptメカニズムは、長年にわたって多くのセキュリティ脆弱性の対象となってきました。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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]およびDTLS [4]は、1990年代半ばに元のSecure Socket Layer（SSL）プロトコルが指定されたときに安全であると見なされていたMAC-then-encrypt構造を使用しますが、安全であるとは見なされなくなりました。 [5] [6]。 TLSおよびそれ以降のDTLSで使用されているこの構造は、長年にわたって広がっている数多くのセキュリティの脆弱性と攻撃の対象となってきました。このドキュメントでは、TLS / DTLSハンドシェイクの一部として、より安全な暗号化してからMAC構成に切り替える方法を指定し、現在の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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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 [2]で定義されているTLS / DTLS拡張を介してネゴシエートされます。接続時に、デフォルトのMAC-then-encryptではなく、encrypt-then-MACを使用する場合、クライアントはclient_helloにencrypt_then_mac拡張を含めます。サーバーがこの要件を満たすことができる場合、サーバーはserver_helloのencrypt_then_macで応答します。この拡張の「extension_type」値は22（0x16）である必要があり、この拡張の「extension_data」フィールドは空である必要があります。クライアントとサーバーは、双方がencrypt_then_mac拡張を正常に交換していない限り、encrypt-then-MACを使用してはなりません（MUST NOT）。
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拡張を使用してスイッチ全体をネゴシエートすることは、新しい暗号スイートを定義するよりも望ましいです。後者はスイートのデカルト爆発を引き起こし、潜在的にすべての既存のスイートを、encrypt-then-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).
暗号化してからMACを導入するもう1つの可能性は、それをTLS 1.3の一部にすることです。ただし、これには、暗号化とMAC化の順序で簡単なコード変更をサポートするためだけに、TLS 1.2のすべての実装と展開が必要になります。対照的に、TLS / DTLS拡張メカニズムを介して暗号化してからMACをデプロイするには、1つの実装で数十行未満のコードを変更する必要がありました（新しい拡張タイプの処理は含まれていません。これはさらに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での使用ができなくなりますが、そのプロトコルを使用しているものは、ほぼ20年前のものですが、いずれにせよ、他の任意の数の攻撃に対して脆弱になる可能性が高いため、対応するために後方に曲げても意味がありません。 SSL 3.0。
Once the use of encrypt-then-MAC has been negotiated, processing of TLS/DTLS packets switches from the standard:
暗号化後MACの使用がネゴシエートされると、TLS / DTLSパケットの処理は標準から切り替わります。
encrypt( data || MAC || pad )
暗号化（データ|| MAC ||パッド）
to the new:
新しいへ：
encrypt( data || 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));
and for TLS 1.1 and greater with an explicit IV is:
明示的なIVを使用したTLS 1.1以降の場合：
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計算が平文（TLSCompressed PDU）ではなくペイロード暗号文（TLSCipherText PDU）で実行される点が異なります。
The overall TLS packet [2] is then:
TLSパケット全体[2]は次のようになります。
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;
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 Data (AEAD) ciphersuite, it MUST NOT send an encrypt-then-MAC response extension back to the client.
GenericBlockCipherアノテーションから、これは異なる暗号化とMAC操作を持つ標準ブロック暗号にのみ適用されることに注意してください。 GenericStreamCiphersや、暗号で完全性保護がすでに組み込まれているGenericAEADCipherには適用されません。サーバーがクライアントから暗号化後MAC要求拡張を受信し、ストリームまたは関連データ付き認証暗号化（AEAD）暗号スイートを選択した場合、サーバーは暗号化後MAC応答拡張をクライアントに送信してはなりません（MUST NOT）。
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の場合、致命的なbad_record_macを生成する必要があります[2]。 DTLSの場合、レコードは破棄されなければならず（MUST）、致命的なbad_record_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の使用についてネゴシエートしてもよい（MAY）。
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:
暗号化後のMACとMAC-then-encryptのステータスは、1回以上の再ハンドシェイク中に変更される可能性があります。実装は、そのセッションのすべての再ハンドシェイクにわたって現在のセッション状態を保持する必要があります（SHOULD）。 （つまり、現在のセッションのメカニズムが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 |
+------------------+---------------------+--------------------------+
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.
上記の表が示すように、実装では、encrypt-then-MACからMAC-then-encryptへのダウングレードを再ネゴシエートしてはなりません（MUST NOT）。 Mechanism-change-during-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).
これらのルールは、潜在的に多くの再握手に適用されることに注意してください。たとえば、セッションが暗号化してからMAC状態にあり、再ハンドシェイクでGenericAEADCiphers暗号スイートを選択し、その後に再ハンドシェイクでMAC-then-encrypt暗号スイートを選択した場合、再ネゴシエーションプロセスによりダウングレードが発生したため、これはエラーになります。 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.)
（上記のテキストですでに指摘したように、実装では、すべての再ハンドシェイクで最初にネゴシエートされたメカニズムを保持することにより、これらの暗号スイートの体操に対処する必要がないようにする必要があります。）
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-then-encryptからencrypt-then-MACへのアップグレードが上記の表の2行目でネゴシエートされる場合、変更はChange Cipher Spec（CCS）メッセージに続く最初のメッセージで行われます。つまり、CCSまでのすべてのメッセージはMAC-then-encryptを使用し、その後のメッセージは引き続きencrypt-then-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.
このドキュメントは、現在のMAC-then-encryptを置き換えるための改良されたセキュリティメカニズムである、encrypt-then-MACを定義しています。 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は、TLS [2]で指定されているように、encrypt_then_mac拡張の拡張コードポイント22（0x16）をTLS "ExtensionType値"レジストリに追加しました。
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、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[3] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[3] Eastlake、D。、「Transport Layer Security（TLS）Extensions：Extension Definitions」、RFC 6066、2011年1月。
[4] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[4] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 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、「Authenticated Encryption：Relations between概念と分析の一般的な構成パラダイム」、Proceedings of AsiaCrypt '00、Springer-Verlag LNCS No. 1976、p。 531、2000年12月。
[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の安全性は？）」、Crypto '01、Springer-Verlag LNCS No. 2139、p。 2001年8月310日。
[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