[要約] RFC 9146はDTLS 1.2における接続識別子に関する文書で、セキュアな通信セッションを一意に識別するための方法を定義しています。この識別子は、特にIPアドレスやポート番号が変更された場合でも、セッションの継続性を保証するために利用されます。主に、モバイルデバイスやネットワークの変更が頻繁に起こる環境での利用が想定されています。
Internet Engineering Task Force (IETF) E. Rescorla, Ed.
Request for Comments: 9146 Mozilla
Updates: 6347 H. Tschofenig, Ed.
Category: Standards Track T. Fossati
ISSN: 2070-1721 Arm Limited
A. Kraus
Bosch.IO GmbH
March 2022
Connection Identifier for DTLS 1.2
DTLS 1.2の接続識別子
Abstract
概要
This document specifies the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol version 1.2.
このドキュメントでは、データグラムトランスポート層セキュリティ（DTLS）プロトコルバージョン1.2用の接続ID（CID）構成要素を指定します。
A CID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association. In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple. If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session, then the receiver will be unable to locate the correct security context.
CIDは、適切なセキュリティアソシエーションを選択するための受信者追加情報を提供するレコードレイヤヘッダーに搭載されている識別子です。「古典的な」DTLSでは、入ってくるDTLSレコードのセキュリティアソシエーションを選択することは、5タプルの助けを借りて達成されます。送信元IPアドレスおよび/または送信元ポートが進行中のDTLSセッションの有効期間中に変更された場合、受信者は正しいセキュリティコンテキストを見つけることができません。
The new ciphertext record format with the CID also provides content type encryption and record layer padding.
CIDを使用した新しい暗号文レコードフォーマットは、コンテンツタイプの暗号化とレコードレイヤのパディングも提供します。
This document updates RFC 6347.
この文書はRFC 6347を更新します。
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 7841.
この文書はインターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それはパブリックレビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9146.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9146で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF信頼と文書の著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。この文書から抽出されたコードコンポーネントには、信託法定規定のセクション4。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この文書には、2008年11月10日以前に公開されたIETFの文書またはIETFの貢献からの資料が含まれている場合があります。この材料のいくつかの著作権を管理する人は、そのような材料の修正を許可する権利を信頼している権利を与えなかった人物IETF標準の外部プロセス。このような資料の著作権を管理する人から適切なライセンスを取得せずに、この文書はIETF規格プロセスの外で修正されていない可能性があり、それをフォーマットすること以外はIETF標準プロセスの外部にはデリバティブワークが作成できません。RFCとしての出版物、または英語以外の言語に翻訳する。
Table of Contents
目次
1. Introduction
2. Conventions and Terminology
3. The "connection_id" Extension
4. Record Layer Extensions
5. Record Payload Protection
5.1. Block Ciphers
5.2. Block Ciphers with Encrypt-then-MAC Processing
5.3. AEAD Ciphers
6. Peer Address Update
7. Example
8. Privacy Considerations
9. Security Considerations
10. IANA Considerations
10.1. Extra Column Added to the TLS ExtensionType Values
Registry
10.2. New Entry in the TLS ExtensionType Values Registry
10.3. New Entry in the TLS ContentType Registry
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
The Datagram Transport Layer Security (DTLS) protocol [RFC6347] was designed for securing data sent over datagram transports (e.g., UDP). DTLS, like TLS, starts with a handshake, which can be computationally demanding (particularly when public key cryptography is used). After a successful handshake, symmetric key cryptography is used to apply data origin authentication, integrity, and confidentiality protection. This two-step approach allows endpoints to amortize the cost of the initial handshake across subsequent application data protection. Ideally, the second phase where application data is protected lasts over a long period of time, since the established keys will only need to be updated once the key lifetime expires.
データグラムトランスポート層セキュリティ（DTLS）プロトコル[RFC6347]は、データグラムトランスポート（例えば、UDP）を介して送信されたデータを保護するために設計されていました。TLSのようなDTLSは、ハンドシェイクから始まります。これは計算上要求があります（特に公開鍵暗号化が使用されている場合）。ハンドシェイクが成功した後、対称鍵暗号化は、データの原点認証、整合性、および機密保持を適用するために使用されます。この2段階のアプローチにより、エンドポイントがその後のアプリケーションデータ保護にわたって最初のハンドシェイクのコストを償却することができます。理想的には、アプリケーションデータが保護されている第2のフェーズは長期間にわたって続く、確立されたキーは、鍵の寿命が期限切れになると更新する必要があるだけなので、確立されたキーは更新される必要がある。
In DTLS as specified in RFC 6347, the IP address and port of the peer are used to identify the DTLS association. Unfortunately, in some cases, such as NAT rebinding, these values are insufficient. This is a particular issue in the Internet of Things when devices enter extended sleep periods to increase their battery lifetime. The NAT rebinding leads to connection failure, with the resulting cost of a new handshake.
RFC 6347で指定されているDTLSでは、ピアのIPアドレスとポートはDTLSアソシエーションを識別するために使用されます。残念ながら、NATの再バインドなどの場合によっては、これらの値が不十分です。これは、デバイスがそれらのバッテリの寿命を延ばすために拡張睡眠期間を入力したときの物事のインターネットの特定の問題です。NATリファグラインディングは、新しいハンドシェイクのコストを使用して接続の失敗につながります。
This document defines an extension to DTLS 1.2 to add a Connection ID (CID) to the DTLS record layer. The presence of the CID is negotiated via a DTLS extension.
この文書はDTLSレコード層に接続ID（CID）を追加するためのDTLS 1.2への拡張子を定義します。CIDの存在はDTLS拡張によってネゴシエートされます。
Adding a CID to the ciphertext record format presents an opportunity to make other changes to the record format. In keeping with the best practices established by TLS 1.3, the type of the record is encrypted, and a mechanism is provided for adding padding to obfuscate the plaintext length.
暗号文レコードフォーマットにCIDを追加すると、レコード形式に他の変更を加える機会が表示されます。TLS 1.3によって確立されたベストプラクティスを維持する際に、レコードの種類は暗号化され、平文の長さを難読化するためのパディングを追加するためのメカニズムが提供されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document assumes familiarity with DTLS 1.2 [RFC6347]. The presentation language used in this document is described in Section 3 of [RFC8446].
この文書はDTLS 1.2 [RFC6347]に精通していることを前提としています。この文書で使用されている提示言語は[RFC8446]のセクション3で説明されています。
This document defines the "connection_id" extension, which is used in ClientHello and ServerHello messages.
このドキュメントでは、ClientHelloメッセージとServerHelloメッセージで使用されている「connection_id」拡張子を定義します。
The extension type is specified as follows.
拡張タイプは次のように指定されています。
enum {
connection_id(54), (65535)
} ExtensionType;
The extension_data field of this extension, when included in the ClientHello, MUST contain the ConnectionId structure. This structure contains the CID value the client wishes the server to use when sending messages to the client. A zero-length CID value indicates that the client is prepared to send using a CID but does not wish the server to use one when sending.
ClientHelloに含まれている場合、この拡張子のextension_dataフィールドには、ConnectionID構造体が含まれている必要があります。この構造には、クライアントにメッセージを送信するときにサーバーが使用するようなCID値が含まれています。長さゼロのCID値は、クライアントがCIDを使用して送信する準備ができているが、送信時にサーバーが使用することを望まないことを示します。
struct {
opaque cid<0..2^8-1>;
} ConnectionId;
A server willing to use CIDs will respond with a "connection_id" extension in the ServerHello, containing the CID it wishes the client to use when sending messages towards it. A zero-length value indicates that the server will send using the client's CID but does not wish the client to include a CID when sending.
CIDを使用しようとしているサーバーは、メッセージを送信するときにクライアントが使用するCIDを含むServerHelloの "connection_id"拡張子で応答します。長さゼロの値は、サーバーがクライアントのCIDを使用して送信されるが、送信時にクライアントにCIDを含めることはできません。
Because each party sends the value in the "connection_id" extension it wants to receive as a CID in encrypted records, it is possible for an endpoint to use a deployment-specific constant length for such connection identifiers. This can in turn ease parsing and connection lookup -- for example, by having the length in question be a compile-time constant. Such implementations MUST still be able to send CIDs of different lengths to other parties. Since the CID length information is not included in the record itself, implementations that want to use variable-length CIDs are responsible for constructing the CID in such a way that its length can be determined on reception.
各パーティは、暗号化されたレコードのCIDとして受信したい「connection_id」拡張子に値を送信するため、エンドポイントがそのような接続識別子に対して展開固有の定数を使用することが可能です。これは、たとえば、問題の長さをコンパイル時定数にすることで、解析と接続ルックアップを容易にすることができます。そのような実装は、依然として異なる長さのCIDを他の当事者に送信することができなければなりません。CID長情報はレコード自体に含まれていないため、可変長CIDを使用したい実装は、その長さが受信時に決定できるようにCIDを構築する責任があります。
In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session only. There is no dedicated "CID update" message that allows new CIDs to be established mid-session, because DTLS 1.2 in general does not allow TLS 1.3-style post-handshake messages that do not themselves begin other handshakes. When a DTLS session is resumed or renegotiated, the "connection_id" extension is negotiated afresh.
DTLS 1.2では、CIDはDTLSセッションの開始時点でのみ交換されます。DTLS 1.2一般的にDTLS 1.2では、他のハンドシェイクを開始しないTLS 1.3スタイルのハンドシェイクメッセージを許可しないため、新しいCIDを確立できるようにする専用の「CID更新プログラム」というメッセージはありません。DTLSセッションが再開された場合、または再合理化されると、「connection_id」拡張子は新たにネゴシエートされます。
If DTLS peers have not negotiated the use of CIDs, or a zero-length CID has been advertised for a given direction, then the record format and content type defined in RFC 6347 MUST be used to send in the indicated direction(s).
DTLSピアがCIDの使用をネゴシエートしていない場合、または長さゼロのCIDが与えられた方向に対してアドバタイズされている場合、RFC 6347で定義されているレコード形式とコンテンツタイプを指定の方向に送信するために使用する必要があります。
If DTLS peers have negotiated the use of a non-zero-length CID for a given direction, then once encryption is enabled, they MUST send with the record format defined in Figure 3 (see Section 4) with the new Message Authentication Code (MAC) computation defined in Section 5 and the content type tls12_cid. Plaintext payloads never use the new record format or the CID content type.
DTLSピアが指定された方向に対するゼロ以外のCIDの使用をネゴシエートした場合、暗号化が有効になると、新しいメッセージ認証コード（MAC）で図3に定義されているレコード形式（セクション4を参照）で送信する必要があります。）5で定義されている計算とコンテンツタイプTLS12_CID。平文ペイロードは、新しいレコード形式またはCIDコンテンツタイプを使用しないでください。
When receiving, if the tls12_cid content type is set, then the CID is used to look up the connection and the security association. If the tls12_cid content type is not set, then the connection and the security association are looked up by the 5-tuple and a check MUST be made to determine whether a non-zero-length CID is expected. If a non-zero-length CID is expected for the retrieved association, then the datagram MUST be treated as invalid, as described in Section 4.1.2.1 of [RFC6347].
受信すると、TLS12_CIDコンテンツタイプが設定されている場合は、CIDを使用して接続とセキュリティアソシエーションを検索します。TLS12_CIDコンテンツタイプが設定されていない場合は、接続とセキュリティアソシエーションが5タプルによって検索され、ゼロ以外のCIDが予想されるかどうかを判断するためにチェックを行う必要があります。検索された関連付けのためにゼロ以外のCIDが予想される場合、[RFC6347]のセクション4.1.2.1で説明されているように、データグラムは無効として扱われなければなりません。
When receiving a datagram with the tls12_cid content type, the new MAC computation defined in Section 5 MUST be used. When receiving a datagram with the record format defined in RFC 6347, the MAC calculation defined in Section 4.1.2 of [RFC6347] MUST be used.
TLS12_CIDコンテンツタイプでデータグラムを受信すると、セクション5で定義されている新しいMAC計算を使用する必要があります。RFC 6347で定義されているレコード形式でデータグラムを受信すると、[RFC6347]のセクション4.1.2で定義されているMAC計算を使用する必要があります。
This specification defines the CID-enhanced record layer format for DTLS 1.2, and [DTLS13] specifies how to carry the CID in DTLS 1.3.
この仕様はDTLS 1.2のCID拡張レコードレイヤ形式を定義し、[DTLS13]はDTLS 1.3でCIDを運ぶ方法を指定します。
To allow a receiver to determine whether a record has a CID or not, connections that have negotiated this extension use a distinguished record type tls12_cid(25). The use of this content type has the following three implications:
レコードがCIDを持つかどうかを受信側で判断できるようにするために、この拡張子をネゴシエートした接続は、識別レコードタイプTLS12_CID（25）を使用します。このコンテンツタイプの使用には、次の3つの意味があります。
* The CID field is present and contains one or more bytes.
* CIDフィールドが存在し、1バイト以上が含まれています。
* The MAC calculation follows the process described in Section 5.
* MAC計算はセクション5に記載されているプロセスに従う。
* The real content type is inside the encryption envelope, as described below.
* 以下に説明するように、実コンテンツタイプは暗号化エンベロープ内にあります。
Plaintext records are not impacted by this extension. Hence, the format of the DTLSPlaintext structure is left unchanged, as shown in Figure 1.
平文記録はこの拡張子の影響を受けません。したがって、図1に示すように、DTLSpleintext構造体のフォーマットは変更されずに残っています。
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch;
uint48 sequence_number;
uint16 length;
opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext;
Figure 1: DTLS 1.2 Plaintext Record Payload
図1：DTLS 1.2平文レコードペイロード
When CIDs are being used, the content to be sent is first wrapped along with its content type and optional padding into a DTLSInnerPlaintext structure. This newly introduced structure is shown in Figure 2.
CIDが使用されている場合、送信されるコンテンツは最初にそのコンテンツタイプとオプションのパディングとともにDTLSInnerPaintext構造体に包まれます。この新しく導入された構造を図2に示す。
struct {
opaque content[length];
ContentType real_type;
uint8 zeros[length_of_padding];
} DTLSInnerPlaintext;
Figure 2: New DTLSInnerPlaintext Payload Structure
図2：新しいDtlSinnerPaintextペイロード構造
content: Corresponds to the fragment of a given length.
内容：与えられた長さの断片に対応します。
real_type: The content type describing the cleartext payload.
REAL_TYPE：ClearTextペイロードを記述するコンテンツタイプ。
zeros: An arbitrary-length run of zero-valued bytes may appear in the cleartext after the type field. This provides an opportunity for senders to pad any DTLS record by a chosen amount as long as the total stays within record size limits. See Section 5.4 of [RFC8446] for more details. (Note that the term TLSInnerPlaintext in RFC 8446 refers to DTLSInnerPlaintext in this specification.)
ゼロ：ゼロ値のバイトの任意の長さの実行が、Typeフィールドの後にクリアテキストに表示されることがあります。これにより、合計がレコードサイズの制限内に留まる滞在時間が維持されている限り、送信者が選択した金額でDTLSレコードを埋める機会を提供します。詳細については、[RFC8446]のセクション5.4を参照してください。（RFC 8446のTLSINNERPLAINTEXTという用語は、この仕様のDTLSINNERPLAINTEXTを参照しています。）
The DTLSInnerPlaintext byte sequence is then encrypted. To create the DTLSCiphertext structure shown in Figure 3, the CID is added.
DTLSINNERPLANTEXTバイトシーケンスは暗号化されます。図3に示すDTLScipherText構造体を作成するには、CIDが追加されました。
struct {
ContentType outer_type = tls12_cid;
ProtocolVersion version;
uint16 epoch;
uint48 sequence_number;
opaque cid[cid_length]; // New field
uint16 length;
opaque enc_content[DTLSCiphertext.length];
} DTLSCiphertext;
Figure 3: DTLS 1.2 CID-Enhanced Ciphertext Record
図3：DTLS 1.2 CID強化暗号文レコード
outer_type: The outer content type of a DTLSCiphertext record carrying a CID is always set to tls12_cid(25). The real content type of the record is found in DTLSInnerPlaintext.real_type after decryption.
outer_type：CIDを搭載したDTLScipherTextレコードの外部コンテンツタイプは、常にTLS12_CID（25）に設定されています。レコードの実コンテンツタイプは、復号化後のDTLSINNERPLAINTEXT.REAL_TYPEにあります。
cid: The CID value, cid_length bytes long, as agreed at the time the extension has been negotiated. Recall that each peer chooses the CID value it will receive and use to identify the connection, so an implementation can choose to always receive CIDs of a fixed length. If, however, an implementation chooses to receive CIDs of different lengths, the assigned CID values must be self-delineating, since there is no other mechanism available to determine what connection (and thus, what CID length) is in use.
CID：拡張子が交渉された時点で合意されたように、CID値CID_LENGTHバイト数。各ピアが受信したCID値を選択し、接続を識別するために使用するため、実装では常に固定長のCIDを受信することを選択できます。しかしながら、実装が異なる長さのCIDを受信することを選択した場合、割り当てられたCID値は、どの接続（したがってCID長）が使用されているかを判断するために利用可能な他のメカニズムはないので、割り当てられたCID値は自己描写でなければならない。
enc_content: The encrypted form of the serialized DTLSInnerPlaintext structure.
enc_content：暗号化された形式のシリアル化されたDTLSInnerPAINTEXT構造体。
All other fields are as defined in RFC 6347.
他のすべてのフィールドはRFC 6347で定義されているとおりです。
Several types of ciphers have been defined for use with TLS and DTLS, and the MAC calculations for those ciphers differ slightly.
TLSやDTLSで使用するためにいくつかの種類の暗号化が定義されており、それらの暗号のMAC計算はわずかに異なります。
This specification modifies the MAC calculation as defined in [RFC6347] and [RFC7366], as well as the definition of the additional data used with Authenticated Encryption with Associated Data (AEAD) ciphers provided in [RFC6347], for records with content type tls12_cid. The modified algorithm MUST NOT be applied to records that do not carry a CID, i.e., records with content type other than tls12_cid.
この仕様では、[RFC6347]と[RFC7366]で定義されているMAC計算と、[RFC6347]で認証された暗号化で使用されている追加データの定義とともに、コンテンツタイプTLS12_CIDのレコードについては、[RFC6347]。修正されたアルゴリズムは、CIDを持たないレコード、すなわち、TLS12_CID以外のコンテンツタイプのレコードに適用されてはならない。
The following fields are defined in this document; all other fields are as defined in the cited documents.
このドキュメントでは、次のフィールドが定義されています。他のすべてのフィールドは、引用文書で定義されています。
cid: Value of the negotiated CID (variable length).
CID：ネゴシエートされたCIDの値（可変長）。
cid_length: The length (in bytes) of the negotiated CID (one-byte integer).
CID_LENGTH：ネゴシエートされたCID（1バイト整数）の長さ（バイト単位）。
length_of_DTLSInnerPlaintext: The length (in bytes) of the serialized DTLSInnerPlaintext (two-byte integer). The length MUST NOT exceed 2^14.
LENGTH_OF_DTLSINNERPLAINTEXT：シリアル化されたDTLSInnerPAINTEXT（2バイト整数）の長さ（バイト単位）。長さは2 ^ 14を超えてはいけません。
seq_num_placeholder: 8 bytes of 0xff.
seq_num_placeholder：0xFFの8バイト。
Note that "+" denotes concatenation.
「」は連結を表します。
The following MAC algorithm applies to block ciphers that do not use the Encrypt-then-MAC processing described in [RFC7366].
次のMACアルゴリズムは、[RFC7366]で説明されている暗号化次のMAC処理を使用しないブロック暗号に適用されます。
MAC(MAC_write_key, seq_num_placeholder + tls12_cid + cid_length + tls12_cid + DTLSCiphertext.version + epoch + sequence_number + cid + length_of_DTLSInnerPlaintext + DTLSInnerPlaintext.content + DTLSInnerPlaintext.real_type + DTLSInnerPlaintext.zeros );
MAC（MAC_WRITE_KEY、SEQ_NUM_PLANEHOLDER TLS12_CID_LENGTHTLS12_CID DTLScipherText.Version Epoch Sequence_Number CID Length_of_DTLSInnerPleAntext_of_dtlsInnerPaintext dtlsinnerpleAntext.real_type dtlsinnerpaintext.zeros）。
The rationale behind this construction is to separate the MAC input for DTLS without the connection ID from the MAC input with the connection ID. The former always consists of a sequence number followed by some content type other than tls12_cid; the latter always consists of the seq_num_placeholder followed by tls12_cid. Although 2^64-1 is potentially a valid sequence number, tls12_cid will never be a valid content type when the connection ID is not in use. In addition, the epoch and sequence_number are now fed into the MAC in the same order as they appear on the wire.
この構造の背景の背景の背景は、接続IDを使用して接続IDを使用せずにDTLSのMAC入力を分離することです。前者は常にシーケンス番号とそれに続くTLS12_CID以外のコンテンツタイプからなる。後者は常にseq_num_placeholderとそれに続くtls12_cidで構成されています。2 ^ 64-1は潜在的に有効なシーケンス番号であるが、接続IDが使用されていないときにTLS12_CIDは有効なコンテンツタイプにはなりません。さらに、EpochとSequence_Numberは、それらがワイヤー上に表示されるのと同じ順序でMACに供給されるようになりました。
The following MAC algorithm applies to block ciphers that use the Encrypt-then-MAC processing described in [RFC7366].
次のMACアルゴリズムは、[RFC7366]で説明されている暗号化次のMAC処理を使用するブロック暗号に適用されます。
MAC(MAC_write_key,
seq_num_placeholder +
tls12_cid +
cid_length +
tls12_cid +
DTLSCiphertext.version +
epoch +
sequence_number +
cid +
DTLSCiphertext.length +
IV +
ENC(content + padding + padding_length)
);
For ciphers utilizing AEAD, the following modification is made to the additional data calculation.
AEDを利用した暗号化のために、追加のデータ計算に次のような変更が加えられます。
additional_data = seq_num_placeholder + tls12_cid + cid_length + tls12_cid + DTLSCiphertext.version + epoch + sequence_number + cid + length_of_DTLSInnerPlaintext;
appitiamal_cid cid_length TLS12_CID DTLScipherText.Version ePoch sequence_number cid length_of_dtlsInnerpleAntext;
When a record with a CID is received that has a source address different from the one currently associated with the DTLS connection, the receiver MUST NOT replace the address it uses for sending records to its peer with the source address specified in the received datagram, unless the following three conditions are met:
現在DTLS接続に関連しているものとは異なる送信元アドレスを持つCIDを持つレコードを受信した場合、受信者はレコードを受信データグラムで指定されたソースアドレスでそのピアに置き換えてはいけません。次の3つの条件が満たされています。
* The received datagram has been cryptographically verified using the DTLS record layer processing procedures.
* 受信したデータグラムは、DTLSレコードレイヤ処理手順を使用して暗号的に検証されています。
* The received datagram is "newer" (in terms of both epoch and sequence number) than the newest datagram received. Reordered datagrams that are sent prior to a change in a peer address might otherwise cause a valid address change to be reverted. This also limits the ability of an attacker to use replayed datagrams to force a spurious address change, which could result in denial of service. An attacker might be able to succeed in changing a peer address if they are able to rewrite source addresses and if replayed packets are able to arrive before any original.
* 受信したデータグラムは、受信した最新のデータグラムよりも「新しい」（Epochとシーケンス番号の両方で）です。ピアアドレスの変更前に送信される並べ替えデータグラムは、そうでなければ有効なアドレスの変更を元に戻すようにする可能性があります。これにより、攻撃者が再生されたデータグラムを使用してスプリアスアドレスの変更を強制する能力を制限し、これによりサービス拒否が発生する可能性があります。攻撃者は、ソースアドレスを書き換えることができ、再生されたパケットがオリジナルの前に到着することができる場合、ピアアドレスを変更することができます。
* There is a strategy for ensuring that the new peer address is able to receive and process DTLS records. No strategy is mandated by this specification, but see note (*) below.
* 新しいピアアドレスがDTLSレコードを受信して処理できるようにするための戦略があります。この仕様では戦略は義務付けられていませんが、下記の注（*）を参照してください。
The conditions above are necessary to protect against attacks that use datagrams with spoofed addresses or replayed datagrams to trigger attacks. Note that there is no requirement for the use of the anti-replay window mechanism defined in Section 4.1.2.6 of [RFC6347]. Both solutions, the "anti-replay window" or "newer" algorithm, will prevent address updates from replay attacks while the latter will only apply to peer address updates and the former applies to any application layer traffic.
上記の条件は、偽装アドレスまたは再生データグラムを使用して攻撃をトリガーするためにデータグラムを使用する攻撃から保護するために必要です。[RFC6347]の4.1.2.6項で定義されている再生アンチレイプウィンドウメカニズムを使用する必要はありません。どちらのソリューション、「アンチリプレイウィンドウ」または「新しい」アルゴリズムも、後者がピアアドレスの更新にのみ適用され、前者はどのアプリケーションレイヤトラフィックにも適用されます。
Note that datagrams that pass the DTLS cryptographic verification procedures but do not trigger a change of peer address are still valid DTLS records and are still to be passed to the application.
DTLS暗号検証手順を渡すがピアアドレスの変更を引き起こさないデータグラムは、まだ有効なDTLSレコードであり、まだアプリケーションに渡されることに注意してください。
(*) Note: Application protocols that implement protection against spoofed addresses depend on being aware of changes in peer addresses so that they can engage the necessary mechanisms. When delivered such an event, an address validation mechanism specific to the application layer can be triggered -- for example, one that is based on successful exchange of a minimal amount of ping-pong traffic with the peer. Alternatively, a DTLS-specific mechanism may be used, as described in [DTLS-RRC].
（*）注：偽装アドレスに対する保護を実装するアプリケーションプロトコルは、ピアアドレスの変更を認識しているため、必要なメカニズムとエンゲージすることができます。そのようなイベントを配信すると、アプリケーション層に固有のアドレス検証メカニズムをトリガすることができる - 例えば、ピアとの最小量のPing - Pongトラフィックの成功した交換に基づくもの。あるいは、[DTLS-RRC]に記載されているように、DTLS固有の機構を使用することができる。
DTLS implementations MUST silently discard records with bad MACs or that are otherwise invalid.
DTLS実装は、不良されたMACを持つレコードを黙って破棄したり、それ以外の場合は無効です。
Figure 4 shows an example exchange where a CID is used unidirectionally from the client to the server. To indicate that a zero-length CID is present in the "connection_id" extension, we use the notation 'connection_id=empty'.
図4は、CIDがクライアントからサーバへの単方向で使用される交換の例を示しています。「connection_id」拡張子にゼロ長CIDが存在することを示すために、表記「connection_id = empty」を使用します。
Client Server
------ ------
ClientHello -------->
(connection_id=empty)
<-------- HelloVerifyRequest
(cookie)
ClientHello -------->
(connection_id=empty)
(cookie)
ServerHello
(connection_id=100)
Certificate
ServerKeyExchange
CertificateRequest
<-------- ServerHelloDone
Certificate
ClientKeyExchange
CertificateVerify
[ChangeCipherSpec]
Finished -------->
<CID=100>
[ChangeCipherSpec]
<-------- Finished
Application Data ========>
<CID=100>
<======== Application Data
Legend:
伝説：
<...> indicates that a connection ID is used in the record layer (...) indicates an extension [...] indicates a payload other than a handshake message
<...>レコードレイヤ（...）で接続IDが使用されていることを示します（...）拡張子[...]はハンドシェイクメッセージ以外のペイロードを示します。
Figure 4: Example DTLS 1.2 Exchange with CID
図4：DTLS 1.2 CIDとの交換
Note: In the example exchange, the CID is included in the record layer once encryption is enabled. In DTLS 1.2, only one handshake message is encrypted, namely the Finished message. Since the example shows how to use the CID for payloads sent from the client to the server, only the record layer payloads containing the Finished message or application data include a CID.
注：Exchangeの例では、暗号化が有効になるとCIDがレコード層に含まれています。DTLS 1.2では、1つのハンドシェイクメッセージのみが暗号化されています。つまり、完成したメッセージです。この例では、クライアントからサーバーに送信されたペイロードのCIDの使用方法を示しているため、完成したメッセージまたはアプリケーションデータを含むレコードレイヤペイロードのみがCIDを含みます。
The CID replaces the previously used 5-tuple and, as such, introduces an identifier that remains persistent during the lifetime of a DTLS connection. Every identifier introduces the risk of linkability, as explained in [RFC6973].
CIDは、以前に使用されている5タプルを置き換え、そのように、DTLS接続の存続期間中に永続的なままの識別子を導入します。[RFC6973]で説明されているように、すべての識別子がリンク性のリスクを招きます。
An on-path adversary observing the DTLS protocol exchanges between the DTLS client and the DTLS server is able to link the observed payloads to all subsequent payloads carrying the same ID pair (for bidirectional communication). Without multihoming or mobility, the use of the CID exposes the same information as the 5-tuple.
DTLSクライアントとDTLSサーバとの間のDTLSプロトコル交換を観察するオンパス障害は、観察されたペイロードを同じIDペアを搭載したすべてのペイロード（双方向通信用）にリンクすることができる。マルチホームやモビリティがなくても、CIDの使用は5タプルと同じ情報を公開します。
With multihoming, a passive attacker is able to correlate the communication interaction over the two paths. The lack of a CID update mechanism in DTLS 1.2 makes this extension unsuitable for mobility scenarios where correlation must be considered. Deployments that use DTLS in multihoming environments and are concerned about these aspects SHOULD refuse to use CIDs in DTLS 1.2 and switch to DTLS 1.3 where a CID update mechanism is provided and sequence number encryption is available.
マルチホームを使用すると、パッシブ攻撃者は2つのパスを越えて通信相互作用を相関させることができます。DTLS 1.2のCID更新メカニズムの欠如は、この拡張が、相関が考慮されなければならないモビリティシナリオには不適切です。マルチホーム環境でDTLを使用する展開とこれらの側面については、DTLS 1.2のCIDを使用し、CID更新メカニズムが提供され、シーケンス番号の暗号化が可能であるDTLS 1.3に切り替えてください。
This specification introduces record padding for the CID-enhanced record layer, which is a privacy feature not available with the original DTLS 1.2 specification. Padding allows the size of the ciphertext to be inflated, making traffic analysis more difficult. More details about record padding can be found in Section 5.4 and Appendix E.3 of [RFC8446].
この仕様では、CID拡張レコードレイヤのレコードパディングを紹介します。これは、元のDTLS 1.2仕様では利用できないプライバシー機能です。パディングにより、暗号文のサイズを膨張させ、トラフィック分析をより困難にします。記録パディングに関する詳細は、[RFC8446]のセクション5.4および付録E.3にあります。
Finally, endpoints can use the CID to attach arbitrary per-connection metadata to each record they receive on a given connection. This may be used as a mechanism to communicate per-connection information to on-path observers. There is no straightforward way to address this concern with CIDs that contain arbitrary values. Implementations concerned about this aspect SHOULD refuse to use CIDs.
最後に、エンドポイントはCIDを使用して、特定の接続で受信した各レコードに任意の接続ごとのメタデータを接続できます。これは、接続ごとの情報をオンパス観察者に伝達するためのメカニズムとして使用することができる。任意の値を含むCIDとこの懸念に対処するための直接的な方法はありません。この側面に関する実装は、CIDを使用することを拒否する必要があります。
An on-path adversary can create reflection attacks against third parties because a DTLS peer has no means to distinguish a genuine address update event (for example, due to a NAT rebinding) from one that is malicious. This attack is of particular concern when the request is small and the response large. See Section 6 for more on address updates.
DTLSピアが悪意のあるものから本物のアドレス更新イベントを区別する手段がないため、オンパスの敵対者は第三者に対する反射攻撃を作成できます。この攻撃は、要求が小さく、応答が大きい場合に特に懸念されます。アドレス更新プログラムの詳細については、セクション6を参照してください。
Additionally, an attacker able to observe the data traffic exchanged between two DTLS peers is able to replay datagrams with modified IP addresses / port numbers.
さらに、2つのDTLSピア間で交換されるデータトラフィックを観察することができる攻撃者は、データグラムを修正したIPアドレス/ポート番号で再生することができます。
The topic of peer address updates is discussed in Section 6.
ピアアドレスの更新のトピックについては、セクション6で説明されています。
This document implements three IANA updates.
この文書は3つのIANAアップデートを実装しています。
IANA has added an extra column named "DTLS-Only" to the "TLS ExtensionType Values" registry to indicate whether an extension is only applicable to DTLS and to include this document as an additional reference for the registry.
IANAは、拡張子がDTLSにのみ適用され、このドキュメントをレジストリの追加の参照として含めるかどうかを示すために、 "TLS ExtenctType値"レジストリに追加の列を追加しました。
IANA has allocated an entry in the existing "TLS ExtensionType Values" registry for connection_id(54), as described in the table below. Although the value 53 had been allocated by early allocation for a previous version of this document, it is incompatible with this document. Therefore, the early allocation has been deprecated in favor of this assignment.
IANAは、以下の表の説明に従って、Connection_ID（54）の既存の "TLS ExtenctType値"レジストリにエントリを割り当てました。この文書の以前のバージョンの早期割り当てによって値53が割り当てられていましたが、この文書と互換性がありません。したがって、この割り当てはこの割り当てに推奨されていません。
+=======+===============+=====+===========+=============+===========+
| Value |Extension Name | TLS | DTLS-Only | Recommended | Reference |
| | | 1.3 | | | |
+=======+===============+=====+===========+=============+===========+
| 54 |connection_id | CH, | Y | N | RFC 9146 |
| | | SH | | | |
+-------+---------------+-----+-----------+-------------+-----------+
Table 1
表1
A new column, "DTLS-Only", has been added to the registry. The valid entries are "Y" if the extension is only applicable to DTLS, "N" otherwise. All the pre-existing entries are given the value "N".
新しい列「DTLS only」がレジストリに追加されました。拡張子がDTLSにのみ適用可能な場合は、有効なエントリは "y"、そうでない場合は "n"です。既存のすべてのエントリに値 "n"が与えられます。
Note: The value "N" in the "Recommended" column is set because this extension is intended only for specific use cases. This document describes the behavior of this extension for DTLS 1.2 only; it is not applicable to TLS, and its usage for DTLS 1.3 is described in [DTLS13].
注：この拡張機能は特定のユースケースのみを目的としているため、[推奨]列の値「N」が設定されています。このドキュメントでは、DTLS 1.2のみのこの拡張機能について説明します。TLSには適用されず、DTLS 1.3の使用方法は[DTLS13]に記載されています。
IANA has allocated tls12_cid(25) in the "TLS ContentType" registry. The tls12_cid content type is only applicable to DTLS 1.2.
IANAは "TLS ContentType"レジストリにTLS12_CID（25）を割り当てました。TLS12_CIDコンテンツタイプはDTLS 1.2にのみ適用されます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E.およびN. ModAdugu、「データグラムトランスポート層セキュリティバージョン1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<https：//www.rfc-editor.org/info/rfc6347>。
[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, <https://www.rfc-editor.org/info/rfc7366>.
[RFC7366] Gutmann、P.、「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）およびDTLS）」、RFC 7366、DOI 10.17487 / RFC7366、2014年9月、<https：//www.rfc-editor.org/info/rfc7366>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B.、RFC 2119キーワードの「大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] RESCORLA、E。、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、<https：//www.rfc-editor.org/info/rfc8446>。
[DTLS-RRC] Tschofenig, H., Ed. and T. Fossati, "Return Routability Check for DTLS 1.2 and DTLS 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-dtls-rrc-05, 7 March 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls-rrc-05>.
[DTLS-RRC] Tschofenig、H。、ED。T. Fossati、「DTLS 1.2およびDTLS 1.3の返品」、進行中の作業、インターネットドラフト、Draft-IETF-TLS-DTLS-RRC-05,2022、<https：//datatracker.ietf。org / doc / html / fromp-ietf-tls-dtls-rrc-05>。
[DTLS13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-dtls13-43, 30 April 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-43>.
[DTLS13] Rescorla、E.、Tschofenig、H.、およびN. MODADUGU、「データグラムトランスポート層セキュリティ（DTLS）プロトコルバージョン1.3」、進行中の作業、インターネットドラフト、Draft-IETF-TLS-DTLS13-43、2021年4月30日、<https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-43>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M.、R. Smith、「インターネットプロトコルに関するプライバシーに関する考察」、RFC 6973、DOI2017487 / RFC6973、2013年7月、<https：//www.rfc-editor.org/info/rfc6973>。
Acknowledgements
謝辞
We would like to thank Hanno Becker, Martin Duke, Lars Eggert, Ben Kaduk, Warren Kumari, Francesca Palombini, Tom Petch, John Scudder, Sean Turner, Éric Vyncke, and Robert Wilton for their review comments.
私たちはHanno Becker、Martin Duke、Lars Eggert、Ben Kaduk、Warren Kumari、Francesca Palombini、Tom Petch、John Scudder、Sean Turner、エリス・ビンケ、そしてRobert Wiltonのレビューコメントについて感謝します。
Finally, we want to thank the IETF TLS Working Group chairs, Chris Wood, Joseph Salowey, and Sean Turner, for their patience, support, and feedback.
最後に、IETF TLSワーキンググループチェア、クリスウッド、ジョセフサロウェイ、スーンターナー、その忍耐、サポート、およびフィードバックに感謝します。
Contributors
貢献者
Many people have contributed to this specification, and we would like to thank the following individuals for their contributions:
多くの人がこの仕様に貢献しており、その貢献のために次の個人に感謝します。
Yin Xinxing Huawei Email: yinxinxing@huawei.com
Yin Xinxing Huawei Email：yinxinxing@huawei.com
Nikos Mavrogiannopoulos RedHat Email: nmav@redhat.com
Nikos MavrogianNopoulos Redhat Eメール：nmav@redhat.com
Tobias Gondrom Email: tobias.gondrom@gondrom.org
Tobias Gondrom Eメール：tobias.gondrom@gondrom.org.
Additionally, we would like to thank the Connection ID task force team members:
さらに、接続IDタスクフォースチームメンバーに感謝します。
* Martin Thomson (Mozilla)
* マーティントムソン（モジラ）
* Christian Huitema (Private Octopus Inc.)
* クリスチャンヘイテマ（プライベートオクトプエンス株式会社）
* Jana Iyengar (Google)
* Jana Iyengar（Google）
* Daniel Kahn Gillmor (ACLU)
* ダニエル・カーン・ジルモール（アール）
* Patrick McManus (Mozilla)
* Patrick Mcmanus（Mozilla）
* Ian Swett (Google)
* イアンスウェット（Google）
* Mark Nottingham (Fastly)
* ノッティンガムマーク（早く）
The task force team discussed various design ideas, including cryptographically generated session IDs using hash chains and public key encryption, but dismissed them due to their inefficiency. The approach described in this specification is the simplest possible design that works, given the limitations of DTLS 1.2. DTLS 1.3 provides better privacy features, and developers are encouraged to switch to the new version of DTLS.
タスクフォースチームは、ハッシュチェーンと公開鍵暗号化を使用して暗号化されたセッションIDを含むさまざまなデザインのアイデアを議論しましたが、非効率性のためにそれらを却下しました。この仕様に記載されているアプローチは、DTLS 1.2の制限を考えると、機能する最も簡単な設計です。DTLS 1.3はより良いプライバシー機能を提供し、開発者はDTLの新しいバージョンに切り替えることをお勧めします。
Authors' Addresses
著者の住所
Eric Rescorla (editor) Mozilla Email: ekr@rtfm.com
Eric Rescorla（編集）Mozilla Eメール：ekr@rtfm.com
Hannes Tschofenig (editor) Arm Limited Email: hannes.tschofenig@arm.com
Hannes Tschofenig（編集）ARM LIMITED Eメール：hannes.tschofenig@arm.com
Thomas Fossati Arm Limited Email: thomas.fossati@arm.com
Thomas Fossati Arm Limited Eメール：Thomas.fossati@arm.com
Achim Kraus Bosch.IO GmbH Email: achim.kraus@bosch.io
Achim Kraus Bosch.io GmbHメール：achim.kraus @ bosch.io.