[要約] RFC 9147は、Datagram Transport Layer Security (DTLS) プロトコルのバージョン1.3に関する文書です。このプロトコルは、データグラムプロトコルを使用するアプリケーションに対して、データのプライバシーと完全性を保護するためのセキュリティ機能を提供します。DTLS 1.3は、改善されたセキュリティ機能と効率性を提供し、特に遅延が許容されないリアルタイムアプリケーションやIoTデバイスなどの環境での使用を目的としています。関連するRFCには、DTLSの以前のバージョンを扱ったRFC 6347や、TLS 1.3に関するRFC 8446などがあります。
Internet Engineering Task Force (IETF) E. Rescorla
Request for Comments: 9147 Mozilla
Obsoletes: 6347 H. Tschofenig
Category: Standards Track Arm Limited
ISSN: 2070-1721 N. Modadugu
Google, Inc.
April 2022
The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
データグラムトランスポート層セキュリティ（DTLS）プロトコルバージョン1.3
Abstract
概要
This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.
このドキュメントでは、データグラムトランスポート層セキュリティ（DTLS）プロトコルのバージョン1.3を指定します。DTLS 1.3を使用すると、クライアント/サーバーアプリケーションは、盗聴、改ざん、およびメッセージの偽造を防ぐように設計された方法でインターネットを介して通信できます。
The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol.
DTLS 1.3プロトコルは、トランスポートレイヤーセキュリティ（TLS）1.3プロトコルに基づいており、注文保護 /非複製性を除き、同等のセキュリティ保証を提供します。基礎となる輸送のデータグラムセマンティクスは、DTLSプロトコルによって保存されます。
This document obsoletes 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/rfc9147.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc9147で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
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. DTLS Design Rationale and Overview
3.1. Packet Loss
3.2. Reordering
3.3. Fragmentation
3.4. Replay Detection
4. The DTLS Record Layer
4.1. Demultiplexing DTLS Records
4.2. Sequence Number and Epoch
4.2.1. Processing Guidelines
4.2.2. Reconstructing the Sequence Number and Epoch
4.2.3. Record Number Encryption
4.3. Transport Layer Mapping
4.4. PMTU Issues
4.5. Record Payload Protection
4.5.1. Anti-Replay
4.5.2. Handling Invalid Records
4.5.3. AEAD Limits
5. The DTLS Handshake Protocol
5.1. Denial-of-Service Countermeasures
5.2. DTLS Handshake Message Format
5.3. ClientHello Message
5.4. ServerHello Message
5.5. Handshake Message Fragmentation and Reassembly
5.6. EndOfEarlyData Message
5.7. DTLS Handshake Flights
5.8. Timeout and Retransmission
5.8.1. State Machine
5.8.2. Timer Values
5.8.3. Large Flight Sizes
5.8.4. State Machine Duplication for Post-Handshake Messages
5.9. Cryptographic Label Prefix
5.10. Alert Messages
5.11. Establishing New Associations with Existing Parameters
6. Example of Handshake with Timeout and Retransmission
6.1. Epoch Values and Rekeying
7. ACK Message
7.1. Sending ACKs
7.2. Receiving ACKs
7.3. Design Rationale
8. Key Updates
9. Connection ID Updates
9.1. Connection ID Example
10. Application Data Protocol
11. Security Considerations
12. Changes since DTLS 1.2
13. Updates Affecting DTLS 1.2
14. IANA Considerations
15. References
15.1. Normative References
15.2. Informative References
Appendix A. Protocol Data Structures and Constant Values
A.1. Record Layer
A.2. Handshake Protocol
A.3. ACKs
A.4. Connection ID Management
Appendix B. Analysis of Limits on CCM Usage
B.1. Confidentiality Limits
B.2. Integrity Limits
B.3. Limits for AEAD_AES_128_CCM_8
Appendix C. Implementation Pitfalls
Contributors
Authors' Addresses
The primary goal of the TLS protocol is to establish an authenticated, confidentiality- and integrity-protected channel between two communicating peers. The TLS protocol is composed of two layers: the TLS record protocol and the TLS handshake protocol. However, TLS must run over a reliable transport channel -- typically TCP [RFC0793].
TLSプロトコルの主な目標は、2つの通信ピア間で認証された機密性、および完全性保護チャネルを確立することです。TLSプロトコルは、TLSレコードプロトコルとTLSハンドシェイクプロトコルの2つのレイヤーで構成されています。ただし、TLSは信頼できる輸送チャネル（通常はTCP [RFC0793]）を介して実行する必要があります。
There are applications that use UDP [RFC0768] as a transport and the Datagram Transport Layer Security (DTLS) protocol has been developed to offer communication security protection for those applications. DTLS is deliberately designed to be as similar to TLS as possible, both to minimize new security invention and to maximize the amount of code and infrastructure reuse.
UDP [RFC0768]を輸送として使用するアプリケーションがあり、データグラムトランスポートレイヤーセキュリティ（DTLS）プロトコルが開発され、これらのアプリケーションに通信セキュリティ保護を提供しています。DTLSは、新しいセキュリティの発明を最小限に抑え、コードとインフラストラクチャの再利用量を最大化するために、可能な限りTLSに似ているように意図的に設計されています。
DTLS 1.0 [RFC4347] was originally defined as a delta from TLS 1.1 [RFC4346], and DTLS 1.2 [RFC6347] was defined as a series of deltas to TLS 1.2 [RFC5246]. There is no DTLS 1.1; that version number was skipped in order to harmonize version numbers with TLS. This specification describes the most current version of the DTLS protocol as a delta from TLS 1.3 [TLS13]. It obsoletes DTLS 1.2.
DTLS 1.0 [RFC4347]は、もともとTLS 1.1 [RFC4346]のデルタとして定義され、DTLS 1.2 [RFC6347]はTLS 1.2 [RFC5246]の一連のDeltasとして定義されました。DTLS 1.1はありません。そのバージョン番号をTLSと調和させるために、そのバージョン番号がスキップされました。この仕様では、TLS 1.3 [TLS13]のDELTAとしてのDTLSプロトコルの最新バージョンを説明しています。DTLS 1.2が廃止されます。
Implementations that speak both DTLS 1.2 and DTLS 1.3 can interoperate with those that speak only DTLS 1.2 (using DTLS 1.2 of course), just as TLS 1.3 implementations can interoperate with TLS 1.2 (see Appendix D of [TLS13] for details). While backwards compatibility with DTLS 1.0 is possible, the use of DTLS 1.0 is not recommended, as explained in Section 3.1.2 of [RFC7525]. [DEPRECATE] forbids the use of DTLS 1.0.
DTLS 1.2とDTLS 1.3の両方を話す実装は、TLS 1.2の実装がTLS 1.2と相互運用できるように、DTLS 1.2のみを話すものと相互運用できます（詳細については[TLS13の付録Dを参照）。DTLS 1.0との後方互換性が可能ですが、[RFC7525]の3.1.2項で説明されているように、DTLS 1.0の使用はお勧めできません。[非推奨] DTLS 1.0の使用を禁止します。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
The following terms are used:
次の用語が使用されます。
client: The endpoint initiating the DTLS connection.
クライアント：DTLS接続を開始するエンドポイント。
association: Shared state between two endpoints established with a DTLS handshake.
関連付け：DTLSハンドシェイクで確立された2つのエンドポイント間の共有状態。
connection: Synonym for association.
接続：協会の同義語。
endpoint: Either the client or server of the connection.
エンドポイント：接続のクライアントまたはサーバーのいずれかです。
epoch: One set of cryptographic keys used for encryption and decryption.
エポック：暗号化と復号化に使用される暗号鍵の1組。
handshake: An initial negotiation between client and server that establishes the parameters of the connection.
ハンドシェイク：接続のパラメータを確立するクライアントとサーバー間の初期ネゴシエーション。
peer: An endpoint. When discussing a particular endpoint, "peer" refers to the endpoint that is remote to the primary subject of discussion.
ピア：エンドポイント。特定のエンドポイントについて議論するとき、「ピア」とは、議論の主要な主題にremote延するエンドポイントを指します。
receiver: An endpoint that is receiving records.
受信者：レコードを受信しているエンドポイント。
sender: An endpoint that is transmitting records.
送信者：レコードを送信しているエンドポイント。
server: The endpoint that did not initiate the DTLS connection.
サーバー：DTLS接続を開始しなかったエンドポイント。
CID: Connection ID.
CID：接続ID。
MSL: Maximum Segment Lifetime.
MSL：最大セグメント寿命。
The reader is assumed to be familiar with [TLS13]. As in TLS 1.3, the HelloRetryRequest has the same format as a ServerHello message, but for convenience we use the term HelloRetryRequest throughout this document as if it were a distinct message.
リーダーは[TLS13]に精通していると見なされます。TLS 1.3と同様に、HelloretryRequestはServerHelloメッセージと同じ形式を持ちますが、便宜上、この文書全体にわたってTERM HelloretryRequestを個別のメッセージであるかのように使用します。
DTLS 1.3 uses network byte order (big-endian) format for encoding messages based on the encoding format defined in [TLS13] and earlier (D)TLS specifications.
DTLS 1.3は、[TLS13]および以前の（d）TLS仕様で定義されたエンコード形式に基づいてメッセージをエンコードするために、ネットワークバイト順序（Big-Endian）形式を使用します。
The reader is also assumed to be familiar with [RFC9146], as this document applies the CID functionality to DTLS 1.3.
このドキュメントはDTLS 1.3にCID機能を適用するので、リーダーは[RFC9146]に精通していると想定されています。
Figures in this document illustrate various combinations of the DTLS protocol exchanges, and the symbols have the following meaning:
この文書の数値は、DTLSプロトコル交換のさまざまな組み合わせを示し、シンボルは次の意味を持ちます。
'+' indicates noteworthy extensions sent in the previously noted message.
''前述のメッセージで送信された注目すべき拡張機能を示します。
'*' indicates optional or situation-dependent messages/extensions that are not always sent.
'*'は、常に送信されるとは限らないオプションまたは状況依存のメッセージ/拡張機能を示します。
'{}' indicates messages protected using keys derived from a [sender]_handshake_traffic_secret.
'{}'は、[送信者] _handshake_traffic_secretから派生したキーを使用して保護されたメッセージを示します。
'[]' indicates messages protected using keys derived from traffic_secret_N.
'[]'は、traffic_secret_nから派生したキーを使用して保護されたメッセージを示します。
The basic design philosophy of DTLS is to construct "TLS over datagram transport". Datagram transport neither requires nor provides reliable or in-order delivery of data. The DTLS protocol preserves this property for application data. Applications such as media streaming, Internet telephony, and online gaming use datagram transport for communication due to the delay-sensitive nature of transported data. The behavior of such applications is unchanged when the DTLS protocol is used to secure communication, since the DTLS protocol does not compensate for lost or reordered data traffic. Note that while low-latency streaming and gaming use DTLS to protect data (e.g., for protection of a WebRTC data channel), telephony utilizes DTLS for key establishment and the Secure Real-time Transport Protocol (SRTP) for protection of data [RFC5763].
DTLSの基本的な設計哲学は「データグラム交通機関を介してTLS」を構成することです。データグラム輸送は、信頼性または順序のデータ配信も必要としていません。DTLSプロトコルはアプリケーションデータのこのプロパティを保持します。メディアストリーミング、インターネットテレフォニー、オンラインゲームなどのアプリケーションは、輸送データの遅延に敏感な性質のために通信のためのデータグラムトランスポートを使用します。DTLSプロトコルは、DTLSプロトコルが紛失または並べ替えられたデータトラフィックを補償しないため、このようなアプリケーションの動作は通信を保護するために使用されていないときは変わりません。低レイテンシストリーミングおよびゲームはDTLSを使用してデータを保護する（例えば、WebRTCデータチャネルの保護のために）、テレフォニーは重要な確立のためにDTLを利用し、データの保護のためのセキュアリアルタイムトランスポートプロトコル（SRTP）[RFC5763]。
TLS cannot be used directly over datagram transports for the following four reasons:
TLSは、次の4つの理由でデータグラムトランスポートを介して直接使用することはできません。
1. TLS relies on an implicit sequence number on records. If a record is not received, then the recipient will use the wrong sequence number when attempting to remove record protection from subsequent records. DTLS solves this problem by adding sequence numbers to records.
1. TLSは、レコード上の暗黙のシーケンス番号に依存しています。レコードが受信されない場合、受信者は、後続のレコードからレコード保護を削除しようとするときに間違ったシーケンス番号を使用します。DTLSは、記録にシーケンス番号を追加することにより、この問題を解決します。
2. The TLS handshake is a lock-step cryptographic protocol. Messages must be transmitted and received in a defined order; any other order is an error. The DTLS handshake includes message sequence numbers to enable fragmented message reassembly and in-order delivery in case datagrams are lost or reordered.
2. TLSハンドシェイクは、ロックステップの暗号化プロトコルです。メッセージは、定義された順序で送信および受信する必要があります。他の注文はエラーです。DTLSハンドシェイクには、データグラムが失われたり並べ替えられたりした場合に、断片化されたメッセージの再組み立てと順序配信を有効にするためのメッセージシーケンス番号が含まれています。
3. Handshake messages are potentially larger than can be contained in a single datagram. DTLS adds fields to handshake messages to support fragmentation and reassembly.
3. ハンドシェイクメッセージは、単一のデータグラムに含まれているよりも潜在的に大きいです。DTLSは、断片化と再構成をサポートするためのハンドシェイクメッセージにフィールドを追加します。
4. Datagram transport protocols are susceptible to abusive behavior effecting denial-of-service (DoS) attacks against nonparticipants. DTLS adds a return-routability check and DTLS 1.3 uses the TLS 1.3 HelloRetryRequest message (see Section 5.1 for details).
4. データグラムトランスポートプロトコルは、非参加者に対するサービス拒否（DOS）攻撃を実現する虐待的な行動の影響を受けやすい。DTLSはリターンルーティブ容量チェックを追加し、DTLS 1.3はTLS 1.3 HelloretryRequestメッセージを使用します（詳細についてはセクション5.1を参照）。
DTLS uses a simple retransmission timer to handle packet loss. Figure 1 demonstrates the basic concept, using the first phase of the DTLS handshake:
DTLSは、単純な再送信タイマーを使用してパケットの損失を処理します。図1は、DTLSハンドシェイクの最初のフェーズを使用して、基本概念を示しています。
Client Server
------ ------
ClientHello ------>
X<-- HelloRetryRequest (lost)
X < - HelloretryRequest（失われた）
[Timer Expires]
[タイマーの有効期限が切れる]
ClientHello ------>
(retransmit)
Figure 1: DTLS Retransmission Example
図1：DTLS再送信例
Once the client has transmitted the ClientHello message, it expects to see a HelloRetryRequest or a ServerHello from the server. However, if the timer expires, the client knows that either the ClientHello or the response from the server has been lost, which causes the client to retransmit the ClientHello. When the server receives the retransmission, it knows to retransmit its HelloRetryRequest or ServerHello.
クライアントがClientHelloメッセージを送信すると、サーバーからHelloretryRequestまたはサーバーヘロが表示されることが期待されます。ただし、タイマーの有効期限が切れた場合、クライアントは、クライアントヘロまたはサーバーからの応答が失われたことを知っており、クライアントはClientHelloを再送信します。サーバーが再送信を受信すると、HelloretryRequestまたはServerHelloを再送信することがわかります。
The server also maintains a retransmission timer for messages it sends (other than HelloRetryRequest) and retransmits when that timer expires. Not applying retransmissions to the HelloRetryRequest avoids the need to create state on the server. The HelloRetryRequest is designed to be small enough that it will not itself be fragmented, thus avoiding concerns about interleaving multiple HelloRetryRequests.
また、サーバーは、送信するメッセージの再送信タイマー（HelloretryRequest以外）を維持し、そのタイマーが期限切れになったときに再送信します。HelloretryRequestに再送信を適用しないと、サーバー上に状態を作成する必要性が回避されます。HelloretryRequestは、それ自体が断片化されないほど小さくなるように設計されているため、複数のHelloretryRequestをインテリのインテリアに懸念することを避けます。
For more detail on timeouts and retransmission, see Section 5.8.
タイムアウトと再送信の詳細については、セクション5.8を参照してください。
In DTLS, each handshake message is assigned a specific sequence number. When a peer receives a handshake message, it can quickly determine whether that message is the next message it expects. If it is, then it processes it. If not, it queues it for future handling once all previous messages have been received.
DTLSでは、各ハンドシェイクメッセージに特定のシーケンス番号が割り当てられます。ピアが握手メッセージを受信すると、そのメッセージが予想される次のメッセージであるかどうかをすばやく判断できます。もしそうなら、それを処理します。そうでない場合は、以前のすべてのメッセージが受信された後、将来の処理のためにキュートします。
TLS and DTLS handshake messages can be quite large (in theory up to 2^24-1 bytes, in practice many kilobytes). By contrast, UDP datagrams are often limited to less than 1500 bytes if IP fragmentation is not desired. In order to compensate for this limitation, each DTLS handshake message may be fragmented over several DTLS records, each of which is intended to fit in a single UDP datagram (see Section 4.4 for guidance). Each DTLS handshake message contains both a fragment offset and a fragment length. Thus, a recipient in possession of all bytes of a handshake message can reassemble the original unfragmented message.
TLSおよびDTLSハンドシェイクメッセージは非常に大きくなる可能性があります（理論的には2^24-1バイトまで、実際には多くのキロバイト）。対照的に、IPフラグメンテーションが望まれない場合、UDPデータグラムは多くの場合1500バイト未満に制限されます。この制限を補うために、各DTLSハンドシェイクメッセージは、単一のUDPデータグラムに適合することを目的としているいくつかのDTLSレコードで断片化される場合があります（ガイダンスについてはセクション4.4を参照）。各DTLSハンドシェイクメッセージには、フラグメントオフセットとフラグメント長の両方が含まれています。したがって、握手メッセージのすべてのバイトを所有している受信者は、元のフラグメントされていないメッセージを再組み立てることができます。
DTLS optionally supports record replay detection. The technique used is the same as in IPsec AH/ESP, by maintaining a bitmap window of received records. Records that are too old to fit in the window and records that have previously been received are silently discarded. The replay detection feature is optional, since packet duplication is not always malicious but can also occur due to routing errors. Applications may conceivably detect duplicate packets and accordingly modify their data transmission strategy.
DTLはオプションでレコードの再生検出をサポートします。使用される技術は、受信したレコードのビットマップウィンドウを維持することによって、IPsec AH / ESPと同じです。ウィンドウに収まるには古すぎるレコードと以前に受信されたレコードは静かに破棄されます。再生検出機能はオプションであるため、パケットの重複は必ずしも悪意のあるものではなく、ルーティングエラーのためにも発生する可能性があります。アプリケーションは、重複したパケットを検出し、したがってデータ伝送戦略を変更する可能性があります。
The DTLS 1.3 record layer is different from the TLS 1.3 record layer and also different from the DTLS 1.2 record layer.
DTLS 1.3レコードレイヤーは、TLS 1.3レコードレイヤーとは異なり、DTLS 1.2レコードレイヤーとも異なります。
1. The DTLSCiphertext structure omits the superfluous version number and type fields.
1. DTLSciphertext構造は、余分なバージョン番号とタイプフィールドを省略します。
2. DTLS adds an epoch and sequence number to the TLS record header. This sequence number allows the recipient to correctly decrypt and verify DTLS records. However, the number of bits used for the epoch and sequence number fields in the DTLSCiphertext structure has been reduced from those in previous versions.
2. DTLSは、TLSレコードヘッダーにエポックとシーケンス番号を追加します。このシーケンス番号は、受信者がDTLSレコードを正しく復号化して検証することを可能にします。ただし、DTLSciphiperText構造体のEpochおよびSequence Numberフィールドに使用されるビット数は、以前のバージョンのものから削減されました。
3. The DTLS epoch serialized in DTLSPlaintext is 2 octets long for compatibility with DTLS 1.2. However, this value is set as the least significant 2 octets of the connection epoch, which is an 8 octet counter incremented on every KeyUpdate. See Section 4.2 for details. The sequence number is set to be the low order 48 bits of the 64 bit sequence number. Plaintext records MUST NOT be sent with sequence numbers that would exceed 2^48-1, so the upper 16 bits will always be 0.
3. DTLSPlantextでシリアル化されたDTLSエポックは、DTLS 1.2との互換性のために2オクテットの長さです。ただし、この値は、すべてのキーアップデートで8オクテットのカウンターが増加する8オクテットのカウンターである接続エポックの最も重要でない2オクテットとして設定されています。詳細については、セクション4.2を参照してください。シーケンス番号は、64ビットシーケンス番号の48ビットが低いように設定されています。プレーンテキストレコードは、2^48-1を超えるシーケンス番号で送信してはなりません。そのため、上部16ビットは常に0になります。
4. The DTLSCiphertext structure has a variable-length header.
4. DTLScipherText構造体には可変長ヘッダーがあります。
DTLSPlaintext records are used to send unprotected records and DTLSCiphertext records are used to send protected records.
DTLSPleantextレコードは、保護されていないレコードを送信するために使用され、DTLScipherTextレコードは保護されたレコードを送信するために使用されます。
The DTLS record formats are shown below. Unless explicitly stated the meaning of the fields is unchanged from previous TLS/DTLS versions.
DTLSレコードフォーマットを以下に示します。明示的に明示的に記載されていない限り、フィールドの意味は以前のTLS / DTLSバージョンから変更されません。
struct {
ContentType type;
ProtocolVersion legacy_record_version;
uint16 epoch = 0
uint48 sequence_number;
uint16 length;
opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext;
struct {
opaque content[DTLSPlaintext.length];
ContentType type;
uint8 zeros[length_of_padding];
} DTLSInnerPlaintext;
struct {
opaque unified_hdr[variable];
opaque encrypted_record[length];
} DTLSCiphertext;
Figure 2: DTLS 1.3 Record Formats
図2：DTLS 1.3レコード形式
legacy_record_version: This value MUST be set to {254, 253} for all records other than the initial ClientHello (i.e., one not generated after a HelloRetryRequest), where it may also be {254, 255} for compatibility purposes. It MUST be ignored for all purposes. See [TLS13], Appendix D.1 for the rationale for this.
LEGACY_RECORD_VERSION：最初のClientHello以外のすべてのレコード（すなわち、HellOretryRequestの後に生成されていない1つ）について、この値は{254,255}でも互換性を目的としても{254,253}に設定する必要があります。すべての目的で無視する必要があります。この根拠のための議論については、[TLS13]、付録D.1を参照してください。
epoch: The least significant 2 bytes of the connection epoch value.
エポック：接続の最小2バイトのエポック値。
unified_hdr: The unified header (unified_hdr) is a structure of variable length, shown in Figure 3.
unified_hdr：unifiedヘッダー（unified_hdr）は、図3に示すように変数長の構造です。
encrypted_record: The encrypted form of the serialized DTLSInnerPlaintext structure.
encrypted_record：シリアル化されたdtlsinnerplaintext構造の暗号化された形式。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0|0|1|C|S|L|E E|
+-+-+-+-+-+-+-+-+
| Connection ID | Legend:
| (if any, |
/ length as / C - Connection ID (CID) present
| negotiated) | S - Sequence number length
+-+-+-+-+-+-+-+-+ L - Length present
| 8 or 16 bit | E - Epoch
|Sequence Number|
+-+-+-+-+-+-+-+-+
| 16 bit Length |
| (if present) |
+-+-+-+-+-+-+-+-+
Figure 3: DTLS 1.3 Unified Header
図3：DTLS 1.3 Unified Header
Fixed Bits: The three high bits of the first byte of the unified header are set to 001. This ensures that the value will fit within the DTLS region when multiplexing is performed as described in [RFC7983]. It also ensures that distinguishing encrypted DTLS 1.3 records from encrypted DTLS 1.2 records is possible when they are carried on the same host/port quartet; such multiplexing is only possible when CIDs [RFC9146] are in use, in which case DTLS 1.2 records will have the content type tls12_cid (25).
固定ビット：Unified Headerの最初のバイトの3つのハイビットは001に設定されています。これにより、[RFC7983]に記載されているように多重化が実行されると、値がDTLS領域内に収まるようになります。また、暗号化されたDTLS 1.3レコードからの暗号化されたDTLS 1.3レコードが同じホスト/ポートカルテットで持ち運ばれるときに可能です。このような多重化は、CIDS [RFC9146]が使用されている場合にのみ可能です。その場合、DTLS 1.2レコードにはコンテンツタイプTLS12_CID（25）があります。
C: The C bit (0x10) is set if the Connection ID is present.
C：接続IDが存在する場合は、Cビット（0x10）が設定されます。
S: The S bit (0x08) indicates the size of the sequence number. 0 means an 8-bit sequence number, 1 means 16-bit. Implementations MAY mix sequence numbers of different lengths on the same connection.
S：Sビット（0x08）は、シーケンス番号のサイズを示します。0は8ビットシーケンス番号を意味し、1は16ビットを意味します。実装では、同じ接続で異なる長さのシーケンス番号を組み合わせることができます。
L: The L bit (0x04) is set if the length is present.
L：長さが存在する場合はLビット（0x04）が設定されます。
E: The two low bits (0x03) include the low-order two bits of the epoch.
E：2つの低ビット（0x03）には、エポックの下位2ビットが含まれています。
Connection ID: Variable-length CID. The CID functionality is described in [RFC9146]. An example can be found in Section 9.1.
接続ID：可変長CID。CID機能は[RFC9146]で説明されています。例は、セクション9.1にあります。
Sequence Number: The low-order 8 or 16 bits of the record sequence number. This value is 16 bits if the S bit is set to 1, and 8 bits if the S bit is 0.
シーケンス番号：レコードシーケンス番号の低次8または16ビット。この値は、Sビットが1に設定されている場合は16ビット、Sビットが0の場合は8ビットです。
Length: Identical to the length field in a TLS 1.3 record.
長さ：TLS 1.3レコードの長さフィールドと同じ。
As with previous versions of DTLS, multiple DTLSPlaintext and DTLSCiphertext records can be included in the same underlying transport datagram.
以前のバージョンのDTLSと同様に、複数のDTLSPleantextとDTLScipherTextレコードを同じ基礎となるトランスポートデータグラムに含めることができます。
Figure 4 illustrates different record headers.
図4は異なるレコードヘッダを示す。
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Content Type | |0|0|1|1|1|1|E E| |0|0|1|0|0|0|E E|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| 16 bit | | | |8 bit Seq. No. |
| Version | / Connection ID / +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ | | | |
| 16 bit | +-+-+-+-+-+-+-+-+ | Encrypted |
| Epoch | | 16 bit | / Record /
+-+-+-+-+-+-+-+-+ |Sequence Number| | |
| | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | | 16 bit |
| 48 bit | | Length | DTLSCiphertext
|Sequence Number| +-+-+-+-+-+-+-+-+ Structure
| | | | (minimal)
| | | Encrypted |
+-+-+-+-+-+-+-+-+ / Record /
| 16 bit | | |
| Length | +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
| | DTLSCiphertext
| | Structure
/ Fragment / (full)
| |
+-+-+-+-+-+-+-+-+
DTLSPlaintext Structure
DTLSPLAINTEXT構造体
Figure 4: DTLS 1.3 Header Examples
図4：DTLS 1.3ヘッダの例
The length field MAY be omitted by clearing the L bit, which means that the record consumes the entire rest of the datagram in the lower level transport. In this case, it is not possible to have multiple DTLSCiphertext format records without length fields in the same datagram. Omitting the length field MUST only be used for the last record in a datagram. Implementations MAY mix records with and without length fields on the same connection.
Lビットをクリアすることによって長さフィールドは省略されてもよい。これは、レコードが下位レベルのトランスポートでデータグラムの残りの部分全体を消費することを意味します。この場合、同じデータグラムに長さフィールドなしで複数のDTLScipherTextフォーマットレコードを持つことはできません。長さフィールドを省略するには、データグラム内の最後のレコードにのみ使用する必要があります。実装は、同じ接続に長さフィールドの有無にかかわらずレコードを混在させることができます。
If a Connection ID is negotiated, then it MUST be contained in all datagrams. Sending implementations MUST NOT mix records from multiple DTLS associations in the same datagram. If the second or later record has a connection ID which does not correspond to the same association used for previous records, the rest of the datagram MUST be discarded.
接続IDがネゴシエートされている場合、すべてのデータグラムに含める必要があります。実装の送信は、同じデータグラムの複数のDTLSアソシエーションからレコードを組み合わせてはなりません。2番目以降のレコードに、以前のレコードに使用された同じ関連付けに対応しない接続IDがある場合、データグラムの残りの部分を破棄する必要があります。
When expanded, the epoch and sequence number can be combined into an unpacked RecordNumber structure, as shown below:
拡張された場合、以下に示すように、エポック番号とシーケンス番号を解凍されていないレコード番号構造に組み合わせることができます。
struct {
uint64 epoch;
uint64 sequence_number;
} RecordNumber;
This 128-bit value is used in the ACK message as well as in the "record_sequence_number" input to the Authenticated Encryption with Associated Data (AEAD) function. The entire header value shown in Figure 4 (but prior to record number encryption; see Section 4.2.3) is used as the additional data value for the AEAD function. For instance, if the minimal variant is used, the Associated Data (AD) is 2 octets long. Note that this design is different from the additional data calculation for DTLS 1.2 and for DTLS 1.2 with Connection IDs. In DTLS 1.3 the 64-bit sequence_number is used as the sequence number for the AEAD computation; unlike DTLS 1.2, the epoch is not included.
この128ビット値は、ACKメッセージと、関連するデータ（AEAD）関数を使用した認証された暗号化への「Record_Sequence_Number」入力で使用されます。図4に示すヘッダー値全体（ただし、レコード番号暗号化の前、セクション4.2.3を参照）は、AEAD関数の追加データ値として使用されます。たとえば、最小限のバリアントを使用する場合、関連データ（AD）の長さは2オクターです。この設計は、DTLS 1.2および接続IDを使用したDTLS 1.2の追加データ計算とは異なることに注意してください。DTLS 1.3では、64ビットSequence_NumberがAEAD計算のシーケンス番号として使用されます。DTLS 1.2とは異なり、エポックは含まれていません。
DTLS 1.3's header format is more complicated to demux than DTLS 1.2, which always carried the content type as the first byte. As described in Figure 5, the first byte determines how an incoming DTLS record is demultiplexed. The first 3 bits of the first byte distinguish a DTLS 1.3 encrypted record from record types used in previous DTLS versions and plaintext DTLS 1.3 record types. Hence, the range 32 (0b0010 0000) to 63 (0b0011 1111) needs to be excluded from future allocations by IANA to avoid problems while demultiplexing; see Section 14. Implementations can demultiplex DTLS 1.3 records by examining the first byte as follows:
DTLS 1.3のヘッダーフォーマットはDTLS 1.2よりもDEMUXに複雑です。これは、常にコンテンツタイプを最初のバイトとしました。図5に記載されているように、最初のバイトは、着信DTLSレコードがどのように分離されるかを決定します。最初のバイトの最初の3ビットは、以前のDTLSバージョンおよびPlaintext DTLS 1.3レコードタイプで使用されているレコードタイプからDTLS 1.3暗号化レコードを区別します。したがって、逆多重化中に問題を回避するために、IANAによる将来の割り当てから範囲の32（0B0010 0000）範囲から除外する必要があります。第14章を参照してください。実装は、最初のバイトを次のように調べることによってDTLS 1.3レコードをデマルチプレックスすることができます。
* If the first byte is alert(21), handshake(22), or ack(proposed, 26), the record MUST be interpreted as a DTLSPlaintext record.
* 最初のバイトがアラート（21）、ハンドシェイク（22）、またはACK（提案、26）の場合、レコードはDTLSPLANTEXTレコードとして解釈する必要があります。
* If the first byte is any other value, then receivers MUST check to see if the leading bits of the first byte are 001. If so, the implementation MUST process the record as DTLSCiphertext; the true content type will be inside the protected portion.
* 最初のバイトが他の値である場合、最初のバイトの先頭ビットが001であるかどうかを確認する必要があります。そうであれば、実装はレコードをDTLScipherTextとして処理する必要があります。真のコンテンツタイプは保護された部分の内側になります。
* Otherwise, the record MUST be rejected as if it had failed deprotection, as described in Section 4.5.2.
* それ以外の場合、セクション4.5.2で説明されているように、記録は脱保護に失敗したかのように拒否されなければなりません。
Figure 5 shows this demultiplexing procedure graphically, taking DTLS 1.3 and earlier versions of DTLS into account.
図5は、この逆転換手順をグラフィカルに示しており、DTLS 1.3および以前のバージョンのDTLSを考慮に入れています。
+----------------+
| Outer Content |
| Type (OCT) |
| |
| OCT == 20 -+--> ChangeCipherSpec (DTLS <1.3)
| OCT == 21 -+--> Alert (Plaintext)
| OCT == 22 -+--> DTLSHandshake (Plaintext)
| OCT == 23 -+--> Application Data (DTLS <1.3)
| OCT == 24 -+--> Heartbeat (DTLS <1.3)
packet --> | OCT == 25 -+--> DTLSCiphertext with CID (DTLS 1.2)
| OCT == 26 -+--> ACK (DTLS 1.3, Plaintext)
| |
| | /+----------------+\
| 31 < OCT < 64 -+--> |DTLSCiphertext |
| | |(header bits |
| else | | start with 001)|
| | | /+-------+--------+\
+-------+--------+ |
| |
v Decryption |
+---------+ +------+
| Reject | |
+---------+ v
+----------------+
| Decrypted |
| Content Type |
| (DCT) |
| |
| DCT == 21 -+--> Alert
| DCT == 22 -+--> DTLSHandshake
| DCT == 23 -+--> Application Data
| DCT == 24 -+--> Heartbeat
| DCT == 26 -+--> ACK
| else ------+--> Error
+----------------+
Figure 5: Demultiplexing DTLS 1.2 and DTLS 1.3 Records
図5：DTLS 1.2およびDTLS 1.3レコードの反発
DTLS uses an explicit or partly explicit sequence number, rather than an implicit one, carried in the sequence_number field of the record. Sequence numbers are maintained separately for each epoch, with each sequence_number initially being 0 for each epoch.
DTLSは、記録のsequence_numberフィールドに搭載されている、暗黙的なものではなく、明示的または部分的に明示的なシーケンス番号を使用します。シーケンス番号は各エポックについて個別に維持され、各Sequence_Numberは最初の各エポックについて0である。
The epoch number is initially zero and is incremented each time keying material changes and a sender aims to rekey. More details are provided in Section 6.1.
エポック数は最初はゼロであり、キーイングマテリアルが変更されるたびに増加し、送信者が再キーを目指します。詳細については、セクション6.1に記載されています。
Because DTLS records could be reordered, a record from epoch M may be received after epoch N (where N > M) has begun. Implementations SHOULD discard records from earlier epochs but MAY choose to retain keying material from previous epochs for up to the default MSL specified for TCP [RFC0793] to allow for packet reordering. (Note that the intention here is that implementers use the current guidance from the IETF for MSL, as specified in [RFC0793] or successors, not that they attempt to interrogate the MSL that the system TCP stack is using.)
DTLSレコードを並べ替えることができるので、EPOCH MからのレコードをEPOCH N（N> M）が開始された後に受信されます。実装は以前のエポックからのレコードを廃棄する必要がありますが、Packet Roderingを許可するために、TCP [RFC0793]に指定されたデフォルトのMSLまでの前のエポックからキーワード資料を維持することを選択できます。（ここでの意図は、システムTCPスタックが使用しているMSLの問い合わせを試みることは、[RFC0793]または後継者に指定されているように、実装者はMSLのIETFから現在のガイダンスを使用することです。）
Conversely, it is possible for records that are protected with the new epoch to be received prior to the completion of a handshake. For instance, the server may send its Finished message and then start transmitting data. Implementations MAY either buffer or discard such records, though when DTLS is used over reliable transports (e.g., SCTP [RFC4960]), they SHOULD be buffered and processed once the handshake completes. Note that TLS's restrictions on when records may be sent still apply, and the receiver treats the records as if they were sent in the right order.
逆に、ハンドシェイクが完了する前に、新しいエポックで保護されているレコードが受信されることが可能です。例えば、サーバはその完成メッセージを送信してからデータの送信を開始することができる。実装は、そのようなレコードをバッファまたは破棄することができますが、DTLSが信頼できるトランスポートにわたって使用されます（例えば、SCTP [RFC4960]）、ハンドシェイクが完了すると、それらをバッファリングして処理する必要があります。レコードが送信される可能性がある場合のTLSの制限が適用され、レコードはレコードを正しい順序で送信されたかのように扱います。
Implementations MUST send retransmissions of lost messages using the same epoch and keying material as the original transmission.
実装は、元の送信として同じエポックとキーイングの資料を使用して失われたメッセージの再送信を送信する必要があります。
Implementations MUST either abandon an association or rekey prior to allowing the sequence number to wrap.
実装は、シーケンス番号を折り返す前に、関連付けまたはリリーキーを放棄する必要があります。
Implementations MUST NOT allow the epoch to wrap, but instead MUST establish a new association, terminating the old association.
実装はエポックをラップすることを許可してはいけませんが、代わりに新しい関連付けを確立し、古い関連付けを終了する必要があります。
When receiving protected DTLS records, the recipient does not have a full epoch or sequence number value in the record and so there is some opportunity for ambiguity. Because the full sequence number is used to compute the per-record nonce and the epoch determines the keys, failure to reconstruct these values leads to failure to deprotect the record, and so implementations MAY use a mechanism of their choice to determine the full values. This section provides an algorithm which is comparatively simple and which implementations are RECOMMENDED to follow.
保護されたDTLSレコードを受信する場合、受信者はレコードに完全なエポックまたはシーケンス番号値を持っていないため、あいまいさの機会があります。完全なシーケンス番号が記録ごとのノンセを計算するために使用され、エポックはキーを決定するため、これらの値を再構築できないとレコードを剥奪できないため、実装は選択のメカニズムを使用して完全な値を決定する可能性があります。このセクションでは、比較的単純で、どの実装が従うことをお勧めするアルゴリズムを提供します。
If the epoch bits match those of the current epoch, then implementations SHOULD reconstruct the sequence number by computing the full sequence number which is numerically closest to one plus the sequence number of the highest successfully deprotected record in the current epoch.
エポックビットが現在のエポックのビットと一致する場合、実装は、現在のエポックで最も高い脱保護レコードのシーケンス番号に数値的に最も近い完全なシーケンス番号を計算することにより、シーケンス番号を再構築する必要があります。
During the handshake phase, the epoch bits unambiguously indicate the correct key to use. After the handshake is complete, if the epoch bits do not match those from the current epoch, implementations SHOULD use the most recent past epoch which has matching bits, and then reconstruct the sequence number for that epoch as described above.
握手段階では、エポックは使用する正しいキーを明確に示しています。握手が完了した後、エポックビットが現在のエポックのものと一致しない場合、実装は一致するビットを持つ最新の過去のエポックを使用し、上記のようにそのエポックのシーケンス番号を再構築する必要があります。
In DTLS 1.3, when records are encrypted, record sequence numbers are also encrypted. The basic pattern is that the underlying encryption algorithm used with the AEAD algorithm is used to generate a mask which is then XORed with the sequence number.
DTLS 1.3では、レコードが暗号化されている場合、レコードシーケンス番号も暗号化されます。基本パターンは、AEDアルゴリズムで使用される基礎となる暗号化アルゴリズムを使用してマスクを生成することで、シーケンス番号とXORSを生成することです。
When the AEAD is based on AES, then the mask is generated by computing AES-ECB on the first 16 bytes of the ciphertext:
AEADがAESに基づいている場合、マスクは、暗号文の最初の16バイトでAES-ECBを計算することにより生成されます。
Mask = AES-ECB(sn_key, Ciphertext[0..15])
mask = aes-ecb（sn_key、ciphertext [0..15]）
When the AEAD is based on ChaCha20, then the mask is generated by treating the first 4 bytes of the ciphertext as the block counter and the next 12 bytes as the nonce, passing them to the ChaCha20 block function (Section 2.3 of [CHACHA]):
AEADがChacha20に基づいている場合、マスクは、Ciphertextの最初の4バイトをブロックカウンターとして、次の12バイトをNonCeとして扱い、Chacha20ブロック関数（[Chacha]のセクション2.3）に渡すことで生成されます。：
Mask = ChaCha20(sn_key, Ciphertext[0..3], Ciphertext[4..15])
mask = chacha20（sn_key、ciphertext [0..3]、ciphertext [4..15]）
The sn_key is computed as follows:
SN_KEYは次のように計算されます。
[sender]_sn_key = HKDF-Expand-Label(Secret, "sn", "", key_length)
[送信者] _SN_KEY = hkdf-expand-label（secret、 "sn"、 ""、key_length）
[sender] denotes the sending side. The per-epoch Secret value to be used is described in Section 7.3 of [TLS13]. Note that a new key is used for each epoch: because the epoch is sent in the clear, this does not result in ambiguity.
[送信者]送信側を表します。使用するエポック秘密値は、[TLS13]のセクション7.3に記載されている。エポックごとに新しいキーが使用されていることに注意してください。エポックは明確に送信されるため、これはあいまいさにはなりません。
The encrypted sequence number is computed by XORing the leading bytes of the mask with the on-the-wire representation of the sequence number. Decryption is accomplished by the same process.
暗号化されたシーケンス番号は、シーケンス番号のオンザワイヤ表現でマスクの先行バイトをXaringすることによって計算されます。復号化は同じプロセスによって達成されます。
This procedure requires the ciphertext length to be at least 16 bytes. Receivers MUST reject shorter records as if they had failed deprotection, as described in Section 4.5.2. Senders MUST pad short plaintexts out (using the conventional record padding mechanism) in order to make a suitable-length ciphertext. Note that most of the DTLS AEAD algorithms have a 16 byte authentication tag and need no padding. However, some algorithms, such as TLS_AES_128_CCM_8_SHA256, have a shorter authentication tag and may require padding for short inputs.
この手順では、暗号文の長さが少なくとも16バイトである必要があります。セクション4.5.2で説明されているように、受信者は脱保護に失敗したかのように短い記録を拒否する必要があります。送信者は、適切な長さの暗号文を作成するために、短いプレーンテキストを（従来のレコードパディングメカニズムを使用して）パッドアウトする必要があります。DTLS AEADアルゴリズムのほとんどには16バイト認証タグがあり、パディングが必要ではないことに注意してください。ただし、TLS_AES_128_CCM_8_SHA256などの一部のアルゴリズムには、認証タグが短く、短い入力にパディングが必要になる場合があります。
Future cipher suites, which are not based on AES or ChaCha20, MUST define their own record sequence number encryption in order to be used with DTLS.
AESまたはCHACHA20に基づいていない将来の暗号スイートは、DTLSで使用されるために独自のレコードシーケンス番号の暗号化を定義する必要があります。
Note that sequence number encryption is only applied to the DTLSCiphertext structure and not to the DTLSPlaintext structure, even though it also contains a sequence number.
シーケンス番号暗号化は、シーケンス番号も含まれていても、DTLSPLANTEXT構造にはDTLSciphertext構造にのみ適用されることに注意してください。
DTLS messages MAY be fragmented into multiple DTLS records. Each DTLS record MUST fit within a single datagram. In order to avoid IP fragmentation, clients of the DTLS record layer SHOULD attempt to size records so that they fit within any Path MTU (PMTU) estimates obtained from the record layer. For more information about PMTU issues, see Section 4.4.
DTLSメッセージは、複数のDTLSレコードに断片化される場合があります。各DTLSレコードは、単一のデータグラム内に適合する必要があります。IPの断片化を回避するために、DTLSレコードレイヤーのクライアントは、レコード（PMTU）の推定値に適合するように、レコードのサイズをサイズしようとする必要があります。PMTUの問題の詳細については、セクション4.4を参照してください。
Multiple DTLS records MAY be placed in a single datagram. Records are encoded consecutively. The length field from DTLS records containing that field can be used to determine the boundaries between records. The final record in a datagram can omit the length field. The first byte of the datagram payload MUST be the beginning of a record. Records MUST NOT span datagrams.
複数のDTLSレコードを単一のデータグラムに配置できます。レコードは連続してエンコードされています。そのフィールドを含むDTLSレコードからの長さフィールドは、レコード間の境界を決定するために使用できます。データグラムの最後のレコードは、長さフィールドを省略できます。データグラムペイロードの最初のバイトはレコードの先頭でなければなりません。レコードはデータグラムに掲載してはいけません。
DTLS records without CIDs do not contain any association identifiers, and applications must arrange to multiplex between associations. With UDP, the host/port number is used to look up the appropriate security association for incoming records without CIDs.
CIDのないDTLSレコードには関連性の識別子が含まれておらず、アプリケーションはアソシエーション間の多重に手配する必要があります。UDPを使用すると、ホスト/ポート番号を使用して、CIDなしで着信レコードに適切なセキュリティ協会を検索します。
Some transports, such as DCCP [RFC4340], provide their own sequence numbers. When carried over those transports, both the DTLS and the transport sequence numbers will be present. Although this introduces a small amount of inefficiency, the transport layer and DTLS sequence numbers serve different purposes; therefore, for conceptual simplicity, it is superior to use both sequence numbers.
DCCP [RFC4340]などの一部のトランスポートは、独自のシーケンス番号を提供します。これらの輸送機関を継承すると、DTLと輸送シーケンス番号の両方が存在します。これは少量の非効率性を導入しますが、輸送層とDTLSシーケンス番号はさまざまな目的を果たします。したがって、概念的なシンプルさのために、両方のシーケンス番号を使用するよりも優れています。
Some transports provide congestion control for traffic carried over them. If the congestion window is sufficiently narrow, DTLS handshake retransmissions may be held rather than transmitted immediately, potentially leading to timeouts and spurious retransmission. When DTLS is used over such transports, care should be taken not to overrun the likely congestion window. [RFC5238] defines a mapping of DTLS to DCCP that takes these issues into account.
一部の輸送機は、それらを引き継がれた交通に混雑制御を提供します。輻輳ウィンドウが十分に狭い場合、DTLSハンドシェイクの再送信はすぐに送信されるのではなく保持される場合があり、タイムアウトや偽りの再送信につながる可能性があります。このような輸送でDTLが使用される場合、輻輳ウィンドウをオーバーランしないように注意する必要があります。[RFC5238]は、これらの問題を考慮に入れるDCCPへのDTLのマッピングを定義します。
In general, DTLS's philosophy is to leave PMTU discovery to the application. However, DTLS cannot completely ignore the PMTU for three reasons:
一般に、DTLSの哲学は、PMTUの発見をアプリケーションに任せることです。ただし、DTLは3つの理由でPMTUを完全に無視することはできません。
* The DTLS record framing expands the datagram size, thus lowering the effective PMTU from the application's perspective.
* DTLSレコードフレーミングはデータグラムサイズを拡大し、実効PMTUをアプリケーションの視点から下げます。
* In some implementations, the application may not directly talk to the network, in which case the DTLS stack may absorb ICMP "Datagram Too Big" indications [RFC1191] or ICMPv6 "Packet Too Big" indications [RFC4443].
* いくつかの実装では、アプリケーションがネットワークに直接通知することはできません。その場合、DTLSスタックはICMP「データグラムが大きすぎる」datagramを吸収する可能性があります。
* The DTLS handshake messages can exceed the PMTU.
* DTLSハンドシェイクメッセージはPMTUを超えることができます。
In order to deal with the first two issues, the DTLS record layer SHOULD behave as described below.
最初の2つの問題に対処するために、DTLSレコードレイヤーは以下に説明するように動作する必要があります。
If PMTU estimates are available from the underlying transport protocol, they should be made available to upper layer protocols. In particular:
PMTU推定値が基礎となるトランスポートプロトコルから利用可能である場合、それらは上位レイヤプロトコルに利用可能にされるべきです。特に：
* For DTLS over UDP, the upper layer protocol SHOULD be allowed to obtain the PMTU estimate maintained in the IP layer.
* UDPを介したDTLSの場合、上層プロトコルは、IPレイヤーで維持されているPMTU推定値を取得することを許可する必要があります。
* For DTLS over DCCP, the upper layer protocol SHOULD be allowed to obtain the current estimate of the PMTU.
* DCCPを介したDTLSの場合、上層層プロトコルをPMTUの現在の推定値を取得できるようにする必要があります。
* For DTLS over TCP or SCTP, which automatically fragment and reassemble datagrams, there is no PMTU limitation. However, the upper layer protocol MUST NOT write any record that exceeds the maximum record size of 2^14 bytes.
* データグラムを自動的にフラグメント化して再組み立てするTCPまたはSCTP上のDTLSの場合、PMTUの制限はありません。ただし、上位レイヤプロトコルは、最大レコードサイズ2 ^ 14バイトを超えるレコードを書き込まれてはいけません。
The DTLS record layer SHOULD also allow the upper layer protocol to discover the amount of record expansion expected by the DTLS processing; alternately, it MAY report PMTU estimates minus the estimated expansion from the transport layer and DTLS record framing.
DTLSレコードレイヤーは、上位レイヤプロトコルがDTLS処理によって予想されるレコード拡張の量を発見することもできます。あるいは、PMTU推定値からトランスポート層およびDTLSレコードフレーミングからの推定拡大を引いたものに報告することができる。
Note that DTLS does not defend against spoofed ICMP messages; implementations SHOULD ignore any such messages that indicate PMTUs below the IPv4 and IPv6 minimums of 576 and 1280 bytes, respectively.
DTLSは、偽装されたICMPメッセージに対して損なわれません。実装は、それぞれIPv4およびIPv6の最小値576および1280バイトの下のPMTUSを示すそのようなメッセージを無視するべきです。
If there is a transport protocol indication that the PMTU was exceeded (either via ICMP or via a refusal to send the datagram as in Section 14 of [RFC4340]), then the DTLS record layer MUST inform the upper layer protocol of the error.
PMTUを超えたというトランスポートプロトコルの表示がある場合（ICMPを介して、または[RFC4340]セクション14のようにデータグラムを送信することを拒否します）、DTLSレコードレイヤーはエラーの上層プロトコルに通知する必要があります。
The DTLS record layer SHOULD NOT interfere with upper layer protocols performing PMTU discovery, whether via [RFC1191] and [RFC4821] for IPv4 or via [RFC8201] for IPv6. In particular:
DTLSレコード層は、IPv4の場合、またはIPv6の[RFC8201]を介して[RFC1191]および[RFC4821]を介してPMTU発見を実行する上層プロトコルを妨害しないでください。特に：
* Where allowed by the underlying transport protocol, the upper layer protocol SHOULD be allowed to set the state of the Don't Fragment (DF) bit (in IPv4) or prohibit local fragmentation (in IPv6).
* 基礎となるトランスポートプロトコルによって許可されている場合、上位レイヤプロトコルは、NOTフラグメント（IPv4）の状態（IPv4）の状態を設定するか、ローカルフラグメンテーションを禁止する必要があります（IPv6）。
* If the underlying transport protocol allows the application to request PMTU probing (e.g., DCCP), the DTLS record layer SHOULD honor this request.
* 基礎となるトランスポートプロトコルによって、アプリケーションがPMTUプロービング（例えばDCCP）を要求できる場合、DTLSレコードレイヤはこの要求を尊重する必要があります。
The final issue is the DTLS handshake protocol. From the perspective of the DTLS record layer, this is merely another upper layer protocol. However, DTLS handshakes occur infrequently and involve only a few round trips; therefore, the handshake protocol PMTU handling places a premium on rapid completion over accurate PMTU discovery. In order to allow connections under these circumstances, DTLS implementations SHOULD follow the following rules:
最終的な問題は、DTLSハンドシェイクプロトコルです。DTLSレコードレイヤーの観点から見ると、これは単なる別の上層層プロトコルにすぎません。ただし、DTLSハンドシェイクはまれに発生し、数回の往復のみが含まれます。したがって、ハンドシェイクプロトコルPMTUハンドリングは、正確なPMTU発見よりも迅速な完了時にプレミアムになります。これらの状況下で接続を許可するために、DTLSの実装は次のルールに従う必要があります。
* If the DTLS record layer informs the DTLS handshake layer that a message is too big, the handshake layer SHOULD immediately attempt to fragment the message, using any existing information about the PMTU.
* DTLSレコードレイヤーが、メッセージが大きすぎることをDTLSハンドシェイクレイヤーに通知する場合、PMTUに関する既存の情報を使用して、握手レイヤーがメッセージをすぐに断片化しようとする必要があります。
* If repeated retransmissions do not result in a response, and the PMTU is unknown, subsequent retransmissions SHOULD back off to a smaller record size, fragmenting the handshake message as appropriate. This specification does not specify an exact number of retransmits to attempt before backing off, but 2-3 seems appropriate.
* 繰り返しの再送信が応答をもたらさず、PMTUが不明である場合、その後の再送信はより小さなレコードサイズに戻し、必要に応じてハンドシェイクメッセージを断片化する必要があります。この仕様では、バックアップする前に試行するための正確な再送信数を指定していませんが、2-3は適切であるようです。
Like TLS, DTLS transmits data as a series of protected records. The rest of this section describes the details of that format.
TLSと同様に、DTLSは一連の保護レコードとしてデータを送信します。このセクションの残りの部分では、その形式の詳細について説明します。
Each DTLS record contains a sequence number to provide replay protection. Sequence number verification SHOULD be performed using the following sliding window procedure, borrowed from Section 3.4.3 of [RFC4303]. Because each epoch resets the sequence number space, a separate sliding window is needed for each epoch.
各DTLSレコードには、再生保護を提供するためのシーケンス番号が含まれています。シーケンス番号検証は、[RFC4303]のセクション3.4.3から借用された次のスライディングウィンドウ手順を使用して実行する必要があります。各エポックはシーケンス番号スペースをリセットするので、各エポックには別のスライディングウィンドウが必要です。
The received record counter for an epoch MUST be initialized to zero when that epoch is first used. For each received record, the receiver MUST verify that the record contains a sequence number that does not duplicate the sequence number of any other record received in that epoch during the lifetime of the association. This check SHOULD happen after deprotecting the record; otherwise, the record discard might itself serve as a timing channel for the record number. Note that computing the full record number from the partial is still a potential timing channel for the record number, though a less powerful one than whether the record was deprotected.
そのエポックが最初に使用される場合、エポックの受信したレコードカウンターはゼロに初期化する必要があります。受信したレコードごとに、受信者は、レコードに、協会の生涯中にそのエポックで受け取った他のレコードのシーケンス番号を複製しないシーケンス番号が含まれていることを確認する必要があります。このチェックは、レコードを剥奪した後に発生するはずです。それ以外の場合、レコード廃棄自体がレコード番号のタイミングチャネルとして機能する可能性があります。部分的な記録番号を計算することは、レコード番号の潜在的なタイミングチャネルであることに注意してください。
Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.) The receiver SHOULD pick a window large enough to handle any plausible reordering, which depends on the data rate. (The receiver does not notify the sender of the window size.)
複製はスライド受信ウィンドウを使用して拒否されます。（ウィンドウがどのように実装されているかは地域的な問題ですが、次のテキストは実装が展示する機能を説明しています。）受信者は、データレートに依存するあらゆる順序を処理するのに十分な大きさのウィンドウを選択する必要があります。（受信者はウィンドウサイズの送信者に通知しません。）
The "right" edge of the window represents the highest validated sequence number value received in the epoch. Records that contain sequence numbers lower than the "left" edge of the window are rejected. Records falling within the window are checked against a list of received records within the window. An efficient means for performing this check, based on the use of a bit mask, is described in Section 3.4.3 of [RFC4303]. If the received record falls within the window and is new, or if the record is to the right of the window, then the record is new.
ウィンドウの「右」の端は、エポックで受け取った最高の検証されたシーケンス数値を表します。ウィンドウの「左」エッジよりも低いシーケンス番号を含むレコードは拒否されます。ウィンドウ内にあるレコードは、ウィンドウ内の受信したレコードのリストに対してチェックされます。ビットマスクの使用に基づいて、このチェックを実行するための効率的な手段は、[RFC4303]のセクション3.4.3で説明されています。受信したレコードがウィンドウ内にあり、新品である場合、またはレコードがウィンドウの右側にある場合、レコードは新しいものです。
The window MUST NOT be updated due to a received record until that record has been deprotected successfully.
そのレコードが正常に解凍されるまで、受信したレコードのためにウィンドウを更新してはいけません。
Unlike TLS, DTLS is resilient in the face of invalid records (e.g., invalid formatting, length, MAC, etc.). In general, invalid records SHOULD be silently discarded, thus preserving the association; however, an error MAY be logged for diagnostic purposes. Implementations which choose to generate an alert instead MUST generate fatal alerts to avoid attacks where the attacker repeatedly probes the implementation to see how it responds to various types of error. Note that if DTLS is run over UDP, then any implementation which does this will be extremely susceptible to DoS attacks because UDP forgery is so easy. Thus, generating fatal alerts is NOT RECOMMENDED for such transports, both to increase the reliability of DTLS service and to avoid the risk of spoofing attacks sending traffic to unrelated third parties.
TLSとは異なり、DTLは無効なレコード（無効なフォーマット、長さ、MACなど）に直面して回復力があります。一般に、無効な記録は静かに廃棄されるべきであるため、協会を維持する必要があります。ただし、診断目的でエラーが記録される場合があります。代わりにアラートを生成することを選択する実装は、攻撃者が実装を繰り返しプローブして、さまざまなタイプのエラーにどのように応答するかを確認する攻撃を避けるために致命的なアラートを生成する必要があります。DTLSがUDPを介して実行されている場合、UDP Forgeryが非常に簡単であるため、これを行う実装はDOS攻撃の影響を非常に受けやすいことに注意してください。したがって、DTLSサービスの信頼性を高め、無関係な第三者にトラフィックを送信するリスクを回避するために、そのような輸送には致命的なアラートを生成することは推奨されません。
If DTLS is being carried over a transport that is resistant to forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts because an attacker will have difficulty forging a datagram that will not be rejected by the transport layer.
DTLSが偽造に耐性のある輸送（SCTP-Authを備えたSCTPなど）に運ばれている場合、攻撃者は輸送層によって拒否されないデータグラムを偽造するのが難しいため、アラートを送信する方が安全です。
Note that because invalid records are rejected at a layer lower than the handshake state machine, they do not affect pending retransmission timers.
ハンドシェイクステートマシンより低いレイヤーに無効なレコードが拒否されるため、保留中の再送信タイマーには影響しません。
Section 5.5 of [TLS13] defines limits on the number of records that can be protected using the same keys. These limits are specific to an AEAD algorithm and apply equally to DTLS. Implementations SHOULD NOT protect more records than allowed by the limit specified for the negotiated AEAD. Implementations SHOULD initiate a key update before reaching this limit.
[TLS13]のセクション5.5は、同じキーを使用して保護できるレコード数の制限を定義します。これらの制限はAEDアルゴリズムに固有のもので、DTLSにも同様に適用されます。実装は、ネゴシエートされたAEADに指定された制限によって許可されているよりも多くのレコードを保護しないでください。実装はこの制限に達する前にキーアップデートを開始する必要があります。
[TLS13] does not specify a limit for AEAD_AES_128_CCM, but the analysis in Appendix B shows that a limit of 2^23 packets can be used to obtain the same confidentiality protection as the limits specified in TLS.
[TLS13]はAEAD_AES_128_CCMの制限を指定していませんが、付録Bの分析では、2^23パケットの制限を使用して、TLSで指定された制限と同じ機密性保護を取得できることが示されています。
The usage limits defined in TLS 1.3 exist for protection against attacks on confidentiality and apply to successful applications of AEAD protection. The integrity protections in authenticated encryption also depend on limiting the number of attempts to forge packets. TLS achieves this by closing connections after any record fails an authentication check. In comparison, DTLS ignores any packet that cannot be authenticated, allowing multiple forgery attempts.
TLS 1.3で定義された使用制限は、機密性に対する攻撃に対する保護に存在し、AED保護の成功申請に適用されます。認証された暗号化の整合性保護は、パケットを偽造する試行回数を制限することによっても異なります。TLSは、レコードが認証チェックに失敗した後に接続を閉じることによってこれを達成します。比較すると、DTLSは認証できないパケットを無視し、複数の偽造試行を可能にします。
Implementations MUST count the number of received packets that fail authentication with each key. If the number of packets that fail authentication exceeds a limit that is specific to the AEAD in use, an implementation SHOULD immediately close the connection. Implementations SHOULD initiate a key update with update_requested before reaching this limit. Once a key update has been initiated, the previous keys can be dropped when the limit is reached rather than closing the connection. Applying a limit reduces the probability that an attacker is able to successfully forge a packet; see [AEBounds] and [ROBUST].
実装は、各キーで認証に失敗した受信パケットの数をカウントする必要があります。認証に失敗したパケットの数が使用中のAEADに固有の制限を超える場合、実装は直ちに接続を閉じてください。この制限に達する前に、実装はUPDATE_REQUESTEDを使用したキーアップデートを開始する必要があります。キーアップデートが開始されると、接続を閉じるのではなく、制限に達すると前のキーを削除できます。制限を適用すると、攻撃者がパケットを正常に偽造できる可能性が低下します。[aebounds]と[robust]を参照してください。
For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305, the limit on the number of records that fail authentication is 2^36. Note that the analysis in [AEBounds] supports a higher limit for AEAD_AES_128_GCM and AEAD_AES_256_GCM, but this specification recommends a lower limit. For AEAD_AES_128_CCM, the limit on the number of records that fail authentication is 2^23.5; see Appendix B.
AEAD_AES_128_GCM、AEAD_AES_256_GCM、およびAEAD_CHACHA20_POLY1305の場合、認証に失敗したレコードの数の制限は2^36です。[Aebounds]の分析は、AEAD_AES_128_GCMおよびAEAD_AES_256_GCMの上限をサポートしていることに注意してください。ただし、この仕様は下限を推奨しています。AEAD_AES_128_CCMの場合、認証に失敗したレコードの数の制限は2^23.5です。付録Bを参照してください
The AEAD_AES_128_CCM_8 AEAD, as used in TLS_AES_128_CCM_8_SHA256, does not have a limit on the number of records that fail authentication that both limits the probability of forgery by the same amount and does not expose implementations to the risk of denial of service; see Appendix B.3. Therefore, TLS_AES_128_CCM_8_SHA256 MUST NOT be used in DTLS without additional safeguards against forgery. Implementations MUST set usage limits for AEAD_AES_128_CCM_8 based on an understanding of any additional forgery protections that are used.
TLS_AES_128_CCM_8_SHA256で使用されるAED_AES_128_CCM_8 AEADは、両方とも偽造の可能性を同じ量だけ制限し、実装をサービス拒否のリスクにさらさないレコードの数に制限はありません。付録B.3を参照してください。したがって、TLS_AES_128_CCM_8_SHA256は、偽造に対する追加の保護措置なしでDTLSでは使用してはなりません。実装は、使用される追加の偽造保護の理解に基づいて、AED_AES_128_CCM_8の使用制限を設定する必要があります。
Any TLS cipher suite that is specified for use with DTLS MUST define limits on the use of the associated AEAD function that preserves margins for both confidentiality and integrity. That is, limits MUST be specified for the number of packets that can be authenticated and for the number of packets that can fail authentication before a key update is required. Providing a reference to any analysis upon which values are based -- and any assumptions used in that analysis -- allows limits to be adapted to varying usage conditions.
DTLSで使用するために指定されているTLS暗号スイートは、機密性と完全性の両方でマージンを保持する関連するAEAD関数の使用に関する制限を定義する必要があります。つまり、認証できるパケットの数と、キーアップデートが必要になる前に認証に失敗する可能性のあるパケットの数に制限を指定する必要があります。値が基づいている分析への参照を提供すること、およびその分析で使用される仮定は、さまざまな使用条件に制限を適合させることができます。
DTLS 1.3 reuses the TLS 1.3 handshake messages and flows, with the following changes:
DTLS 1.3は、次の変更を加えて、TLS 1.3ハンドシェイクメッセージとフローを再利用します。
1. To handle message loss, reordering, and fragmentation, modifications to the handshake header are necessary.
1. メッセージの損失、並べ替え、および断片化を処理するには、ハンドシェイクヘッダーへの変更が必要です。
2. Retransmission timers are introduced to handle message loss.
2. メッセージの損失を処理するために再送信タイマーが導入されます。
3. A new ACK content type has been added for reliable message delivery of handshake messages.
3. ハンドシェイクメッセージの信頼できるメッセージ配信のために新しいACKコンテンツタイプが追加されました。
In addition, DTLS reuses TLS 1.3's "cookie" extension to provide a return-routability check as part of connection establishment. This is an important DoS prevention mechanism for UDP-based protocols, unlike TCP-based protocols, for which TCP establishes return-routability as part of the connection establishment.
さらに、DTLSはTLS 1.3の「Cookie」拡張機能を再利用して、接続確立の一環としてリターンルーティブ可能性チェックを提供します。これは、TCPベースのプロトコルとは異なり、UDPベースのプロトコルの重要なDOS予防メカニズムであり、TCPは接続確立の一部としてリターンリューション可能性を確立します。
DTLS implementations do not use the TLS 1.3 "compatibility mode" described in Appendix D.4 of [TLS13]. DTLS servers MUST NOT echo the "legacy_session_id" value from the client and endpoints MUST NOT send ChangeCipherSpec messages.
DTLS実装では、[TLS13]の付録D.4に記載されているTLS 1.3「互換モード」を使用しません。DTLSサーバーは、クライアントとエンドポイントから「legacy_session_id」値をエコーしてはなりません。
With these exceptions, the DTLS message formats, flows, and logic are the same as those of TLS 1.3.
これらの例外を使用すると、DTLSメッセージフォーマット、フロー、およびロジックはTLS 1.3のものと同じです。
Datagram security protocols are extremely susceptible to a variety of DoS attacks. Two attacks are of particular concern:
データグラムセキュリティプロトコルは、さまざまなDOS攻撃の影響を非常に受けやすいです。2つの攻撃は特に懸念されます。
1. An attacker can consume excessive resources on the server by transmitting a series of handshake initiation requests, causing the server to allocate state and potentially to perform expensive cryptographic operations.
1. 攻撃者は、一連のハンドシェイクの開始要求を送信することによってサーバー上の過度のリソースを消費し、サーバーに状態が状態があり、潜在的に高価な暗号操作を実行することによって消費できます。
2. An attacker can use the server as an amplifier by sending connection initiation messages with a forged source address that belongs to a victim. The server then sends its response to the victim machine, thus flooding it. Depending on the selected parameters, this response message can be quite large, as is the case for a Certificate message.
2. 攻撃者は、被害者に属する偽の送信元アドレスを持つ接続開始メッセージを送信することによって、アンプとしてサーバーを使用できます。その後、サーバーはその応答を犠牲Machineに送信し、それをフラッディングします。選択されたパラメータによっては、証明書メッセージの場合と同様に、この応答メッセージは非常に大きくなる可能性があります。
In order to counter both of these attacks, DTLS borrows the stateless cookie technique used by Photuris [RFC2522] and IKE [RFC7296]. When the client sends its ClientHello message to the server, the server MAY respond with a HelloRetryRequest message. The HelloRetryRequest message, as well as the "cookie" extension, is defined in TLS 1.3. The HelloRetryRequest message contains a stateless cookie (see [TLS13], Section 4.2.2). The client MUST send a new ClientHello with the cookie added as an extension. The server then verifies the cookie and proceeds with the handshake only if it is valid. This mechanism forces the attacker/client to be able to receive the cookie, which makes DoS attacks with spoofed IP addresses difficult. This mechanism does not provide any defense against DoS attacks mounted from valid IP addresses.
これらの攻撃の両方に対抗するために、DTLはPHOTURIS [RFC2522]とIKE [RFC7296]で使用されるステートレスCookie技術を借ります。クライアントがそのClientHelloメッセージをサーバーに送信すると、サーバーはHelloretryRequestメッセージで応答することがあります。HelloretryRequestメッセージ、および "Cookie"拡張子はTLS 1.3で定義されています。HelloretryRequestメッセージにはステートレスCookieが含まれています（[TLS13]、セクション4.2.2）。クライアントは、拡張子として追加されたCookieを使用して新しいClientHelloを送信する必要があります。その後、サーバーはCookieを検証し、有効な場合にのみハンドシェイクを進めます。このメカニズムは、攻撃者/クライアントがCookieを受信できるように強制します。これにより、偽装IPアドレスでDOS攻撃が困難になります。このメカニズムは、有効なIPアドレスからマウントされたDOS攻撃に対する防御は提供されていません。
The DTLS 1.3 specification changes how cookies are exchanged compared to DTLS 1.2. DTLS 1.3 reuses the HelloRetryRequest message and conveys the cookie to the client via an extension. The client receiving the cookie uses the same extension to place the cookie subsequently into a ClientHello message. DTLS 1.2, on the other hand, used a separate message, namely the HelloVerifyRequest, to pass a cookie to the client and did not utilize the extension mechanism. For backwards compatibility reasons, the cookie field in the ClientHello is present in DTLS 1.3 but is ignored by a DTLS 1.3-compliant server implementation.
DTLS 1.3仕様は、DTLS 1.2と比較してCookieの交換方法を変更します。DTLS 1.3は、HelloretryRequestメッセージを再利用し、拡張機能を介してクッキーをクライアントに伝えます。Cookieを受信するクライアントは、同じ拡張機能を使用してCookieをClientHelloメッセージに配置します。一方、DTLS 1.2は、別のメッセージ、つまりHelloverifeRequestを使用してクライアントにCookieを渡し、拡張メカニズムを利用しませんでした。後方互換性の理由から、ClientHelloのCookieフィールドはDTLS 1.3に存在しますが、DTLS 1.3に準拠したサーバーの実装では無視されます。
The exchange is shown in Figure 6. Note that the figure focuses on the cookie exchange; all other extensions are omitted.
交換を図6に示します。図は、Cookie Exchangeに焦点を当てていることに注意してください。他のすべての拡張機能は省略されています。
Client Server
------ ------
ClientHello ------>
<----- HelloRetryRequest
+ cookie
ClientHello ------>
+ cookie
[Rest of handshake]
[ハンドシェイクの静止]
Figure 6: DTLS Exchange with HelloRetryRequest Containing the "cookie" Extension
図6：「Cookie」拡張子を含むHelloretryRequestとのDTLS交換
The "cookie" extension is defined in Section 4.2.2 of [TLS13]. When sending the initial ClientHello, the client does not have a cookie yet. In this case, the "cookie" extension is omitted and the legacy_cookie field in the ClientHello message MUST be set to a zero-length vector (i.e., a zero-valued single byte length field).
「Cookie」拡張機能は、[TLS13]のセクション4.2.2で定義されています。最初のClientHelloを送信するとき、クライアントはまだCookieを持っていません。この場合、「Cookie」拡張機能が省略され、ClientHelloメッセージのLegacy_Cookieフィールドはゼロ長ベクトル（つまり、ゼロ値の単一バイト長フィールド）に設定する必要があります。
When responding to a HelloRetryRequest, the client MUST create a new ClientHello message following the description in Section 4.1.2 of [TLS13].
HelloretryRequestに応答する場合、クライアントは[TLS13]のセクション4.1.2の説明に従って新しいClientHelloメッセージを作成する必要があります。
If the HelloRetryRequest message is used, the initial ClientHello and the HelloRetryRequest are included in the calculation of the transcript hash. The computation of the message hash for the HelloRetryRequest is done according to the description in Section 4.4.1 of [TLS13].
HelloretryRequestメッセージを使用すると、最初のClientHelloとHelloretryRequestが転写産物ハッシュの計算に含まれています。[TLS13]のセクション4.4.1の説明に従って、HelloretryRequestのメッセージハッシュの計算は行われます。
The handshake transcript is not reset with the second ClientHello, and a stateless server-cookie implementation requires the content or hash of the initial ClientHello (and HelloRetryRequest) to be stored in the cookie. The initial ClientHello is included in the handshake transcript as a synthetic "message_hash" message, so only the hash value is needed for the handshake to complete, though the complete HelloRetryRequest contents are needed.
ハンドシェイクトランスクリプトは2番目のClientHelloでリセットされず、ステートレスサーバー-Cookie実装では、Cookieに格納される最初のClientHello（およびHelloretryRequest）のコンテンツまたはハッシュが必要です。最初のClientHelloは、ハンドシェイクトランスクリプトに合成 "Message_hash"メッセージとして含まれているので、ハンドシェイクが完了するのに必要なハッシュ値だけが必要ですが、完全なHellORetryRequestの内容が必要です。
When the second ClientHello is received, the server can verify that the cookie is valid and that the client can receive packets at the given IP address. If the client's apparent IP address is embedded in the cookie, this prevents an attacker from generating an acceptable ClientHello apparently from another user.
2番目のClientHelloを受信すると、サーバーはCookieが有効であること、およびクライアントが指定されたIPアドレスでパケットを受信できることを確認できます。クライアントの見かけのIPアドレスがCookieに埋め込まれている場合、これにより、攻撃者が明らかに他のユーザーから許容可能なclienthelloを生成することができなくなります。
One potential attack on this scheme is for the attacker to collect a number of cookies from different addresses where it controls endpoints and then reuse them to attack the server. The server can defend against this attack by changing the secret value frequently, thus invalidating those cookies. If the server wishes to allow legitimate clients to handshake through the transition (e.g., a client received a cookie with Secret 1 and then sent the second ClientHello after the server has changed to Secret 2), the server can have a limited window during which it accepts both secrets. [RFC7296] suggests adding a key identifier to cookies to detect this case. An alternative approach is simply to try verifying with both secrets. It is RECOMMENDED that servers implement a key rotation scheme that allows the server to manage keys with overlapping lifetimes.
このスキームに対する1つの潜在的な攻撃は、攻撃者がエンドポイントを制御してからそれらを再利用してサーバーを攻撃するためにそれらを再利用するための攻撃者が攻撃者にとって非常に多くのクッキーを収集することです。サーバーは秘密の価値を頻繁に変更することによってこの攻撃に対して守ることができ、したがってそれらのクッキーを無効にすることができます。サーバーが正当なクライアントが遷移を介してハンドシェイクすることを許可したい場合（たとえば、クライアントが秘密1を持つCookieを受信し、サーバーが秘密2に変更した後に2番目のClientHelloを送信しました）、サーバーはそれが限られたウィンドウを持つことができます。両方の秘密を受け入れます。[RFC7296]この場合を検出するためにCookieにキー識別子を追加することを提案します。代替的なアプローチは単に両方の秘密で検証を試みることです。サーバーは、サーバーが重複する寿命を持つキーを管理できるようにするキーローテーション方式を実装することをお勧めします。
Alternatively, the server can store timestamps in the cookie and reject cookies that were generated outside a certain interval of time.
あるいは、サーバーはクッキーにタイムスタンプを保存し、特定の時間外で生成されたCookieを拒否することができます。
DTLS servers SHOULD perform a cookie exchange whenever a new handshake is being performed. If the server is being operated in an environment where amplification is not a problem, e.g., where ICE [RFC8445] has been used to establish bidirectional connectivity, the server MAY be configured not to perform a cookie exchange. The default SHOULD be that the exchange is performed, however. In addition, the server MAY choose not to do a cookie exchange when a session is resumed or, more generically, when the DTLS handshake uses a PSK-based key exchange and the IP address matches one associated with the PSK. Servers which process 0-RTT requests and send 0.5-RTT responses without a cookie exchange risk being used in an amplification attack if the size of outgoing messages greatly exceeds the size of those that are received. A server SHOULD limit the amount of data it sends toward a client address to three times the amount of data sent by the client before it verifies that the client is able to receive data at that address. A client address is valid after a cookie exchange or handshake completion. Clients MUST be prepared to do a cookie exchange with every handshake. Note that cookies are only valid for the existing handshake and cannot be stored for future handshakes.
DTLSサーバーは、新しいハンドシェイクが実行されているときはいつでもCookie Exchangeを実行する必要があります。サーバが増幅が問題ではない環境で動作している場合、例えばICE [RFC8445]が双方向接続性を確立するために使用されてきた場合、サーバはクッキー交換を実行しないように構成されてもよい。ただし、デフォルトは交換が実行されることです。さらに、サーバーは、セッションが再開されたときに、またはより一般的に、より一般的に、PSKベースの鍵交換を使用し、IPアドレスがPSKに関連付けられている場合には、Cookie Exchangeを実行しないことを選択できます。発信メッセージのサイズが受信されたもののサイズを大きく超えると、Cookie Exchange Responseが0-RTTの要求を処理し、0.5-RTTの応答を送信するサーバー。サーバーは、クライアントがそのアドレスでデータを受信できることを確認する前に、クライアントアドレスに向かって送信するデータの量をクライアントから送信されたデータの数量に制限する必要があります。クライアントアドレスは、クッキー交換またはハンドシェイクの完了後に有効です。顧客はすべてのハンドシェイクとクッキー交換を行う準備をしなければなりません。クッキーは既存のハンドシェイクに対してのみ有効であり、将来のハンドシェイクのために保存することはできません。
If a server receives a ClientHello with an invalid cookie, it MUST terminate the handshake with an "illegal_parameter" alert. This allows the client to restart the connection from scratch without a cookie.
サーバーが無効なCookieを使用してClientHelloを受信した場合、「Illegal_Parameter」アラートで握手を終了する必要があります。これにより、クライアントはクッキーなしで接続をゼロから再起動できます。
As described in Section 4.1.4 of [TLS13], clients MUST abort the handshake with an "unexpected_message" alert in response to any second HelloRetryRequest which was sent in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest).
[TLS13]のセクション4.1.4で説明されているように、クライアントは、同じ接続で送信された（すなわち、ClientHelloがHellOretryRequestに対応してそれ自体がそれ自体）任意の2番目のHelloretryRequestに応答してハンドシェイクを中止する必要があります。。
DTLS clients which do not want to receive a Connection ID SHOULD still offer the "connection_id" extension [RFC9146] unless there is an application profile to the contrary. This permits a server which wants to receive a CID to negotiate one.
接続IDを受信したくないDTLSクライアントは、逆にアプリケーションプロファイルがない限り、「connection_id」拡張子[RFC9146]を提供する必要があります。これにより、CIDを受信したいサーバーが交渉するサーバーが許可されます。
DTLS uses the same Handshake messages as TLS 1.3. However, prior to transmission they are converted to DTLSHandshake messages, which contain extra data needed to support message loss, reordering, and message fragmentation.
DTLSはTLS 1.3と同じハンドシェイクメッセージを使用します。ただし、送信前に、メッセージの損失、並べ替え、およびメッセージの断片化をサポートするために必要な追加データを含むDTLShandShakeメッセージに変換されます。
enum {
client_hello(1),
server_hello(2),
new_session_ticket(4),
end_of_early_data(5),
encrypted_extensions(8),
request_connection_id(9), /* New */
new_connection_id(10), /* New */
certificate(11),
certificate_request(13),
certificate_verify(15),
finished(20),
key_update(24),
message_hash(254),
(255)
} HandshakeType;
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */
uint16 message_seq; /* DTLS-required field */
uint24 fragment_offset; /* DTLS-required field */
uint24 fragment_length; /* DTLS-required field */
select (msg_type) {
case client_hello: ClientHello;
case server_hello: ServerHello;
case end_of_early_data: EndOfEarlyData;
case encrypted_extensions: EncryptedExtensions;
case certificate_request: CertificateRequest;
case certificate: Certificate;
case certificate_verify: CertificateVerify;
case finished: Finished;
case new_session_ticket: NewSessionTicket;
case key_update: KeyUpdate;
case request_connection_id: RequestConnectionId;
case new_connection_id: NewConnectionId;
} body;
} DTLSHandshake;
In DTLS 1.3, the message transcript is computed over the original TLS 1.3-style Handshake messages without the message_seq, fragment_offset, and fragment_length values. Note that this is a change from DTLS 1.2 where those values were included in the transcript.
DTLS 1.3では、メッセージトランスクリプトは、message_seq、fragment_offset、およびfragment_length値なしで、元のTLS 1.3スタイルのハンドシェイクメッセージを介して計算されます。これはDTLS 1.2からの変化であり、ここでそれらの値がトランスクリプトに含まれていました。
The first message each side transmits in each association always has message_seq = 0. Whenever a new message is generated, the message_seq value is incremented by one. When a message is retransmitted, the old message_seq value is reused, i.e., not incremented. From the perspective of the DTLS record layer, the retransmission is a new record. This record will have a new DTLSPlaintext.sequence_number value.
各アソシエーションで各側面が送信される最初のメッセージには、常にメッセージ_Seq = 0があります。新しいメッセージが生成されるたびに、Message_Seq値は1つずつ増加します。メッセージが再送信されると、古いmessage_seq値が再利用されます。つまり、増加しません。DTLSレコードレイヤーの観点から見ると、再送信は新しいレコードです。このレコードには、新しいdtlsplaintext.sequence_number値があります。
Note: In DTLS 1.2, the message_seq was reset to zero in case of a rehandshake (i.e., renegotiation). On the surface, a rehandshake in DTLS 1.2 shares similarities with a post-handshake message exchange in DTLS 1.3. However, in DTLS 1.3 the message_seq is not reset, to allow distinguishing a retransmission from a previously sent post-handshake message from a newly sent post-handshake message.
注：DTLS 1.2では、再ハンドシェイク（つまり、再交渉）の場合、Message_Seqはゼロにリセットされました。表面的には、DTLS 1.2の再ハンドシェイクは、DTLS 1.3のポストハンドシェイクメッセージ交換と類似点を共有しています。ただし、DTLS 1.3では、Message_Seqはリセットされていません。これは、新しく送信されたポストハンドシェークメッセージから以前に送信されたポストハンドシェークメッセージからの再送信を区別できるようにします。
DTLS implementations maintain (at least notionally) a next_receive_seq counter. This counter is initially set to zero. When a handshake message is received, if its message_seq value matches next_receive_seq, next_receive_seq is incremented and the message is processed. If the sequence number is less than next_receive_seq, the message MUST be discarded. If the sequence number is greater than next_receive_seq, the implementation SHOULD queue the message but MAY discard it. (This is a simple space/ bandwidth trade-off).
DTLS実装は、（少なくとも概念的に）Next_receive_Seqカウンターを維持します。このカウンターは最初はゼロに設定されています。ハンドシェイクメッセージが受信されると、message_seq値がnext_receive_seqと一致する場合、next_receive_seqがインクリメントされ、メッセージが処理されます。シーケンス番号がnext_receive_seqよりも少ない場合、メッセージを破棄する必要があります。シーケンス番号がnext_receive_seqよりも大きい場合、実装はメッセージをキューする必要がありますが、破棄する場合があります。（これは単純なスペース/帯域幅のトレードオフです）。
In addition to the handshake messages that are deprecated by the TLS 1.3 specification, DTLS 1.3 furthermore deprecates the HelloVerifyRequest message originally defined in DTLS 1.0. DTLS 1.3-compliant implementations MUST NOT use the HelloVerifyRequest to execute a return-routability check. A dual-stack DTLS 1.2 / DTLS 1.3 client MUST, however, be prepared to interact with a DTLS 1.2 server.
TLS 1.3仕様によって廃止予定されているハンドシェイクメッセージに加えて、DTLS 1.3は、DTLS 1.0で最初に定義されているHelloVelifyRequestメッセージをさらに推奨します。DTLS 1.3準拠の実装は、Return-romailifyRequestを使用して返信ルーティング性チェックを実行しないでください。ただし、デュアルスタックDTLS 1.2 / DTLS 1.3クライアントは、DTLS 1.2サーバと対話する準備をしなければなりません。
The format of the ClientHello used by a DTLS 1.3 client differs from the TLS 1.3 ClientHello format, as shown below.
以下に示すように、DTLS 1.3クライアントが使用するClientHelloの形式は、TLS 1.3 ClientHello形式とは異なります。
uint16 ProtocolVersion;
opaque Random[32];
uint8 CipherSuite[2]; /* Cryptographic suite selector */
struct {
ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2
Random random;
opaque legacy_session_id<0..32>;
opaque legacy_cookie<0..2^8-1>; // DTLS
CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>;
} ClientHello;
legacy_version: In previous versions of DTLS, this field was used for version negotiation and represented the highest version number supported by the client. Experience has shown that many servers do not properly implement version negotiation, leading to "version intolerance" in which the server rejects an otherwise acceptable ClientHello with a version number higher than it supports. In DTLS 1.3, the client indicates its version preferences in the "supported_versions" extension (see Section 4.2.1 of [TLS13]) and the legacy_version field MUST be set to {254, 253}, which was the version number for DTLS 1.2. The supported_versions entries for DTLS 1.0 and DTLS 1.2 are 0xfeff and 0xfefd (to match the wire versions). The value 0xfefc is used to indicate DTLS 1.3.
Legacy_version：以前のバージョンのDTLSでは、このフィールドはバージョンのネゴシエーションに使用され、クライアントがサポートする最高のバージョン番号を表しています。経験によると、多くのサーバーがバージョンのネゴシエーションを適切に実装しておらず、「バージョンの不寛容」につながり、サーバーはサポートよりも高いバージョン番号を持つ許容可能なクライアントヘロを拒否します。DTLS 1.3では、クライアントは「supported_versions」拡張子（[TLS13]のセクション4.2.1を参照）のバージョンの設定を示し、Legacy_versionフィールドは{254、253}に設定する必要があります。これはDTLS 1.2のバージョン番号でした。DTLS 1.0およびDTLS 1.2のsupported_versionsエントリは、0xfeffと0xfefdです（ワイヤーバージョンと一致するため）。値0xFEFCは、DTLS 1.3を示すために使用されます。
random: Same as for TLS 1.3, except that the downgrade sentinels described in Section 4.1.3 of [TLS13] when TLS 1.2 and TLS 1.1 and below are negotiated apply to DTLS 1.2 and DTLS 1.0, respectively.
ランダム：TLS 1.3と同じですが、TLS 1.2およびTLS 1.1以下がそれぞれDTLS 1.2およびDTLS 1.0に適用される場合、[TLS13]のセクション4.1.3で説明されているダウングレードセンチネルがそれぞれ説明します。
legacy_session_id: Versions of TLS and DTLS before version 1.3 supported a "session resumption" feature, which has been merged with pre-shared keys (PSK) in version 1.3. A client which has a cached session ID set by a pre-DTLS 1.3 server SHOULD set this field to that value. Otherwise, it MUST be set as a zero-length vector (i.e., a zero-valued single byte length field).
LEGACY_SESSION_ID：バージョン1.3の前のTLSおよびDTLSのバージョンは、バージョン1.3の事前共有キー（PSK）と統合された「セッション再開」機能をサポートしています。Pre-DTLS 1.3サーバーによって設定されたキャッシュセッションIDを持つクライアントは、このフィールドをその値に設定する必要があります。それ以外の場合は、ゼロ長ベクトル（つまり、ゼロ値の単一バイトの長さフィールド）として設定する必要があります。
legacy_cookie: A DTLS 1.3-only client MUST set the legacy_cookie field to zero length. If a DTLS 1.3 ClientHello is received with any other value in this field, the server MUST abort the handshake with an "illegal_parameter" alert.
LEGACY_COOKIE：DTLS 1.3のみのクライアントは、LEGACY_COOKIEフィールドをゼロの長さに設定する必要があります。DTLS 1.3 ClientHelloがこのフィールドの他の値で受信された場合、サーバーは「Illegal_Parameter」アラートでハンドシェイクを中止する必要があります。
cipher_suites: Same as for TLS 1.3; only suites with DTLS-OK=Y may be used.
cipher_suites：TLS 1.3と同じ;DTLS-OK = Yのスイートのみを使用できます。
legacy_compression_methods: Same as for TLS 1.3.
legacy_compression_methods：TLS 1.3と同じ。
extensions: Same as for TLS 1.3.
拡張機能：TLS 1.3と同じ。
The DTLS 1.3 ServerHello message is the same as the TLS 1.3 ServerHello message, except that the legacy_version field is set to 0xfefd, indicating DTLS 1.2.
DTLS 1.3 ServerHelloメッセージは、LEGACY_VERSIONフィールドが0xFEFDに設定されていることを除いて、TLS 1.3 ServerHelloメッセージと同じです。これはDTLS 1.2を示します。
As described in Section 4.3, one or more handshake messages may be carried in a single datagram. However, handshake messages are potentially bigger than the size allowed by the underlying datagram transport. DTLS provides a mechanism for fragmenting a handshake message over a number of records, each of which can be transmitted in separate datagrams, thus avoiding IP fragmentation.
セクション4.3で説明されているように、1つの握手メッセージを単一のデータグラムで伝えることができます。ただし、握手メッセージは、基礎となるデータグラムトランスポートで許可されているサイズよりも潜在的に大きくなります。DTLSは、多数のレコードにわたって握手メッセージを断片化するメカニズムを提供します。それぞれが別々のデータグラムで送信されるため、IPの断片化を回避できます。
When transmitting the handshake message, the sender divides the message into a series of N contiguous data ranges. The ranges MUST NOT overlap. The sender then creates N DTLSHandshake messages, all with the same message_seq value as the original DTLSHandshake message. Each new message is labeled with the fragment_offset (the number of bytes contained in previous fragments) and the fragment_length (the length of this fragment). The length field in all messages is the same as the length field of the original message. An unfragmented message is a degenerate case with fragment_offset=0 and fragment_length=length. Each handshake message fragment that is placed into a record MUST be delivered in a single UDP datagram.
握手メッセージを送信するとき、送信者はメッセージを一連のN連続データ範囲に分割します。範囲は重複してはなりません。その後、送信者はn dtlshandshakeメッセージを作成します。すべてが元のdtlshandshakeメッセージと同じmessage_seq値を持っています。各新しいメッセージには、fragment_offset（以前のフラグメントに含まれるバイト数）とfragment_length（このフラグメントの長さ）でラベル付けされます。すべてのメッセージの長さフィールドは、元のメッセージの長さフィールドと同じです。fragmented fragmentedメッセージは、fragment_offset = 0およびfragment_length = lengthの縮退したケースです。レコードに配置された各ハンドシェイクメッセージフラグメントは、単一のUDPデータグラムで配信する必要があります。
When a DTLS implementation receives a handshake message fragment corresponding to the next expected handshake message sequence number, it MUST process it, either by buffering it until it has the entire handshake message or by processing any in-order portions of the message. The transcript consists of complete TLS Handshake messages (reassembled as necessary). Note that this requires removing the message_seq, fragment_offset, and fragment_length fields to create the Handshake structure.
DTLSの実装が、次の予想されるハンドシェイクメッセージシーケンス番号に対応するハンドシェイクメッセージフラグメントを受信した場合、ハンドシェイクメッセージ全体があるまでバッファリングするか、メッセージの順序を処理することにより、処理する必要があります。トランスクリプトは、完全なTLSハンドシェイクメッセージで構成されています（必要に応じて再組み立てされています）。これには、メッセージ_Seq、fragment_offset、およびfragment_lengthフィールドを削除して、ハンドシェイク構造を作成する必要があることに注意してください。
DTLS implementations MUST be able to handle overlapping fragment ranges. This allows senders to retransmit handshake messages with smaller fragment sizes if the PMTU estimate changes. Senders MUST NOT change handshake message bytes upon retransmission. Receivers MAY check that retransmitted bytes are identical and SHOULD abort the handshake with an "illegal_parameter" alert if the value of a byte changes.
DTLSの実装は、重複するフラグメント範囲を処理できる必要があります。これにより、送信者は、PMTUが変化した場合、フラグメントサイズが小さい握手メッセージを再送信できます。送信者は、再送信時に握手メッセージバイトを変更してはなりません。受信者は、再送信されたバイトが同一であることを確認する場合があり、バイトの値が変更された場合、「Illegal_Parameter」アラートで握手を中止する必要があります。
Note that as with TLS, multiple handshake messages may be placed in the same DTLS record, provided that there is room and that they are part of the same flight. Thus, there are two acceptable ways to pack two DTLS handshake messages into the same datagram: in the same record or in separate records.
TLSと同様に、複数のハンドシェイクメッセージを同じDTLSレコードに配置することができ、ルームがあると同じ飛行の一部であることが提供されます。したがって、2つのDTLSハンドシェイクメッセージを同じデータグラムにパックするには、同じレコードまたは別々のレコードに2つのDTLSハンドシェイクメッセージをパックする方法があります。
The DTLS 1.3 handshake has one important difference from the TLS 1.3 handshake: the EndOfEarlyData message is omitted both from the wire and the handshake transcript. Because DTLS records have epochs, EndOfEarlyData is not necessary to determine when the early data is complete, and because DTLS is lossy, attackers can trivially mount the deletion attacks that EndOfEarlyData prevents in TLS. Servers SHOULD NOT accept records from epoch 1 indefinitely once they are able to process records from epoch 3. Though reordering of IP packets can result in records from epoch 1 arriving after records from epoch 3, this is not likely to persist for very long relative to the round trip time. Servers could discard epoch 1 keys after the first epoch 3 data arrives, or retain keys for processing epoch 1 data for a short period. (See Section 6.1 for the definitions of each epoch.)
DTLS 1.3ハンドシェイクには、TLS 1.3ハンドシェイクと1つの重要な違いがあります。EndoFearlyDataメッセージは、ワイヤとハンドシェイクトランスクリプトの両方で省略されます。DTLSレコードにエポックがあるため、EndoFearlyDataは早期データが完了した日がいつ完了しているかを判断する必要はありません.DTLSが損失しているため、攻撃者は、ENDoFeArlyDataがTLSで防止する削除攻撃を簡単にマウントできます。EPOCH 1からのレコードを無期限に受け入れないでください。往復時間。サーバーは、最初のEPOCH 3データが到着した後、EPOCH 1キーを破棄したり、EPOCH 1データを短時間で処理するためのキーを保持することができます。（各エポックの定義については6.1項を参照してください。）
DTLS handshake messages are grouped into a series of message flights. A flight starts with the handshake message transmission of one peer and ends with the expected response from the other peer. Table 1 contains a complete list of message combinations that constitute flights.
DTLSハンドシェイクメッセージは、一連のメッセージフライトにグループ化されます。フライトは、1つのピアの握手メッセージの伝達から始まり、他のピアからの予想される応答で終わります。表1には、フライトを構成するメッセージの組み合わせの完全なリストが含まれています。
+======+========+========+===================================+
| Note | Client | Server | Handshake Messages |
+======+========+========+===================================+
| | x | | ClientHello |
+------+--------+--------+-----------------------------------+
| | | x | HelloRetryRequest |
+------+--------+--------+-----------------------------------+
| | | x | ServerHello, EncryptedExtensions, |
| | | | CertificateRequest, Certificate, |
| | | | CertificateVerify, Finished |
+------+--------+--------+-----------------------------------+
| 1 | x | | Certificate, CertificateVerify, |
| | | | Finished |
+------+--------+--------+-----------------------------------+
| 1 | | x | NewSessionTicket |
+------+--------+--------+-----------------------------------+
Table 1: Flight Handshake Message Combinations
表1：フライトハンドシェイクメッセージの組み合わせ
Remarks:
備考：
* Table 1 does not highlight any of the optional messages.
* 表1は、オプションのメッセージのいずれも強調表示されません。
* Regarding note (1): When a handshake flight is sent without any expected response, as is the case with the client's final flight or with the NewSessionTicket message, the flight must be acknowledged with an ACK message.
* 注記（1）：クライアントの最終フライトまたはNewSessionTicketメッセージを使用している場合と同様に、予想される応答なしにハンドシェイクのフライトが送信されると、ACKメッセージで承認されなければなりません。
Below are several example message exchanges illustrating the flight concept. The notational conventions from [TLS13] are used.
以下は、飛行の概念を示すいくつかのメッセージ交換です。[TLS13]からの表記規則が使用されます。
Client Server
クライアントサーバー
+--------+
ClientHello | Flight |
--------> +--------+
+--------+
<-------- HelloRetryRequest | Flight |
+ cookie +--------+
+--------+
ClientHello | Flight |
+ cookie --------> +--------+
ServerHello
{EncryptedExtensions} +--------+
{CertificateRequest*} | Flight |
{Certificate*} +--------+
{CertificateVerify*}
{Finished}
<-------- [Application Data*]
{Certificate*} +--------+
{CertificateVerify*} | Flight |
{Finished} --------> +--------+
[Application Data]
+--------+
<-------- [ACK] | Flight |
[Application Data*] +--------+
[Application Data] <-------> [Application Data]
Figure 7: Message Flights for a Full DTLS Handshake (with Cookie Exchange)
図7：完全なDTLSハンドシェイクのメッセージフライト（Cookie Exchange付）
ClientHello +--------+
+ pre_shared_key | Flight |
+ psk_key_exchange_modes +--------+
+ key_share* -------->
ServerHello
+ pre_shared_key +--------+
+ key_share* | Flight |
{EncryptedExtensions} +--------+
<-------- {Finished}
[Application Data*]
+--------+
{Finished} --------> | Flight |
[Application Data*] +--------+
+--------+
<-------- [ACK] | Flight |
[Application Data*] +--------+
[Application Data] <-------> [Application Data]
Figure 8: Message Flights for Resumption and PSK Handshake (without Cookie Exchange)
図8：再開およびPSKハンドシェイクのメッセージフライト（クッキー交換なし）
Client Server
クライアントサーバー
ClientHello
+ early_data
+ psk_key_exchange_modes +--------+
+ key_share* | Flight |
+ pre_shared_key +--------+
(Application Data*) -------->
ServerHello
+ pre_shared_key
+ key_share* +--------+
{EncryptedExtensions} | Flight |
{Finished} +--------+
<-------- [Application Data*]
+--------+
{Finished} --------> | Flight |
[Application Data*] +--------+
+--------+
<-------- [ACK] | Flight |
[Application Data*] +--------+
[Application Data] <-------> [Application Data]
Figure 9: Message Flights for the Zero-RTT Handshake
図9：ゼロRTTハンドシェイクのメッセージフライト
Client Server
クライアントサーバー
+--------+
<-------- [NewSessionTicket] | Flight |
+--------+
+--------+
[ACK] --------> | Flight |
+--------+
Figure 10: Message Flights for the NewSessionTicket Message
図10：NewsessionTicketメッセージのメッセージフライト
KeyUpdate, NewConnectionId, and RequestConnectionId follow a similar pattern to NewSessionTicket: a single message sent by one side followed by an ACK by the other.
KeyUpDate、NewConnectionID、およびRequestConnectionIDは、NewsessionTicketと同様のパターンに従います。一方の側で送信された単一のメッセージに続いて、もう一方の側がACKが続きます。
DTLS uses a simple timeout and retransmission scheme with the state machine shown in Figure 11.
DTLSは、図11に示す状態機械で簡単なタイムアウトおよび再送信方式を使用します。
+-----------+
| PREPARING |
+----------> | |
| | |
| +-----------+
| |
| | Buffer next flight
| |
| \|/
| +-----------+
| | |
| | SENDING |<------------------+
| | | |
| +-----------+ |
Receive | | |
next | | Send flight or partial |
flight | | flight |
| | |
| | Set retransmit timer |
| \|/ |
| +-----------+ |
| | | |
+------------| WAITING |-------------------+
| +----->| | Timer expires |
| | +-----------+ |
| | | | | |
| | | | | |
| +----------+ | +--------------------+
| Receive record | Read retransmit or ACK
Receive | (Maybe Send ACK) |
last | |
flight | | Receive ACK
| | for last flight
\|/ |
|
+-----------+ |
| | <---------+
| FINISHED |
| |
+-----------+
| /|\
| |
| |
+---+
Server read retransmit Retransmit ACK
サーバーRead Retransmit retransmit ack.
Figure 11: DTLS Timeout and Retransmission State Machine
図11：DTLSタイムアウトおよび再送信状態マシン
The state machine has four basic states: PREPARING, SENDING, WAITING, and FINISHED.
州のマシンには、準備、送信、待機、および終了の4つの基本的な状態があります。
In the PREPARING state, the implementation does whatever computations are necessary to prepare the next flight of messages. It then buffers them up for transmission (emptying the transmission buffer first) and enters the SENDING state.
準備状態では、次のメッセージのフライトを準備するために必要な計算が必要です。それはそれからそれらを送信するためにそれらをバッファアップする（最初に送信バッファを空にして）送信状態に入る。
In the SENDING state, the implementation transmits the buffered flight of messages. If the implementation has received one or more ACKs (see Section 7) from the peer, then it SHOULD omit any messages or message fragments which have already been acknowledged. Once the messages have been sent, the implementation then sets a retransmit timer and enters the WAITING state.
送信状態では、実装はメッセージのバッファフライトフライトを送信します。実装がピアから1つ以上のACK（セクション7を参照）を受信した場合は、すでに確認されているメッセージまたはメッセージフラグメントを省略してください。メッセージが送信されると、実装は再送信タイマを設定し、待機状態に入ります。
There are four ways to exit the WAITING state:
待機状態を終了するには4つの方法があります。
1. The retransmit timer expires: the implementation transitions to the SENDING state, where it retransmits the flight, adjusts and re-arms the retransmit timer (see Section 5.8.2), and returns to the WAITING state.
1. 再送タイマーは期限切れになります。実装は送信状態に移行します。ここで、フライトを再送信し、再送信タイマを調整し、統合します（セクション5.8.2を参照）、待機状態に戻ります。
2. The implementation reads an ACK from the peer: upon receiving an ACK for a partial flight (as mentioned in Section 7.1), the implementation transitions to the SENDING state, where it retransmits the unacknowledged portion of the flight, adjusts and re-arms the retransmit timer, and returns to the WAITING state. Upon receiving an ACK for a complete flight, the implementation cancels all retransmissions and either remains in WAITING, or, if the ACK was for the final flight, transitions to FINISHED.
2. 実装はピアからACKを読み取ります：部分飛行のACKを受信すると（セクション7.1で言及されている）、実装は送信状態に移行し、そこでフライトの未充填部分を再送信し、再送信を調整して再装填しますタイマー、そして待機状態に戻ります。完全なフライトのためにACKを受け取ると、実装はすべての再送信をキャンセルし、待機中のまま、またはACKが最終フライトの場合、完了まで移行します。
3. The implementation reads a retransmitted flight from the peer when none of the messages that it sent in response to that flight have been acknowledged: the implementation transitions to the SENDING state, where it retransmits the flight, adjusts and re-arms the retransmit timer, and returns to the WAITING state. The rationale here is that the receipt of a duplicate message is the likely result of timer expiry on the peer and therefore suggests that part of one's previous flight was lost.
3. 実装は、そのフライトに応じて送信したメッセージが認められていない場合、ピアからの再送信フライトを読み取ります。実装は送信状態に移行し、そこでフライトを再送信し、再送信タイマーを調整して再装着し、再装填します。待機状態に戻ります。ここでの理論的根拠は、重複したメッセージの受領がピアのタイマーの有効期限の結果である可能性が高いため、以前のフライトの一部が失われたことを示唆していることです。
4. The implementation receives some or all of the next flight of messages: if this is the final flight of messages, the implementation transitions to FINISHED. If the implementation needs to send a new flight, it transitions to the PREPARING state. Partial reads (whether partial messages or only some of the messages in the flight) may also trigger the implementation to send an ACK, as described in Section 7.1.
4. 実装では、次のメッセージの一部またはすべてが受信されます。これがメッセージの最終飛行である場合、実装は終了します。実装が新しいフライトを送信する必要がある場合、準備状態に移行します。セクション7.1で説明されているように、部分的な読み取り（部分的なメッセージまたはフライト内のメッセージの一部のみ）も、ACKを送信するために実装をトリガーする場合があります。
Because DTLS clients send the first message (ClientHello), they start in the PREPARING state. DTLS servers start in the WAITING state, but with empty buffers and no retransmit timer.
DTLSクライアントは最初のメッセージ（ClientHello）を送信し、準備状態で起動します。DTLSサーバーは待機状態で始まりますが、空のバッファーと再送信タイマーがありません。
In addition, for at least twice the default MSL defined for [RFC0793], when in the FINISHED state, the server MUST respond to retransmission of the client's final flight with a retransmit of its ACK.
さらに、[RFC0793]に対して定義されたデフォルトのMSLの少なくとも2倍の場合、完成した状態では、サーバーがACKの再送信でクライアントの最終フライトの再送信に応答する必要があります。
Note that because of packet loss, it is possible for one side to be sending application data even though the other side has not received the first side's Finished message. Implementations MUST either discard or buffer all application data records for epoch 3 and above until they have received the Finished message from the peer. Implementations MAY treat receipt of application data with a new epoch prior to receipt of the corresponding Finished message as evidence of reordering or packet loss and retransmit their final flight immediately, shortcutting the retransmission timer.
パケットの損失のため、反対側が最初の側の完成したメッセージを受信していない場合でも、一方の側がアプリケーションデータを送信することが可能であることに注意してください。実装は、ピアから完成したメッセージを受信するまで、エポック3以上のすべてのアプリケーションデータレコードを破棄またはバッファリングする必要があります。実装は、対応する完成したメッセージを受信する前にアプリケーションデータの受信を、並べ替えまたはパケット損失の証拠として扱い、すぐに最終フライトを再送信し、再送信タイマーをショートカットする場合があります。
The configuration of timer settings varies with implementations, and certain deployment environments require timer value adjustments. Mishandling of the timer can lead to serious congestion problems -- for example, if many instances of a DTLS time out early and retransmit too quickly on a congested link.
タイマー設定の設定は実装によって異なり、特定の展開環境ではタイマー値の調整が必要です。タイマーの誤操作は重大な渋滞の問題につながる可能性があります - たとえば、DTLSの多くのインスタンスが早期にタイムアウトし、混雑したリンクで早く再送信されます。
Unless implementations have deployment-specific and/or external information about the round trip time, implementations SHOULD use an initial timer value of 1000 ms and double the value at each retransmission, up to no less than 60 seconds (the maximum as specified in RFC 6298 [RFC6298]). Application-specific profiles MAY recommend shorter or longer timer values. For instance:
実装が展開固有および/または往復時間に関する外部情報がない限り、実装は初期タイマー値1000ミリ秒を使用し、各再送信で60秒以上の値を2倍にする必要があります（RFC 6298で指定されている最大値[RFC6298]）。アプリケーション固有のプロファイルは、より短いまたは長いタイマー値を推奨する場合があります。例えば：
* Profiles for specific deployment environments, such as in low-power, multi-hop mesh scenarios as used in some Internet of Things (IoT) networks, MAY specify longer timeouts. See [IOT-PROFILE] for more information about one such DTLS 1.3 IoT profile.
* 一部のインターネット（IoT）ネットワークで使用される低電力、マルチホップメッシュシナリオなど、特定の展開環境のプロファイルは、より長いタイムアウトを指定する場合があります。そのようなDTL 1.3 IoTプロファイルの1つの詳細については、[IoT-Profile]を参照してください。
* Real-time protocols MAY specify shorter timeouts. It is RECOMMENDED that for DTLS-SRTP [RFC5764], a default timeout of 400 ms be used; because customer experience degrades with one-way latencies of greater than 200 ms, real-time deployments are less likely to have long latencies.
* リアルタイムプロトコルは、より短いタイムアウトを指定することができます。DTLS-SRTP [RFC5764]の場合、400ミリ秒のデフォルトタイムアウトを使用することをお勧めします。顧客の経験は200ミリ秒以上の一方向の待ち時間で劣化しているため、リアルタイムの展開は長い待ち時間を持つ可能性が低くなります。
In settings where there is external information (for instance, from an ICE [RFC8445] handshake, or from previous connections to the same server) about the RTT, implementations SHOULD use 1.5 times that RTT estimate as the retransmit timer.
外部情報がある設定（たとえば、氷[RFC8445]の握手から、またはRTTについての以前の接続から）では、実装はRTTが再送信タイマーとして推定される1.5倍を使用する必要があります。
Implementations SHOULD retain the current timer value until a message is transmitted and acknowledged without having to be retransmitted, at which time the value SHOULD be adjusted to 1.5 times the measured round trip time for that message. After a long period of idleness, no less than 10 times the current timer value, implementations MAY reset the timer to the initial value.
実装は、メッセージが再送信されずに送信され、確認されるまで現在のタイマ値を保持する必要があります。その場合、そのメッセージの測定された往復時間の1.5倍になる必要があります。長時間のアイドル性が、現在のタイマ値の10倍以上、実装はタイマーを初期値にリセットすることができます。
Note that because retransmission is for the handshake and not dataflow, the effect on congestion of shorter timeouts is smaller than in generic protocols such as TCP or QUIC. Experience with DTLS 1.2, which uses a simpler "retransmit everything on timeout" approach, has not shown serious congestion problems in practice.
再送信はデータフローではなく握手のためのものであるため、短いタイムアウトの混雑への影響は、TCPやQUICなどの汎用プロトコルよりも小さいことに注意してください。よりシンプルな「タイムアウトですべてを再送信する」アプローチを使用するDTLS 1.2の経験は、実際に深刻な混雑の問題を示していません。
DTLS does not have any built-in congestion control or rate control; in general, this is not an issue because messages tend to be small. However, in principle, some messages -- especially Certificate -- can be quite large. If all the messages in a large flight are sent at once, this can result in network congestion. A better strategy is to send out only part of the flight, sending more when messages are acknowledged. Several extensions have been standardized to reduce the size of the Certificate message -- for example, the "cached_info" extension [RFC7924]; certificate compression [RFC8879]; and [RFC6066], which defines the "client_certificate_url" extension allowing DTLS clients to send a sequence of Uniform Resource Locators (URLs) instead of the client certificate.
DTLSには、混雑制御またはレート制御が組み込まれていません。一般に、メッセージは小さい傾向があるため、これは問題ではありません。ただし、原則として、一部のメッセージ（特に証明書）は非常に大きい場合があります。大規模なフライト内のすべてのメッセージが一度に送信された場合、これによりネットワークの輻輳が発生する可能性があります。より良い戦略は、フライトの一部のみを送信し、メッセージが認められたときにさらに多くを送信することです。証明書メッセージのサイズを削減するためにいくつかの拡張機能が標準化されています - たとえば、「cached_info」拡張[RFC7924]。証明書圧縮[RFC8879];[RFC6066]は、「client_certificate_url」拡張機能を定義し、DTLSクライアントがクライアント証明書の代わりに一連のユニフォームリソースロケーター（URL）を送信できるようにします。
DTLS stacks SHOULD NOT send more than 10 records in a single transmission.
DTLSスタックは、単一の送信で10以上のレコードを送信しないでください。
DTLS 1.3 makes use of the following categories of post-handshake messages:
DTLS 1.3は、ポストハンドシェイクメッセージの次のカテゴリを使用しています。
1. NewSessionTicket
1. Newsessionticket
2. KeyUpdate
2. keyupdate
3. NewConnectionId
3. NewConnectionID
4. RequestConnectionId
4. RequestConnectionID
5. Post-handshake client authentication
5. ハンドシェイク後のクライアント認証
Messages of each category can be sent independently, and reliability is established via independent state machines, each of which behaves as described in Section 5.8.1. For example, if a server sends a NewSessionTicket and a CertificateRequest message, two independent state machines will be created.
各カテゴリのメッセージは独立して送信でき、信頼性は独立した状態マシンを介して確立され、それぞれがセクション5.8.1で説明されているように動作します。たとえば、サーバーがNewsessionTicketとCertificateRequestメッセージを送信する場合、2つの独立した状態マシンが作成されます。
Sending multiple instances of messages of a given category without having completed earlier transmissions is allowed for some categories, but not for others. Specifically, a server MAY send multiple NewSessionTicket messages at once without awaiting ACKs for earlier NewSessionTicket messages first. Likewise, a server MAY send multiple CertificateRequest messages at once without having completed earlier client authentication requests before. In contrast, implementations MUST NOT send KeyUpdate, NewConnectionId, or RequestConnectionId messages if an earlier message of the same type has not yet been acknowledged.
以前の送信を完了せずに特定のカテゴリのメッセージの複数のインスタンスを送信することは、いくつかのカテゴリに対して許可されていますが、他のカテゴリでは許可されていません。具体的には、以前のNewsessionTicketメッセージが最初にACKを待っていなくても、サーバーは一度に複数のNewSessionTicketメッセージを送信することがあります。同様に、サーバーは、以前に以前のクライアント認証要求を完了せずに、複数のCertificateQuestメッセージを一度に送信することができます。対照的に、同じタイプの以前のメッセージがまだ認識されていない場合、実装はKeyUpdate、NewConnectionID、またはRequestConnectionIDメッセージを送信してはいけません。
Note: Except for post-handshake client authentication, which involves handshake messages in both directions, post-handshake messages are single-flight, and their respective state machines on the sender side reduce to waiting for an ACK and retransmitting the original message. In particular, note that a RequestConnectionId message does not force the receiver to send a NewConnectionId message in reply, and both messages are therefore treated independently.
注：ポストハンドシェイククライアント認証を除き、両方向のハンドシェイクメッセージ、ポストハンドシェイクメッセージは単一飛行であり、送信者側のそれぞれの状態マシンがACKを待って元のメッセージを再送信します。特に、RequestConnectionIDメッセージは、受信者にNewConnectionIDメッセージを返信するように強制しないため、両方のメッセージが独立して扱われることに注意してください。
Creating and correctly updating multiple state machines requires feedback from the handshake logic to the state machine layer, indicating which message belongs to which state machine. For example, if a server sends multiple CertificateRequest messages and receives a Certificate message in response, the corresponding state machine can only be determined after inspecting the certificate_request_context field. Similarly, a server sending a single CertificateRequest and receiving a NewConnectionId message in response can only decide that the NewConnectionId message should be treated through an independent state machine after inspecting the handshake message type.
複数の状態マシンを作成して正しく更新するには、ハンドシェイクロジックから状態マシン層へのフィードバックが必要であり、どのメッセージがどのようなメッセージに属しているかを示します。たとえば、サーバーが複数のCertificateRequestメッセージを送信し、応答して証明書メッセージを受信した場合、対応する状態マシンは、certificate_request_contextフィールドを検査した後にのみ決定できます。同様に、単一のCertificateRequestを送信し、それに応じてNewConnectionIDメッセージを受信するサーバーは、握手メッセージの種類を検査した後、NewConnectionIDメッセージを独立した状態マシンで扱う必要があることのみを決定できます。
Section 7.1 of [TLS13] specifies that HKDF-Expand-Label uses a label prefix of "tls13 ". For DTLS 1.3, that label SHALL be "dtls13". This ensures key separation between DTLS 1.3 and TLS 1.3. Note that there is no trailing space; this is necessary in order to keep the overall label size inside of one hash iteration because "DTLS" is one letter longer than "TLS".
[TLS13]のセクション7.1は、HKDF-Expand-Labelが「TLS13」のラベルプレフィックスを使用することを指定しています。DTLS 1.3の場合、そのラベルは「DTLS13」でなければなりません。これにより、DTLS 1.3とTLS 1.3の重要な分離が保証されます。後続のスペースはないことに注意してください。これは、「DTL」が「TLS」よりも1文字長いため、1つのハッシュ反復内にラベルサイズ全体を維持するために必要です。
Note that alert messages are not retransmitted at all, even when they occur in the context of a handshake. However, a DTLS implementation which would ordinarily issue an alert SHOULD generate a new alert message if the offending record is received again (e.g., as a retransmitted handshake message). Implementations SHOULD detect when a peer is persistently sending bad messages and terminate the local connection state after such misbehavior is detected. Note that alerts are not reliably transmitted; implementations SHOULD NOT depend on receiving alerts in order to signal errors or connection closure.
アラートメッセージは、握手のコンテキストで発生した場合でも、まったく再送信されないことに注意してください。ただし、通常、アラートを発行するDTLS実装は、問題の記録が再度受信された場合（たとえば、再送信されたハンドシェイクメッセージとして）新しいアラートメッセージを生成する必要があります。実装は、ピアが悪いメッセージを永続的に送信しているときに検出し、そのような不正行為が検出された後、ローカル接続状態を終了する必要があります。アラートは確実に送信されないことに注意してください。実装は、エラーや接続の閉鎖を信号するために、アラートの受信に依存してはなりません。
Any data received with an epoch/sequence number pair after that of a valid received closure alert MUST be ignored. Note: this is a change from TLS 1.3 which depends on the order of receipt rather than the epoch and sequence number.
有効な受信閉鎖アラートのエポック/シーケンス番号ペアで受信したデータは無視する必要があります。注：これは、エポック数とシーケンス番号ではなく、領収書の順序に依存するTLS 1.3からの変更です。
If a DTLS client-server pair is configured in such a way that repeated connections happen on the same host/port quartet, then it is possible that a client will silently abandon one connection and then initiate another with the same parameters (e.g., after a reboot). This will appear to the server as a new handshake with epoch=0. In cases where a server believes it has an existing association on a given host/port quartet and it receives an epoch=0 ClientHello, it SHOULD proceed with a new handshake but MUST NOT destroy the existing association until the client has demonstrated reachability either by completing a cookie exchange or by completing a complete handshake including delivering a verifiable Finished message. After a correct Finished message is received, the server MUST abandon the previous association to avoid confusion between two valid associations with overlapping epochs. The reachability requirement prevents off-path/ blind attackers from destroying associations merely by sending forged ClientHellos.
DTLSクライアント - サーバ対が同じホスト/ポートカルテット上で繰り返し接続が発生するように構成されている場合、クライアントが1つの接続を静かに放棄し、次に同じパラメータを使用して別の接続を開始する可能性がある（例えば、リブート）。これは、Epoch = 0の新しいハンドシェイクとしてサーバーに表示されます。サーバーが特定のホスト/ポートQuartetで既存の関連付けを持ち、EPOCH = 0 ClientHelloを受信した場合は、新しいハンドシェイクを進める必要がありますが、クライアントが到達可能性を実証するまで既存の関連付けを破棄してはいけません。クッキー交換または検証可能な完成メッセージを配信することを含む完全なハンドシェイクを完了することによって。正しい完成メッセージが受信された後、サーバーは、オーバーラップエポックとの2つの有効な関連付けの間の混乱を避けるために、サーバーは前の関連付けを放棄する必要があります。到達可能性の要件は、オフパス/ブラインド攻撃者が鍛造されたClientHellosを送信するだけで、アソシエーションを破壊するのを防ぎます。
Note: It is not always possible to distinguish which association a given record is from. For instance, if the client performs a handshake, abandons the connection, and then immediately starts a new handshake, it may not be possible to tell which connection a given protected record is for. In these cases, trial decryption may be necessary, though implementations could use CIDs to avoid the 5-tuple-based ambiguity.
注：与えられたレコードがどこからであるかを区別することは必ずしも可能ではありません。たとえば、クライアントがハンドシェイクを実行している場合は、接続に停止してから、すぐに新しいハンドシェイクを開始します。与えられた保護されたレコードがどの接続であるかをわかりません。このような場合、実装は5タプルベースのあいまいさを回避するためにCIDSを使用することができるが、試行復号化が必要な場合がある。
The following is an example of a handshake with lost packets and retransmissions. Note that the client sends an empty ACK message because it can only acknowledge Record 2 sent by the server once it has processed messages in Record 0 needed to establish epoch 2 keys, which are needed to encrypt or decrypt messages found in Record 2. Section 7 provides the necessary background details for this interaction. Note: For simplicity, we are not resetting record numbers in this diagram, so "Record 1" is really "Epoch 2, Record 0", etc.
以下は、失われたパケットと再送信による握手の例です。クライアントは空のACKメッセージを送信することに注意してください。なぜなら、サーバーが送信したレコード2を確認できるため、レコード2キーを確立するために必要なレコード0のメッセージを処理した後、レコード2で見つかったメッセージを暗号化または復号化するために必要な場合に注意してください。この相互作用に必要な背景の詳細を提供します。注：簡単にするために、この図でレコード番号をリセットしていないため、「レコード1」は本当に「エポック2、レコード0」などです。
Client Server
------ ------
Record 0 -------->
ClientHello
(message_seq=0)
X<----- Record 0
(lost) ServerHello
(message_seq=0)
Record 1
EncryptedExtensions
(message_seq=1)
Certificate
(message_seq=2)
<-------- Record 2
CertificateVerify
(message_seq=3)
Finished
(message_seq=4)
Record 1 -------->
ACK []
<-------- Record 3
ServerHello
(message_seq=0)
EncryptedExtensions
(message_seq=1)
Certificate
(message_seq=2)
<-------- Record 4
CertificateVerify
(message_seq=3)
Finished
(message_seq=4)
Record 2 -------->
Certificate
(message_seq=1)
CertificateVerify
(message_seq=2)
Finished
(message_seq=3)
<-------- Record 5
ACK [2]
Figure 12: Example DTLS Exchange Illustrating Message Loss
図12：メッセージの損失を示すDTLS Exchangeの例
A recipient of a DTLS message needs to select the correct keying material in order to process an incoming message. With the possibility of message loss and reordering, an identifier is needed to determine which cipher state has been used to protect the record payload. The epoch value fulfills this role in DTLS. In addition to the TLS 1.3-defined key derivation steps (see Section 7 of [TLS13]), a sender may want to rekey at any time during the lifetime of the connection. It therefore needs to indicate that it is updating its sending cryptographic keys.
DTLSメッセージの受信者は、着信メッセージを処理するために正しいキーイング資料を選択する必要があります。メッセージの損失と並べ替えの可能性で、レコードペイロードを保護するためにどの暗号状態が使用されてきたかを判断するために識別子が必要です。EPOCH値はDTLSにおけるこの役割を果たします。TLS 1.3定義のキー導出ステップ（[TLS13]のセクション7を参照）に加えて、送信者は接続の有効期間中いつでも再確認したいと思うかもしれません。したがって、送信暗号化キーを送信していることを示す必要があります。
This version of DTLS assigns dedicated epoch values to messages in the protocol exchange to allow identification of the correct cipher state:
このバージョンのDTLSは、専用のエポック値をプロトコル交換のメッセージに割り当て、正しい暗号状態を識別できるようにします。
* Epoch value (0) is used with unencrypted messages. There are three unencrypted messages in DTLS, namely ClientHello, ServerHello, and HelloRetryRequest.
* エポック値（0）は暗号化されていないメッセージで使用されます。DTLSには3つの暗号化されていないメッセージ、すなわちClientHello、ServerHello、およびHelloretryRequestがあります。
* Epoch value (1) is used for messages protected using keys derived from client_early_traffic_secret. Note that this epoch is skipped if the client does not offer early data.
* EPOCH値（1）は、client_early_traffic_secretから派生したキーを使用して保護されたメッセージに使用されます。クライアントが早期データを提供していない場合、このエポックはスキップされます。
* Epoch value (2) is used for messages protected using keys derived from [sender]_handshake_traffic_secret. Messages transmitted during the initial handshake, such as EncryptedExtensions, CertificateRequest, Certificate, CertificateVerify, and Finished, belong to this category. Note, however, that post-handshake messages are protected under the appropriate application traffic key and are not included in this category.
* エポック値（2）は、[送信者] _handshake_traffic_secretから派生したキーを使用して保護されたメッセージに使用されます。暗号化されたTextensions、certifateaterequest、certifativeverify、および完成など、最初の握手中に送信されたメッセージは、このカテゴリに属します。ただし、ポストハンドシェイクメッセージは適切なアプリケーショントラフィックキーの下で保護されており、このカテゴリには含まれていないことに注意してください。
* Epoch value (3) is used for payloads protected using keys derived from the initial [sender]_application_traffic_secret_0. This may include handshake messages, such as post-handshake messages (e.g., a NewSessionTicket message).
* エポック値（3）は、初期の[送信者] _Application_traffic_secret_0から派生したキーを使用して保護されたペイロードに使用されます。これには、ポストハンドシェイクメッセージ（NewsessionTicketメッセージなど）などのハンドシェイクメッセージが含まれる場合があります。
* Epoch values (4 to 2^64-1) are used for payloads protected using keys from the [sender]_application_traffic_secret_N (N>0).
* エポック値（4~2 ^ 64-1）は、[送信者] _Application_traffic_secret_n（n> 0）からのキーを使用して保護されたペイロードに使用されます。
Using these reserved epoch values, a receiver knows what cipher state has been used to encrypt and integrity protect a message. Implementations that receive a record with an epoch value for which no corresponding cipher state can be determined SHOULD handle it as a record which fails deprotection.
これらの予約されたエポック値を使用して、受信者は、メッセージの暗号化と整合性を保護するために使用されたCipher状態を知っています。対応する暗号状態を決定できないエポック値でレコードを受け取る実装は、脱保護に失敗するレコードとしてそれを処理する必要があります。
Note that epoch values do not wrap. If a DTLS implementation would need to wrap the epoch value, it MUST terminate the connection.
エポック値は折り返されないことに注意してください。DTLS実装がエポック値をラップする必要がある場合は、接続を終了する必要があります。
The traffic key calculation is described in Section 7.3 of [TLS13].
トラフィックキーの計算は、[TLS13]のセクション7.3で説明されています。
Figure 13 illustrates the epoch values in an example DTLS handshake.
図13は、DTLSハンドシェイクの例のエポック値を示しています。
Client Server
------ ------
Record 0
ClientHello
(epoch=0)
-------->
Record 0
<-------- HelloRetryRequest
(epoch=0)
Record 1
ClientHello -------->
(epoch=0)
Record 1
<-------- ServerHello
(epoch=0)
{EncryptedExtensions}
(epoch=2)
{Certificate}
(epoch=2)
{CertificateVerify}
(epoch=2)
{Finished}
(epoch=2)
Record 2
{Certificate} -------->
(epoch=2)
{CertificateVerify}
(epoch=2)
{Finished}
(epoch=2)
Record 2
<-------- [ACK]
(epoch=3)
Record 3
[Application Data] -------->
(epoch=3)
Record 3
<-------- [Application Data]
(epoch=3)
Some time later ...
(Post-Handshake Message Exchange)
Record 4
<-------- [NewSessionTicket]
(epoch=3)
Record 4
[ACK] -------->
(epoch=3)
Some time later ...
(Rekeying)
Record 5
<-------- [Application Data]
(epoch=4)
Record 5
[Application Data] -------->
(epoch=4)
Figure 13: Example DTLS Exchange with Epoch Information
図13：Epoch情報との例示DTLS交換
The ACK message is used by an endpoint to indicate which handshake records it has received and processed from the other side. ACK is not a handshake message but is rather a separate content type, with code point 26. This avoids having ACK being added to the handshake transcript. Note that ACKs can still be sent in the same UDP datagram as handshake records.
ACKメッセージは、どのハンドシェイクレコードが他方の側から受信および処理されたかを示すためにエンドポイントによって使用されます。ACKはハンドシェイクメッセージではなく、コードポイント26を持つ別のコンテンツタイプです。これにより、ACKがハンドシェイクトランスクリプトに追加されることを回避します。ACKは、ハンドシェイクレコードと同じUDPデータグラムで送信できることに注意してください。
struct {
RecordNumber record_numbers<0..2^16-1>;
} ACK;
record_numbers: A list of the records containing handshake messages in the current flight which the endpoint has received and either processed or buffered, in numerically increasing order.
Record_Numbers：エンドポイントが受信し、処理またはバッファリングされた現在のフライトに握手メッセージを含むレコードのリストは、数値的に順序を増やします。
Implementations MUST NOT acknowledge records containing handshake messages or fragments which have not been processed or buffered. Otherwise, deadlock can ensue. As an example, implementations MUST NOT send ACKs for handshake messages which they discard because they are not the next expected message.
実装は、処理またはバッファリングされていないハンドシェイクメッセージまたはフラグメントを含むレコードを確認してはなりません。そうでなければ、デッドロックが続く可能性があります。例として、実装は、次の予想されるメッセージではないため、ハンドシェイクメッセージにAcksを送信してはなりません。
During the handshake, ACKs only cover the current outstanding flight (this is possible because DTLS is generally a lock-step protocol). In particular, receiving a message from a handshake flight implicitly acknowledges all messages from the previous flight(s). Accordingly, an ACK from the server would not cover both the ClientHello and the client's Certificate message, because the ClientHello and client Certificate are in different flights. Implementations can accomplish this by clearing their ACK list upon receiving the start of the next flight.
握手中、ACKSは現在の未払いの飛行のみをカバーしています（これは、DTLSが一般的にロックステッププロトコルであるため可能です）。特に、握手フライトからメッセージを受信すると、以前のフライトからのすべてのメッセージが暗黙的に認められます。したがって、クライアントヘロとクライアントの証明書は異なるフライトにあるため、サーバーからのACKはクライアントヘロとクライアントの証明書メッセージの両方をカバーしません。実装は、次のフライトの開始を受信するとACKリストをクリアすることでこれを達成できます。
For post-handshake messages, ACKs SHOULD be sent once for each received and processed handshake record (potentially subject to some delay) and MAY cover more than one flight. This includes records containing messages which are discarded because a previous copy has been received.
ハンドシェイクメッセージの後、受信したハンドシェイクレコードと処理されたハンドシェイクレコード（潜在的にある遅延を受ける可能性がある）に対して、ACKを1回送信する必要があります。これには、前のコピーが受信されたため、破棄されるメッセージを含むレコードが含まれます。
During the handshake, ACK records MUST be sent with an epoch which is equal to or higher than the record which is being acknowledged. Note that some care is required when processing flights spanning multiple epochs. For instance, if the client receives only the ServerHello and Certificate and wishes to ACK them in a single record, it must do so in epoch 2, as it is required to use an epoch greater than or equal to 2 and cannot yet send with any greater epoch. Implementations SHOULD simply use the highest current sending epoch, which will generally be the highest available. After the handshake, implementations MUST use the highest available sending epoch.
握手中、ACKレコードは、認められているレコード以上のエポックで送信する必要があります。複数のエポックにまたがるフライトを処理する場合は、ある程度の注意が必要であることに注意してください。たとえば、クライアントがServerHelloと証明書のみを受信し、単一のレコードでそれらをACKしたい場合、Epoch 2では2以上のエポックを使用する必要があり、まだ送信できないため、それを行う必要があります。より大きな時代。実装では、単に最高の電流送信エポックを使用する必要があります。これは一般に利用可能な最高のものです。握手の後、実装は利用可能な最高の送信エポックを使用する必要があります。
When an implementation detects a disruption in the receipt of the current incoming flight, it SHOULD generate an ACK that covers the messages from that flight which it has received and processed so far. Implementations have some discretion about which events to treat as signs of disruption, but it is RECOMMENDED that they generate ACKs under two circumstances:
実装が現在の着信フライトの受信の中断を検出すると、それがこれまでに受信および処理されたそのフライトからのメッセージをカバーするACKを生成する必要があります。実装には、どのイベントが中断の兆候として扱うかについての裁量がいくつかありますが、2つの状況下でACKを生成することをお勧めします。
* When they receive a message or fragment which is out of order, either because it is not the next expected message or because it is not the next piece of the current message.
* 彼らが次に予想されるメッセージではないか、現在のメッセージの次のピースではないために、故障したメッセージまたはフラグメントを受け取るとき。
* When they have received part of a flight and do not immediately receive the rest of the flight (which may be in the same UDP datagram). "Immediately" is hard to define. One approach is to set a timer for 1/4 the current retransmit timer value when the first record in the flight is received and then send an ACK when that timer expires. Note: The 1/4 value here is somewhat arbitrary. Given that the round trip estimates in the DTLS handshake are generally very rough (or the default), any value will be an approximation, and there is an inherent compromise due to competition between retransmission due to over-aggressive ACKing and over-aggressive timeout-based retransmission. As a comparison point, QUIC's loss-based recovery algorithms ([RFC9002], Section 6.1.2) work out to a delay of about 1/3 of the retransmit timer.
* フライトの一部を受け取ったとき、そしてすぐにフライトの残りの部分を受け取らない場合（同じUDPデータグラムにあるかもしれません）。「すぐに」定義するのが難しいです。1つのアプローチは、フライト内の最初のレコードが受信されたときに現在の再送信タイマ値を1/4に設定し、そのタイマーが期限切れになったときにACKを送信するようにタイマーを設定することです。注：ここで1/4値はやや任意です。DTLSハンドシェイクの往復推定値が一般的に非常に荒れている（またはデフォルト）、任意の値は近似値になり、積極的な攻撃による再送信と過度の積極的なタイムアウトによる再送信の競合による固有の妥協点があります。再送に基づく。比較点として、QUICの損失ベースの回復アルゴリズム（[RFC9002]、6.1.2）は、再送信タイマの約1/3の遅延に機能します。
In general, flights MUST be ACKed unless they are implicitly acknowledged. In the present specification, the following flights are implicitly acknowledged by the receipt of the next flight, which generally immediately follows the flight:
一般に、フライトは暗黙のうちに認められない限り、ackedする必要があります。現在の仕様では、次のフライトは次のフライトの受領によって暗黙的に認められます。これは通常、フライトの直後になります。
1. Handshake flights other than the client's final flight of the main handshake.
1. クライアントのメインハンドシェイクの最終飛行以外の握手フライト。
2. The server's post-handshake CertificateRequest.
2. サーバーのポストハンドシェイクCertificateRequest。
ACKs SHOULD NOT be sent for these flights unless the responding flight cannot be generated immediately. All other flights MUST be ACKed. In this case, implementations MAY send explicit ACKs for the complete received flight even though it will eventually also be implicitly acknowledged through the responding flight. A notable example for this is the case of client authentication in constrained environments, where generating the CertificateVerify message can take considerable time on the client. Implementations MAY acknowledge the records corresponding to each transmission of each flight or simply acknowledge the most recent one. In general, implementations SHOULD ACK as many received packets as can fit into the ACK record, as this provides the most complete information and thus reduces the chance of spurious retransmission; if space is limited, implementations SHOULD favor including records which have not yet been acknowledged.
応答フライトをすぐに生成できない限り、これらのフライトにACKを送信しないでください。他のすべてのフライトをAckedする必要があります。この場合、実装は、最終的に応答するフライトを通じて暗黙的に認められるにもかかわらず、完全な受信フライトの明示的なAcksを送信する場合があります。これの注目すべき例は、Certimateverifyメッセージを生成することでクライアントにかなりの時間がかかる可能性があるため、制約された環境でクライアント認証の場合です。実装は、各フライトの各伝送に対応するレコードを認めるか、単に最新のフライトを確認する場合があります。一般に、実装はACKレコードに収まると同じくらい多くの受信パケットをACKする必要があります。これは、最も完全な情報を提供し、したがって偽りの再送信の可能性を減らすためです。スペースが限られている場合、実装はまだ認められていない記録を含めて有利なものです。
Note: While some post-handshake messages follow a request/response pattern, this does not necessarily imply receipt. For example, a KeyUpdate sent in response to a KeyUpdate with request_update set to "update_requested" does not implicitly acknowledge the earlier KeyUpdate message because the two KeyUpdate messages might have crossed in flight.
注：いくつかのハンドシェイクメッセージが要求/応答パターンに従うが、これは必ずしも受信を意味するわけではありません。たとえば、request_updateが "update_requested"に設定されているKeyUpdateに応答して送信されたKeyUpdateは、2つのKeyUpdateメッセージがフライトで交差した可能性があるため、以前のKeyUpdateメッセージを暗黙的に確認しません。
ACKs MUST NOT be sent for records of any content type other than handshake or for records which cannot be deprotected.
ACKは、ハンドシェイク以外のコンテンツタイプのレコードまたは脱保護できないレコードのために送信してはなりません。
Note that in some cases it may be necessary to send an ACK which does not contain any record numbers. For instance, a client might receive an EncryptedExtensions message prior to receiving a ServerHello. Because it cannot decrypt the EncryptedExtensions, it cannot safely acknowledge it (as it might be damaged). If the client does not send an ACK, the server will eventually retransmit its first flight, but this might take far longer than the actual round trip time between client and server. Having the client send an empty ACK shortcuts this process.
場合によっては、レコード番号が含まれていないACKを送信する必要がある場合があることに注意してください。たとえば、クライアントはServerHelloを受信する前に暗号化されたEdextensionsメッセージを受信する場合があります。暗号化されたEdedExtensionsを復号化できないため、安全に認めることはできません（損傷している可能性があるため）。クライアントがACKを送信しない場合、サーバーは最終的に最初のフライトを再送信しますが、これはクライアントとサーバー間の実際の往復時間よりもはるかに長くかかる場合があります。クライアントに空のACKショートカットを送信させると、このプロセス。
When an implementation receives an ACK, it SHOULD record that the messages or message fragments sent in the records being ACKed were received and omit them from any future retransmissions. Upon receipt of an ACK that leaves it with only some messages from a flight having been acknowledged, an implementation SHOULD retransmit the unacknowledged messages or fragments. Note that this requires implementations to track which messages appear in which records. Once all the messages in a flight have been acknowledged, the implementation MUST cancel all retransmissions of that flight. Implementations MUST treat a record as having been acknowledged if it appears in any ACK; this prevents spurious retransmission in cases where a flight is very large and the receiver is forced to elide acknowledgements for records which have already been ACKed. As noted above, the receipt of any record responding to a given flight MUST be taken as an implicit acknowledgement for the entire flight to which it is responding.
実装がACKを受信すると、ACKされているレコードで送信されたメッセージまたはメッセージフラグメントが受信され、将来の再送信からそれらを省略したことを記録する必要があります。承認されたフライトからのメッセージのみを残すACKを受信すると、実装は未確認のメッセージまたはフラグメントを再送信する必要があります。これには、どのメッセージがレコードに表示されるかを追跡するための実装が必要です。フライト内のすべてのメッセージが確認されたら、その実装はそのフライトのすべての再送信をキャンセルする必要があります。実装は、任意のACKに表示されている場合は、レコードを承認されたものとして扱う必要があります。これは、飛行が非常に大きく、受信機はすでに撮影されている記録の承認を余儀なくされることを余儀なくされている。上記のように、特定のフライトに応答するレコードの受信は、それが応答しているフライト全体の暗黙の確認として取られる必要があります。
ACK messages are used in two circumstances, namely:
ACKメッセージは、2つの状況で使用されます。
* On sign of disruption, or lack of progress; and
* 混乱の兆候、または進歩の欠如。と
* To indicate complete receipt of the last flight in a handshake.
* 握手で最後のフライトの完全な受領を示すため。
In the first case, the use of the ACK message is optional, because the peer will retransmit in any case and therefore the ACK just allows for selective or early retransmission, as opposed to the timeout-based whole flight retransmission in previous versions of DTLS. When DTLS 1.3 is used in deployments with lossy networks, such as low-power, long-range radio networks as well as low-power mesh networks, the use of ACKs is recommended.
最初のケースでは、ACKメッセージの使用はオプションです。これは、ピアがいずれにせよ再送信するため、ACKはDTLSの以前のバージョンでのタイムアウトベースのフライト全体の再送信とは対照的に、選択的または早期の再送信を可能にするだけです。DTLS 1.3が、低電力、長距離無線ネットワークや低電力メッシュネットワークなどの損失ネットワークを使用した展開で使用される場合、ACKの使用をお勧めします。
The use of the ACK for the second case is mandatory for the proper functioning of the protocol. For instance, the ACK message sent by the client in Figure 13 acknowledges receipt and processing of Record 4 (containing the NewSessionTicket message), and if it is not sent, the server will continue retransmission of the NewSessionTicket indefinitely until its maximum retransmission count is reached.
2番目のケースにACKを使用することは、プロトコルの適切な機能に必須です。たとえば、図13のクライアントが送信したACKメッセージは、レコード4の領収書と処理（NewsessionTicketメッセージを含む）を確認し、送信されない場合、サーバーは最大再送信カウントに達するまで無期限にNewsessionTicketの再送信を継続します。。
As with TLS 1.3, DTLS 1.3 implementations send a KeyUpdate message to indicate that they are updating their sending keys. As with other handshake messages with no built-in response, KeyUpdates MUST be acknowledged. In order to facilitate epoch reconstruction (Section 4.2.2), implementations MUST NOT send records with the new keys or send a new KeyUpdate until the previous KeyUpdate has been acknowledged (this avoids having too many epochs in active use).
TLS 1.3と同様に、DTLS 1.3の実装は、キーアップデートメッセージを送信して、送信キーを更新していることを示します。反応が組み込まれていない他のハンドシェイクメッセージと同様に、KeyUpDatesを確認する必要があります。エポックの再構成を促進するために（セクション4.2.2）、実装は新しいキーでレコードを送信したり、以前のkeyUpdateが認められるまで新しいkeyUpdateを送信したりしてはなりません（これにより、アクティブに使用されているエポックが多すぎることがなくなります）。
Due to loss and/or reordering, DTLS 1.3 implementations may receive a record with an older epoch than the current one (the requirements above preclude receiving a newer record). They SHOULD attempt to process those records with that epoch (see Section 4.2.2 for information on determining the correct epoch) but MAY opt to discard such out-of-epoch records.
損失および/または並べ替えにより、DTLS 1.3の実装は、現在のエポックよりも古いエポックでレコードを受信する場合があります（上記の要件は、新しいレコードを受け取ることを妨げます）。彼らはその時代でそれらのレコードを処理しようとする必要があります（正しいエポックを決定する詳細については、セクション4.2.2を参照）が、そのようなエポック外のレコードを破棄することを選択する場合があります。
Due to the possibility of an ACK message for a KeyUpdate being lost and thereby preventing the sender of the KeyUpdate from updating its keying material, receivers MUST retain the pre-update keying material until receipt and successful decryption of a message using the new keys.
KeyUpdateが失われ、それによってKeyUpdateの送信者がそのキーイング資料を更新するのを防ぐためのACKメッセージが失われる可能性があるため、受信者は新しいキーを使用してメッセージの受信および成功の復号化まで、更新前のキーイングを保持しなければなりません。
Figure 14 shows an example exchange illustrating that successful ACK processing updates the keys of the KeyUpdate message sender, which is reflected in the change of epoch values.
図14は、成功したACK処理がキーアップデートメッセージ送信者のキーを更新することを示す例を示しています。これはエポック値の変化に反映されています。
Client Server
クライアントサーバー
/-------------------------------------------\
| |
| Initial Handshake |
\-------------------------------------------/
[Application Data] -------->
(epoch=3)
<-------- [Application Data]
(epoch=3)
/-------------------------------------------\
| |
| Some time later ... |
\-------------------------------------------/
[Application Data] -------->
(epoch=3)
[KeyUpdate]
(+ update_requested -------->
(epoch 3)
<-------- [Application Data]
(epoch=3)
[ACK]
<-------- (epoch=3)
[Application Data]
(epoch=4) -------->
<-------- [KeyUpdate]
(epoch=3)
[ACK] -------->
(epoch=4)
<-------- [Application Data]
(epoch=4)
Figure 14: Example DTLS Key Update
図14：DTLSキーの更新の例
With a 128-bit key as in AES-128, rekeying 2^64 times has a high probability of key reuse within a given connection. Note that even if the key repeats, the IV is also independently generated. In order to provide an extra margin of security, sending implementations MUST NOT allow the epoch to exceed 2^48-1. In order to allow this value to be changed later, receiving implementations MUST NOT enforce this rule. If a sending implementation receives a KeyUpdate with request_update set to "update_requested", it MUST NOT send its own KeyUpdate if that would cause it to exceed these limits and SHOULD instead ignore the "update_requested" flag. Note: this overrides the requirement in TLS 1.3 to always send a KeyUpdate in response to "update_requested".
AES-128のように128ビットキーを使用すると、2^64回を再キーにすると、特定の接続内でキーの再利用の可能性が高くなります。キーが繰り返されたとしても、IVも独立して生成されることに注意してください。セキュリティの余分なマージンを提供するために、実装を送信することで、エポックが2^48-1を超えることを許可してはなりません。この値を後で変更できるようにするために、実装を受信することはこのルールを実施してはなりません。送信実装が「update_requested」に設定されたrequest_updateを使用してkeyupdateを受信した場合、これらの制限を超えて「update_requested」フラグを無視する場合、独自のkeyupdateを送信してはなりません。注：これにより、TLS 1.3の要件がオーバーライドされ、「update_requested」に応じて常にキーアップデートを送信します。
If the client and server have negotiated the "connection_id" extension [RFC9146], either side can send a new CID that it wishes the other side to use in a NewConnectionId message.
クライアントとサーバーが「connection_id」拡張子[RFC9146]を交渉した場合、どちらの側も、NewConnectionIDメッセージで反対側が使用することを望んでいる新しいCIDを送信できます。
enum {
cid_immediate(0), cid_spare(1), (255)
} ConnectionIdUsage;
opaque ConnectionId<0..2^8-1>;
struct {
ConnectionId cids<0..2^16-1>;
ConnectionIdUsage usage;
} NewConnectionId;
cids: Indicates the set of CIDs that the sender wishes the peer to use.
CIDS：送信者がピアに使用することを望んでいるCIDのセットを示します。
usage: Indicates whether the new CIDs should be used immediately or are spare. If usage is set to "cid_immediate", then one of the new CIDs MUST be used immediately for all future records. If it is set to "cid_spare", then either an existing or new CID MAY be used.
使用法：新しいCIDをすぐに使用する必要があるか、予備のかを示します。使用法が「cid_immediate」に設定されている場合、新しいCIDの1つをすべての将来のレコードにすぐに使用する必要があります。「CID_SPARE」に設定されている場合、既存または新しいCIDを使用できます。
Endpoints SHOULD use receiver-provided CIDs in the order they were provided. Implementations which receive more spare CIDs than they wish to maintain MAY simply discard any extra CIDs. Endpoints MUST NOT have more than one NewConnectionId message outstanding.
エンドポイントは、提供された順序で受信者提供のCIDを使用する必要があります。維持したいよりも多くの予備のCIDを受け取る実装は、追加のCIDを捨てることができます。エンドポイントには、2つ以上のNewConnectionIDメッセージが未解決ではありません。
Implementations which either did not negotiate the "connection_id" extension or which have negotiated receiving an empty CID MUST NOT send NewConnectionId. Implementations MUST NOT send RequestConnectionId when sending an empty Connection ID. Implementations which detect a violation of these rules MUST terminate the connection with an "unexpected_message" alert.
「connection_id」拡張機能を交渉しなかった、または空のCIDの受信を交渉した実装は、NewConnectionIDを送信してはなりません。実装は、空の接続IDを送信するときにRequestConnectionIDを送信してはなりません。これらのルールの違反を検出する実装では、「rediced_message」アラートとの接続を終了する必要があります。
Implementations SHOULD use a new CID whenever sending on a new path and SHOULD request new CIDs for this purpose if path changes are anticipated.
実装は、新しいパスを送信するときはいつでも新しいCIDを使用する必要があり、パス変更が予想される場合は、この目的のために新しいCIDを要求する必要があります。
struct {
uint8 num_cids;
} RequestConnectionId;
num_cids: The number of CIDs desired.
num_cids：希望するCIDの数。
Endpoints SHOULD respond to RequestConnectionId by sending a NewConnectionId with usage "cid_spare" containing num_cids CIDs as soon as possible. Endpoints MUST NOT send a RequestConnectionId message when an existing request is still unfulfilled; this implies that endpoints need to request new CIDs well in advance. An endpoint MAY handle requests which it considers excessive by responding with a NewConnectionId message containing fewer than num_cids CIDs, including no CIDs at all. Endpoints MAY handle an excessive number of RequestConnectionId messages by terminating the connection using a "too_many_cids_requested" (alert number 52) alert.
エンドポイントは、num_cids cidsを含む「cid_spare」を備えたnewConnectionIDをできるだけ早く送信することにより、RequestConnectionIDに応答する必要があります。既存のリクエストがまだ満たされていない場合、エンドポイントはrequestConnectionIDメッセージを送信してはなりません。これは、エンドポイントが事前に新しいCIDをリクエストする必要があることを意味します。エンドポイントは、num_cidsよりも少ないCIDよりも少ないCIDを含むnewConnectionIDメッセージで応答することにより、過剰と見なすリクエストを処理する場合があります。エンドポイントは、「TOO_MANY_CIDS_REQUESTED」（アラート番号52）アラートを使用して接続を終了することにより、過剰な数のRequestConnectionIDメッセージを処理できます。
Endpoints MUST NOT send either of these messages if they did not negotiate a CID. If an implementation receives these messages when CIDs were not negotiated, it MUST abort the connection with an "unexpected_message" alert.
エンドポイントは、CIDをネゴシエートしなかった場合は、これらのメッセージのいずれかを送信してはなりません。CIDがネゴシエートされなかったときに実装がこれらのメッセージを受信した場合は、「infented_message」アラートで接続を中止する必要があります。
Below is an example exchange for DTLS 1.3 using a single CID in each direction.
以下は、各方向の単一のCIDを使用するDTLS 1.3の交換の例です。
Note: The "connection_id" extension, which is used in ClientHello and ServerHello messages, is defined in [RFC9146].
注：clienthelloおよびserverhelloメッセージで使用される「connection_id」拡張機能は、[RFC9146]で定義されています。
Client Server
------ ------
ClientHello
(connection_id=5)
-------->
<-------- HelloRetryRequest
(cookie)
ClientHello -------->
(connection_id=5)
+ cookie
<-------- ServerHello
(connection_id=100)
EncryptedExtensions
(cid=5)
Certificate
(cid=5)
CertificateVerify
(cid=5)
Finished
(cid=5)
Certificate -------->
(cid=100)
CertificateVerify
(cid=100)
Finished
(cid=100)
<-------- ACK
(cid=5)
Application Data ========>
(cid=100)
<======== Application Data
(cid=5)
Figure 15: Example DTLS 1.3 Exchange with CIDs
図15：例DTLS 1.3 CIDとの交換
If no CID is negotiated, then the receiver MUST reject any records it receives that contain a CID.
CIDが交渉されていない場合、受信者はCIDを含む受信したレコードを拒否する必要があります。
Application data messages are carried by the record layer and are split into records and encrypted based on the current connection state. The messages are treated as transparent data to the record layer.
アプリケーションデータメッセージはレコード層によって搬送され、現在の接続状態に基づいてレコードに分割され、暗号化されます。メッセージは透過データとしてレコード層に扱われます。
Security issues are discussed primarily in [TLS13].
セキュリティ上の問題は、主に[TLS13]に議論されています。
The primary additional security consideration raised by DTLS is that of denial of service by excessive resource consumption. DTLS includes a cookie exchange designed to protect against denial of service. However, implementations that do not use this cookie exchange are still vulnerable to DoS. In particular, DTLS servers that do not use the cookie exchange may be used as attack amplifiers even if they themselves are not experiencing DoS. Therefore, DTLS servers SHOULD use the cookie exchange unless there is good reason to believe that amplification is not a threat in their environment. Clients MUST be prepared to do a cookie exchange with every handshake.
DTLSによって提起された主要な追加のセキュリティ対価は、過度のリソース消費によるサービス拒否のものです。DTLSには、サービスの拒否から保護するように設計されたCookie Exchangeが含まれています。ただし、このCookie Exchangeを使用していない実装は、依然としてDOSに対して脆弱です。特に、Cookie Exchangeを使用していないDTLSサーバーは、DOSが経験していなくても、攻撃アンプとして使用できます。したがって、DTLSサーバーは、増幅が環境の脅威ではないと信じる正当な理由がない限り、Cookie Exchangeを使用する必要があります。クライアントは、すべての握手でクッキー交換を行う準備をする必要があります。
Some key properties required of the cookie for the cookie-exchange mechanism to be functional are described in Section 3.3 of [RFC2522]:
Cookie交換メカニズムに機能するためにCookieに必要ないくつかの重要な特性は、[RFC2522]のセクション3.3で説明されています。
* The cookie MUST depend on the client's address.
* Cookieは、クライアントのアドレスに依存する必要があります。
* It MUST NOT be possible for anyone other than the issuing entity to generate cookies that are accepted as valid by that entity. This typically entails an integrity check based on a secret key.
* 発行エンティティ以外の誰かがそのエンティティによって有効であると受け入れられたクッキーを生成することは可能ではありません。これは通常、秘密鍵に基づく整合性チェックを伴います。
* Cookie generation and verification are triggered by unauthenticated parties, and as such their resource consumption needs to be restrained in order to avoid having the cookie-exchange mechanism itself serve as a DoS vector.
* Cookieの生成と検証は、認定されていない当事者によって引き起こされ、そのため、Cookie交換メカニズム自体がDOSベクターとして機能することを避けるために、リソースの消費を抑制する必要があります。
Although the cookie must allow the server to produce the right handshake transcript, it SHOULD be constructed so that knowledge of the cookie is insufficient to reproduce the ClientHello contents. Otherwise, this may create problems with future extensions such as Encrypted Client Hello [TLS-ECH].
Cookieはサーバーが右のハンドシェイクトランスクリプトを作成できるようにする必要がありますが、クッキーの知識がClientHelloの内容を再現するのに不十分であるように構築されるべきです。そうでなければ、これは暗号化されたクライアントhello [TLS-ECH]などの将来の拡張機能に関する問題を生み出すかもしれません。
When cookies are generated using a keyed authentication mechanism, it should be possible to rotate the associated secret key, so that temporary compromise of the key does not permanently compromise the integrity of the cookie-exchange mechanism. Though this secret is not as high-value as, e.g., a session-ticket-encryption key, rotating the cookie-generation key on a similar timescale would ensure that the key rotation functionality is exercised regularly and thus in working order.
キー付き認証メカニズムを使用してCookieが生成される場合、関連する秘密キーを回転させることができる必要があります。そうすれば、キーの一時的な妥協がCookie交換メカニズムの整合性を永続的に侵害しないようにします。この秘密は、たとえばセッションチケット暗号化キーほど価値がありませんが、同様のタイムスケールでCookie-Generationキーを回転させると、キーの回転機能が定期的に行使され、したがって動作していることが保証されます。
The cookie exchange provides address validation during the initial handshake. DTLS with Connection IDs allows for endpoint addresses to change during the association; any such updated addresses are not covered by the cookie exchange during the handshake. DTLS implementations MUST NOT update the address they send to in response to packets from a different address unless they first perform some reachability test; no such test is defined in this specification and a future specification would need to specify a complete procedure for how and when to update addresses. Even with such a test, an active on-path adversary can also black-hole traffic or create a reflection attack 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 concern when there is a large asymmetry of request/response message sizes.
Cookie Exchangeは、最初の握手中のアドレス検証を提供します。接続IDを備えたDTLは、エンドポイントアドレスが関連性中に変更できるようにします。このような更新されたアドレスは、握手中のCookie Exchangeでカバーされません。DTLS実装は、最初に到達可能性テストを実行しない限り、異なるアドレスからパケットに応答して送信するアドレスを更新してはなりません。この仕様ではそのようなテストは定義されておらず、将来の仕様では、アドレスを更新する方法と時期の完全な手順を指定する必要があります。このようなテストがあっても、アクティブなオンパス敵は、DTLSピアが本物のアドレス更新イベントを区別する手段を持たないため、黒穴のトラフィックやサードパーティに対する反射攻撃を作成することもできます（たとえば、NATのリバインディングなど）悪意のあるものから。この攻撃は、要求/応答メッセージサイズの大きな非対称性がある場合に懸念があります。
With the exception of order protection and non-replayability, the security guarantees for DTLS 1.3 are the same as TLS 1.3. While TLS always provides order protection and non-replayability, DTLS does not provide order protection and may not provide replay protection.
注文保護と非再生性を除いて、DTLS 1.3のセキュリティ保証はTLS 1.3と同じです。TLSは常に注文保護と再生不能性を提供しているが、DTLは注文保護を提供しないため、再生保護を提供しない可能性があります。
Unlike TLS implementations, DTLS implementations SHOULD NOT respond to invalid records by terminating the connection.
TLSの実装とは異なり、DTLS実装は、接続を終了して無効なレコードに応答しないでください。
TLS 1.3 requires replay protection for 0-RTT data (or rather, for connections that use 0-RTT data; see Section 8 of [TLS13]). DTLS provides an optional per-record replay-protection mechanism, since datagram protocols are inherently subject to message reordering and replay. These two replay-protection mechanisms are orthogonal, and neither mechanism meets the requirements for the other.
TLS 1.3では、0-RTTデータのリプレイ保護が必要です（または、0-RTTデータを使用する接続については、[TLS13]のセクション8を参照）。DTLSは、データグラムのプロトコルは本質的にメッセージの並べ替えとリプレイの対象となるため、オプションの記録ごとのリプレイ保護メカニズムを提供します。これらの2つのリプレイ保護メカニズムは直交しており、どちらのメカニズムも他のメカニズムを満たしていません。
DTLS 1.3's handshake transcript does not include the new DTLS fields, which makes it have the same format as TLS 1.3. However, the DTLS 1.3 and TLS 1.3 transcripts are disjoint because they use different version numbers. Additionally, the DTLS 1.3 key schedule uses a different label and so will produce different keys for the same transcript.
DTLS 1.3のハンドシェイクトランスクリプトには、新しいDTLSフィールドは含まれていません。これはTLS 1.3と同じ形式です。ただし、DTLS 1.3とTLS 1.3のトランスクリプトは異なるバージョン番号を使用するためです。さらに、DTLS 1.3キースケジュールは別のラベルを使用しているため、同じトランスクリプトに対して異なるキーが生成されます。
The security and privacy properties of the CID for DTLS 1.3 build on top of what is described for DTLS 1.2 in [RFC9146]. There are, however, several differences:
DTLS 1.3のCIDのセキュリティとプライバシーのプロパティは、DTLS 1.2で説明されているものの上にある[RFC9146]。ただし、いくつかの違いがあります。
* In both versions of DTLS, extension negotiation is used to agree on the use of the CID feature and the CID values. In both versions, the CID is carried in the DTLS record header (if negotiated). However, the way the CID is included in the record header differs between the two versions.
* 両方のバージョンのDTLSでは、拡張交渉を使用して、CID機能とCID値の使用に同意します。どちらのバージョンでも、CIDはDTLSレコードヘッダー（ネゴシエートされた場合）に携帯されています。ただし、CIDがレコードヘッダーに含まれる方法は、2つのバージョン間で異なります。
* The use of the post-handshake message allows the client and the server to update their CIDs, and those values are exchanged with confidentiality protection.
* handshakeメッセージを使用すると、クライアントとサーバーはCIDを更新でき、それらの値は機密保護と交換されます。
* The ability to use multiple CIDs allows for improved privacy properties in multihomed scenarios. When only a single CID is in use on multiple paths from such a host, an adversary can correlate the communication interaction across paths, which adds further privacy concerns. In order to prevent this, implementations SHOULD attempt to use fresh CIDs whenever they change local addresses or ports (though this is not always possible to detect). The RequestConnectionId message can be used by a peer to ask for new CIDs to ensure that a pool of suitable CIDs is available.
* 複数のCIDを使用する機能により、マルチホームのシナリオでプライバシープロパティを改善できます。このようなホストからの複数のパスで単一のCIDのみが使用されている場合、敵はパス間のコミュニケーションの相互作用を相関させることができ、さらにプライバシーの懸念が追加されます。これを防ぐために、実装はローカルアドレスまたはポートを変更するたびに新鮮なCIDを使用しようとする必要があります（ただし、これは常に検出することができません）。RequestConnectionIDメッセージは、ピアが使用して、適切なCIDのプールが利用できるようにするために新しいCIDを要求することができます。
* The mechanism for encrypting sequence numbers (Section 4.2.3) prevents trivial tracking by on-path adversaries that attempt to correlate the pattern of sequence numbers received on different paths; such tracking could occur even when different CIDs are used on each path, in the absence of sequence number encryption. Switching CIDs based on certain events, or even regularly, helps against tracking by on-path adversaries. Note that sequence number encryption is used for all encrypted DTLS 1.3 records irrespective of whether a CID is used or not. Unlike the sequence number, the epoch is not encrypted because it acts as a key identifier, which may improve correlation of packets from a single connection across different network paths.
* シーケンス番号を暗号化するためのメカニズム（セクション4.2.3）は、さまざまなパスで受信されたシーケンス番号のパターンを相関させることを試みるオンパスの逆境による簡単な追跡を防ぎます。このようなトラッキングは、シーケンス番号暗号化がない場合に、各パスで異なるCIDが使用されていても発生する可能性があります。特定のイベントに基づいてCIDの切り替え、あるいは定期的には、経路上の逆境による追跡に役立ちます。シーケンス番号の暗号化は、CIDが使用されているかどうかにかかわらず、すべての暗号化されたDTLS 1.3レコードに使用されます。シーケンス番号とは異なり、Epochはキー識別子として機能するため暗号化されていません。これは、異なるネットワークパス間の単一の接続からのパケットの相関を向上させる可能性があります。
* DTLS 1.3 encrypts handshake messages much earlier than in previous DTLS versions. Therefore, less information identifying the DTLS client, such as the client certificate, is available to an on-path adversary.
* DTLS 1.3以前のDTLSバージョンよりもるかに早くハンドシェイクメッセージを暗号化します。したがって、クライアント証明書などのDTLSクライアントを識別する情報が少なく、オンパスの敵対者が利用できます。
Since TLS 1.3 introduces a large number of changes with respect to TLS 1.2, the list of changes from DTLS 1.2 to DTLS 1.3 is equally large. For this reason, this section focuses on the most important changes only.
TLS 1.3はTLS 1.2に関して多数の変更を導入するため、DTLS 1.2からDTLS 1.3への変更のリストも同様に大きくなっています。このため、このセクションでは、最も重要な変更のみに焦点を当てています。
* New handshake pattern, which leads to a shorter message exchange.
* 新しいハンドシェイクパターン。これは、短いメッセージ交換につながります。
* Only AEAD ciphers are supported. Additional data calculation has been simplified.
* AEAD暗号のみがサポートされています。追加のデータ計算が簡素化されました。
* Removed support for weaker and older cryptographic algorithms.
* 弱い暗号化アルゴリズムと古い暗号化アルゴリズムのサポートを削除しました。
* HelloRetryRequest of TLS 1.3 used instead of HelloVerifyRequest.
* HelloverifeRequestの代わりに使用されるTLS 1.3のHelloretryRequest。
* More flexible cipher suite negotiation.
* より柔軟な暗号スイート交渉。
* New session resumption mechanism.
* 新しいセッション再開メカニズム。
* PSK authentication redefined.
* PSK認証が再定義されました。
* New key derivation hierarchy utilizing a new key derivation construct.
* 新しいキー導出構築物を利用した新しいキー導出階層
* Improved version negotiation.
* 改善されたバージョンのネゴシエーション。
* Optimized record layer encoding and thereby its size.
* 最適化されたレコード層エンコード、それによりサイズ。
* Added CID functionality.
* CID機能を追加しました。
* Sequence numbers are encrypted.
* シーケンス番号は暗号化されます。
This document defines several changes that optionally affect implementations of DTLS 1.2, including those which do not also support DTLS 1.3.
このドキュメントは、DTLS 1.2もサポートしていないものを含むDTLS 1.2の実装に影響を与えるいくつかの変更を定義します。
* A version downgrade protection mechanism as described in [TLS13], Section 4.1.3 and applying to DTLS as described in Section 5.3.
* [TLS13]、セクション4.1.3で説明されているバージョンダウングレード保護メカニズム、およびセクション5.3で説明されているDTLSへの適用。
* The updates described in [TLS13], Section 1.3.
* [TLS13]、セクション1.3で説明されている更新。
* The new compliance requirements described in [TLS13], Section 9.3.
* [TLS13]、セクション9.3で説明されている新しいコンプライアンス要件。
IANA has allocated the content type value 26 in the "TLS ContentType" registry for the ACK message, defined in Section 7. The value for the "DTLS-OK" column is "Y". IANA has reserved the content type range 32-63 so that content types in this range are not allocated.
IANAは、セクション7で定義されているACKメッセージの「TLS ContentType」レジストリにコンテンツタイプ値26を割り当てました。「DTLS-OK」列の値は「Y」です。IANAはコンテンツタイプの範囲32-63を予約しているため、この範囲のコンテンツタイプが割り当てられません。
IANA has allocated value 52 for the "too_many_cids_requested" alert in the "TLS Alerts" registry. The value for the "DTLS-OK" column is "Y".
IANAは、「TLSアラート」レジストリで「TOO_MANY_CIDS_REQUESTED」アラートに値52を割り当てました。「DTLS-OK」列の値は「Y」です。
IANA has allocated two values in the "TLS HandshakeType" registry, defined in [TLS13], for request_connection_id (9) and new_connection_id (10), as defined in this document. The value for the "DTLS-OK" column is "Y".
IANAは、[TLS13]で定義されている「TLS HandShaketype」レジストリに2つの値を割り当てました。これは、このドキュメントで定義されているように、[TLS13]で定義されています。「DTLS-OK」列の値は「Y」です。
IANA has added this RFC as a reference to the "TLS Cipher Suites" registry along with the following Note:
IANAはこのRFCを「TLS暗号スイート」レジストリへの参照として次の注意しています。
| Any TLS cipher suite that is specified for use with DTLS MUST
| define limits on the use of the associated AEAD function that
| preserves margins for both confidentiality and integrity, as
| specified in Section 4.5.3 of RFC 9147.
[CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, <https://www.rfc-editor.org/info/rfc8439>.
[Chacha] Nir、Y。およびA. Langley、「IETFプロトコル用のChacha20およびPoly1305」、RFC 8439、DOI 10.17487/RFC8439、2018年6月、<https://www.rfc-editor.org/info/rfc8439>
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.
[RFC0768] POSTEL、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、DOI 10.17487/RFC0768、1980年8月、<https://www.rfc-editor.org/info/rfc768>。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC0793] Postel、J.、 "Transmission Control Protocol"、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<https：//www.rfc-editor.org/info/rfc793>。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.
[RFC1191] Mogul、J.およびS.Theering、 "Path Mtu Discovery"、RFC 1191、DOI 10.17487 / RFC1191、1990年11月、<https：//www.rfc-editor.org/info/rfc1191>。
[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>。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、ed。、 "インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPV6）、STD 89、RFC 4443、DOI 10.17487/RFC4443、2006年3月、<https://www.rfc-editor.org/info/rfc4443>。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.
[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、DOI 10.17487/RFC4821、2007年3月、<https://www.rfc-editor.org/info/rfc4821>。
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>.
[RFC6298] Paxson、V.、Allman、M.、Chu、J.、およびM.Sargent、「コンピューティングTCPの再送信タイマー」、RFC 6298、DOI 10.17487 / RFC6298、2011年6月、<https：///www.rfc-editor.org/info/rfc6298>。
[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>。
[RFC9146] Rescorla, E., Ed., Tschofenig, H., Ed., Fossati, T., and A. Kraus, "Connection Identifier for DTLS 1.2", RFC 9146, DOI 10.17487/RFC9146, March 2022, <https://www.rfc-editor.org/info/rfc9146>.
[RFC9146] Rescorla、E.、Ed。、Tschofenig、H.、Ed。、Fossati、T.、およびA. Kraus、「DTLS 1.2の接続識別子」、RFC 9146、DOI 10.17487/RFC9146、2022年3月、<https：//www.rfc-editor.org/info/rfc9146>。
[TLS13] 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>.
[TLS13] RESCORLA、E。、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https：//www.rfc-editor.org/info/rfc8446>。
[AEAD-LIMITS] Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on AEAD Algorithms", Work in Progress, Internet-Draft, draft-irtf-cfrg-aead-limits-04, 7 March 2022, <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-aead-limits-04>.
[aead-limits]Günther、F.、Thomson、M.、およびC.A。木材、「AEDアルゴリズムの使用制限」、進行中の作業、インターネットドラフト、ドラフト-IRTF-CFRG-AEAD-LIMITS-04,24,722、<https://datatracker.ietf.org/doc/html/draft-irf-cfrg-aead-limits-04>。
[AEBounds] Luykx, A. and K. Paterson, "Limits on Authenticated Encryption Use in TLS", 28 August 2017, <https://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.
[Aebounds] Luykx、A.およびK. Paterson、2017年8月28日、<https://www.isg.rhul.ac.uk/~kp/tls-aebounds.pdf>。
[CCM-ANALYSIS] Jonsson, J., "On the Security of CTR + CBC-MAC", Selected Areas in Cryptography pp. 76-93, DOI 10.1007/3-540-36492-7_7, February 2003, <https://doi.org/10.1007/3-540-36492-7_7>.
[CCM-Analysis] Jonsson、J.、「CTR CBC-MACのセキュリティについて」、暗号PPの選択領域。76-93、DOI 10.1007 / 3-540-36492-7_7、2003年2月、<https：//doi.org/10.1007/3-540-36492-7_7>。
[DEPRECATE] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, <https://www.rfc-editor.org/info/rfc8996>.
[廃止] MoriArty、K.およびS. Farrell、「非推奨TLS 1.0およびTLS 1.1」、BCP 195、RFC 8996、DOI 10.17487 / RFC8996、2021年3月、<https：//www.rfc-editor.org/info/RFC8996>。
[IOT-PROFILE] Tschofenig, H. and T. Fossati, "TLS/DTLS 1.3 Profiles for the Internet of Things", Work in Progress, Internet-Draft, draft-ietf-uta-tls13-iot-profile-04, 7 March 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-uta-tls13-iot-profile-04>.
[IoT-Profile] Tschofenig、H。and T. Fossati、「TLS/DTLS 1.3モノのインターネットのプロファイル」、進行中の作業、インターネットドラフト、ドラフト-ITA-TLS13-ot-Profile-04、72022年3月、<https://datatracker.ietf.org/doc/html/draft-ietf-uta-tls13-iot-profile-04>。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, DOI 10.17487/RFC2522, March 1999, <https://www.rfc-editor.org/info/rfc2522>.
[RFC2522] Karn、P。and W. Simpson、「Photuris：Session-Key Management Protocol」、RFC 2522、DOI 10.17487/RFC2522、1999年3月、<https://www.rfc-editor.org/info/rfc2522>。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、DOI 10.17487 / RFC4303、2005年12月、<https：//www.rfc-editor.org/info/rfc4303>。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <https://www.rfc-editor.org/info/rfc4340>.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram混雑制御プロトコル（DCCP）」、RFC 4340、DOI 10.17487/RFC4340、2006年3月、<https：//www.rfc-editor。org/info/rfc4340>。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, DOI 10.17487/RFC4346, April 2006, <https://www.rfc-editor.org/info/rfc4346>.
[RFC4346] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.1」、RFC 4346、DOI 10.17487/RFC4346、2006年4月、<https://www.rfc-editor.org/info/RFC4346>。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, <https://www.rfc-editor.org/info/rfc4347>.
[RFC4347] Rescorla、E。およびN. Modadugu、「データグラム輸送層セキュリティ」、RFC 4347、DOI 10.17487/RFC4347、2006年4月、<https://www.rfc-editor.org/info/rfc4347>
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.
[RFC4960] Stewart、R.、ed。、「Stream Control Transmission Protocol」、RFC 4960、DOI 10.17487/RFC4960、2007年9月、<https://www.rfc-editor.org/info/rfc4960>。
[RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", RFC 5238, DOI 10.17487/RFC5238, May 2008, <https://www.rfc-editor.org/info/rfc5238>.
[RFC5238] Phelan、T。、「データグラム輸送層セキュリティ（DTLS）データグラム混雑制御プロトコル（DCCP）上のセキュリティ（DCCP）」、RFC 5238、DOI 10.17487/RFC5238、2008年5月、<https://www.rfc-editor.org/info/rfc5238>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T.およびE. Rescorla、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<https：//www.rfc-editor.org/info/ RFC5246>。
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, <https://www.rfc-editor.org/info/rfc5763>.
[RFC5763] Fischl、J.、Tschofenig、H.、およびE. Rescorla、「データグラムトランスポート層セキュリティ（DTLS）」、RFC 5763、DOI 10.17487 /を使用したセキュリティコンテキスト（SRTP）セキュリティコンテキストを確立するためのフレームワーク。RFC5763、2010年5月、<https：//www.rfc-editor.org/info/rfc5763>。
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, <https://www.rfc-editor.org/info/rfc5764>.
[RFC5764] MCGREW、D.およびE. RESCORLA、セキュアリアルタイムトランスポートプロトコル（SRTP） "、RFC 5764、DOI 10.17487 / RFC5764、2010年5月、<HTTPS）//www.rfc-editor.org/info/rfc5764>。
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.
[RFC6066]イーストレイク3RD、D.、「トランスポートレイヤセキュリティ（TLS）拡張：拡張定義」、RFC 6066、DOI 10.17487 / RFC6066、2011年1月、<https：//ww.rfc-editor.org/info/rfc6066>。
[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>
[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, <https://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月、<https://www.rfc-editor.org/info/rfc7296>。
[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, <https://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月、<https://www.rfc-editor.org/info/rfc7525>。
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security (TLS) Cached Information Extension", RFC 7924, DOI 10.17487/RFC7924, July 2016, <https://www.rfc-editor.org/info/rfc7924>.
[RFC7924] Santesson、S。およびH. Tschofenig、「輸送層のセキュリティ（TLS）キャッシュ情報拡張」、RFC 7924、DOI 10.17487/RFC7924、2016年7月、<https：//www.rfc-editor.org/info/RFC7924>。
[RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)", RFC 7983, DOI 10.17487/RFC7983, September 2016, <https://www.rfc-editor.org/info/rfc7983>.
[RFC7983] Petit-Huguenin、M。and G. Salgueiro、「データグラム輸送層セキュリティ（DTLS）の安全なリアルタイム輸送プロトコル（SRTP）拡張のためのマルチプレックススキームの更新」、RFC 7983、DOI 10.17487/RFC7983、2016年9月、<https://www.rfc-editor.org/info/rfc7983>。
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.
[RFC8201] McCann、J.、Theering、S.、Mogul、J.、およびR. Hinden、Ed。、「PATH MTUディスカバリー用IPバージョン6」、STD 87、RFC 8201、DOI 10.17487 / RFC8201、2017年7月、<https://www.rfc-editor.org/info/rfc8201>。
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>.
[RFC8445]ケラネン、A.、Holmberg、C.、J.Rosenberg、「インタラクティブ接続確立（氷）：ネットワークアドレストランスレータ（NAT）トラバースのためのプロトコル、RFC 8445、DOI 10.17487 / RFC8445、2018年7月、<https://www.rfc-editor.org/info/rfc8445>。
[RFC8879] Ghedini, A. and V. Vasiliev, "TLS Certificate Compression", RFC 8879, DOI 10.17487/RFC8879, December 2020, <https://www.rfc-editor.org/info/rfc8879>.
[RFC8879] Ghedini、A。およびV. Vasiliev、「TLS証明書圧縮」、RFC 8879、DOI 10.17487/RFC8879、2020年12月、<https://www.rfc-editor.org/info/rfc8879>
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.
[RFC9000] Iyengar、J.、ED。M. Thomson、ED。、「QUIC：UDPベースの多重化および安全な輸送」、RFC 9000、DOI 10.17487 / RFC9000、2021年5月、<https：//www.rfc-editor.org/info/rfc9000>。
[RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, May 2021, <https://www.rfc-editor.org/info/rfc9002>.
[RFC9002] Iyengar、J.、Ed。I.Swett、Ed。、「QUIC損失検出および輻輳制御」、RFC 9002、DOI 10.17487 / RFC9002、2021年5月、<https：//www.rfc-editor.org/info/rfc9002>。
[ROBUST] Fischlin, M., Günther, F., and C. Janson, "Robust Channels: Handling Unreliable Networks in the Record Layers of QUIC and DTLS 1.3", received 15 June 2020, last revised 22 February 2021, <https://eprint.iacr.org/2020/718>.
[堅牢] Fischlin、M.、Günther、F.、およびC. JaSanson、「堅牢なチャンネル：QUICおよびDTLS 1.3の記録層の信頼性の低いネットワークの取り扱い」、2020年6月15日、最後の改訂2021年2月22日、<https：///eprint.iacr.org/2020/718>。
[TLS-ECH] Rescorla, E., Oku, K., Sullivan, N., and C.A. Wood, "TLS Encrypted Client Hello", Work in Progress, Internet-Draft, draft-ietf-tls-esni-14, 13 February 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-14>.
[TLS-ECH] Rescorla、E.、Oku、K.、Sullivan、N。、およびC.A.wood、「TLS暗号化クライアントハロー」、作業中のインターネットドラフト、ドラフト-TLS-ESNI-14、2022年2月13日、<https://datatracker.ietf.org/doc/html/draft-ietf-TLS-ESNI-14>。
This section provides the normative protocol types and constants definitions.
このセクションでは、規範的なプロトコルタイプと定数定義を提供します。
struct {
ContentType type;
ProtocolVersion legacy_record_version;
uint16 epoch = 0
uint48 sequence_number;
uint16 length;
opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext;
struct {
opaque content[DTLSPlaintext.length];
ContentType type;
uint8 zeros[length_of_padding];
} DTLSInnerPlaintext;
struct {
opaque unified_hdr[variable];
opaque encrypted_record[length];
} DTLSCiphertext;
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0|0|1|C|S|L|E E|
+-+-+-+-+-+-+-+-+
| Connection ID | Legend:
| (if any, |
/ length as / C - Connection ID (CID) present
| negotiated) | S - Sequence number length
+-+-+-+-+-+-+-+-+ L - Length present
| 8 or 16 bit | E - Epoch
|Sequence Number|
+-+-+-+-+-+-+-+-+
| 16 bit Length |
| (if present) |
+-+-+-+-+-+-+-+-+
struct {
uint64 epoch;
uint64 sequence_number;
} RecordNumber;
enum {
hello_request_RESERVED(0),
client_hello(1),
server_hello(2),
hello_verify_request_RESERVED(3),
new_session_ticket(4),
end_of_early_data(5),
hello_retry_request_RESERVED(6),
encrypted_extensions(8),
request_connection_id(9), /* New */
new_connection_id(10), /* New */
certificate(11),
server_key_exchange_RESERVED(12),
certificate_request(13),
server_hello_done_RESERVED(14),
certificate_verify(15),
client_key_exchange_RESERVED(16),
finished(20),
certificate_url_RESERVED(21),
certificate_status_RESERVED(22),
supplemental_data_RESERVED(23),
key_update(24),
message_hash(254),
(255)
} HandshakeType;
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */
uint16 message_seq; /* DTLS-required field */
uint24 fragment_offset; /* DTLS-required field */
uint24 fragment_length; /* DTLS-required field */
select (msg_type) {
case client_hello: ClientHello;
case server_hello: ServerHello;
case end_of_early_data: EndOfEarlyData;
case encrypted_extensions: EncryptedExtensions;
case certificate_request: CertificateRequest;
case certificate: Certificate;
case certificate_verify: CertificateVerify;
case finished: Finished;
case new_session_ticket: NewSessionTicket;
case key_update: KeyUpdate;
case request_connection_id: RequestConnectionId;
case new_connection_id: NewConnectionId;
} body;
} Handshake;
uint16 ProtocolVersion;
opaque Random[32];
uint8 CipherSuite[2]; /* Cryptographic suite selector */
struct {
ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2
Random random;
opaque legacy_session_id<0..32>;
opaque legacy_cookie<0..2^8-1>; // DTLS
CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>;
} ClientHello;
struct {
RecordNumber record_numbers<0..2^16-1>;
} ACK;
enum {
cid_immediate(0), cid_spare(1), (255)
} ConnectionIdUsage;
opaque ConnectionId<0..2^8-1>;
struct {
ConnectionId cids<0..2^16-1>;
ConnectionIdUsage usage;
} NewConnectionId;
struct {
uint8 num_cids;
} RequestConnectionId;
TLS [TLS13] and [AEBounds] do not specify limits on key usage for AEAD_AES_128_CCM. However, any AEAD that is used with DTLS requires limits on use that ensure that both confidentiality and integrity are preserved. This section documents that analysis for AEAD_AES_128_CCM.
TLS [TLS13]および[Aebounds] AEAD_AES_128_CCMのキー使用法の制限を指定しないでください。しかしながら、DTLSで使用されるAEDは、機密性と完全性の両方が保存されていることを保証する使用時の制限が必要です。このセクションでは、AED_AES_128_CCMの分析を文書化します。
[CCM-ANALYSIS] is used as the basis of this analysis. The results of that analysis are used to derive usage limits that are based on those chosen in [TLS13].
[CCM分析]は、この分析の基礎として使用されます。その分析の結果は、[TLS13]で選択されたものに基づいた使用制限を導き出すために使用されます。
This analysis uses symbols for multiplication (*), division (/), and exponentiation (^), plus parentheses for establishing precedence. The following symbols are also used:
この分析では、乗算（*）、ディビジョン（/）、および余分なもの（^）、プラレンスを確立するための括弧の記号を使用します。以下の記号も使用されます。
t: The size of the authentication tag in bits. For this cipher, t is 128.
T：ビットの認証タグのサイズ。この暗号では、tは128です。
n: The size of the block function in bits. For this cipher, n is 128.
N：ビット内のブロック関数のサイズ。この暗号では、nは128です。
l: The number of blocks in each packet (see below).
L：各パケットのブロック数（以下を参照）。
q: The number of genuine packets created and protected by endpoints. This value is the bound on the number of packets that can be protected before updating keys.
Q：エンドポイントによって作成および保護された本物のパケットの数。この値は、キーを更新する前に保護できるパケットの数にバインドされています。
v: The number of forged packets that endpoints will accept. This value is the bound on the number of forged packets that an endpoint can reject before updating keys.
v：エンドポイントが受け入れる鍛造パケットの数。この値は、キーを更新する前にエンドポイントが拒否できる鍛造パケットの数のバインドです。
The analysis of AEAD_AES_128_CCM relies on a count of the number of block operations involved in producing each message. For simplicity, and to match the analysis of other AEAD functions in [AEBounds], this analysis assumes a packet length of 2^10 blocks and a packet size limit of 2^14 bytes.
AEAD_AES_128_CCMの分析は、各メッセージの作成に関与するブロック操作の数のカウントに依存しています。簡単にし、[Aebounds]の他のAEAD関数の分析と一致するために、この分析では、2^10ブロックのパケット長と2^14バイトのパケットサイズ制限を想定しています。
For AEAD_AES_128_CCM, the total number of block cipher operations is the sum of: the length of the associated data in blocks, the length of the ciphertext in blocks, and the length of the plaintext in blocks, plus 1. In this analysis, this is simplified to a value of twice the maximum length of a record in blocks (that is, 2l = 2^11). This simplification is based on the associated data being limited to one block.
AEAD_AES_128_CCMの場合、ブロック暗号操作の総数は、ブロック内の関連データの長さ、ブロック内の暗号文の長さ、およびブロックの平文の長さの合計です。この分析では、これはこれです。ブロック内のレコードの最大長の2倍の値（つまり、2L = 2^11）に簡素化されます。この単純化は、関連するデータが1つのブロックに制限されていることに基づいています。
For confidentiality, Theorem 2 in [CCM-ANALYSIS] establishes that an attacker gains a distinguishing advantage over an ideal pseudorandom permutation (PRP) of no more than:
機密性のために、[CCM分析]の定理2は、攻撃者が以下の理想的な擬似ランダム順列（PRP）よりも際立った利点を獲得することを確立しています。
(2l * q)^2 / 2^n
For a target advantage in a single-key setting of 2^-60, which matches that used by TLS 1.3, as summarized in [AEAD-LIMITS], this results in the relation:
[AEAD-limits]で要約されているように、TLS 1.3で使用されているものと一致する2^-60のシングルキー設定でのターゲットの利点の場合、これは関係になります。
q <= 2^23
That is, endpoints cannot protect more than 2^23 packets with the same set of keys without causing an attacker to gain a larger advantage than the target of 2^-60.
すなわち、エンドポイントは、攻撃者が2 ^ -60の目標よりも大きな利点を得ることなく、同じキーを持つ2 ^ 23パケットを超える2 ^ 23パケットを保護することはできません。
For integrity, Theorem 1 in [CCM-ANALYSIS] establishes that an attacker gains an advantage over an ideal PRP of no more than:
整合性のために、[CCM分析]の定理1は、攻撃者が理想的なPRPよりも優位性を獲得することを確立しています。
v / 2^t + (2l * (v + q))^2 / 2^n
The goal is to limit this advantage to 2^-57, to match the target in TLS 1.3, as summarized in [AEAD-LIMITS]. As t and n are both 128, the first term is negligible relative to the second, so that term can be removed without a significant effect on the result. This produces the relation:
目標は、[aead-limits]で要約されているように、TLS 1.3のターゲットと一致するように、この利点を2^-57に制限することです。TとNは両方とも128であるため、最初の用語は2番目の項に対しては無視できます。そのため、結果に大きな影響を与えることなく、その用語を削除できます。これにより、関係が生成されます。
v + q <= 2^24.5
Using the previously established value of 2^23 for q and rounding, this leads to an upper limit on v of 2^23.5. That is, endpoints cannot attempt to authenticate more than 2^23.5 packets with the same set of keys without causing an attacker to gain a larger advantage than the target of 2^-57.
Qおよび丸めで以前に確立された値2^23を使用して、これにより2^23.5のVの上限が生じます。つまり、エンドポイントは、攻撃者に2^-57のターゲットよりも大きな利点を得ることなく、同じキーのセットで2^23.5以上のパケットを認証しようとすることはできません。
The TLS_AES_128_CCM_8_SHA256 cipher suite uses the AEAD_AES_128_CCM_8 function, which uses a short authentication tag (that is, t=64).
TLS_AES_128_CCM_8_SHA256 CIPHES SUITEは、AEAD_AES_128_CCM_8関数を使用します。これは、短い認証タグ（つまり、t = 64）を使用します。
The confidentiality limits of AEAD_AES_128_CCM_8 are the same as those for AEAD_AES_128_CCM, as this does not depend on the tag length; see Appendix B.1.
AEAD_AES_128_CCM_8の機密性の制限は、タグの長さに依存しないため、AEAD_AES_128_CCMの機密制限と同じです。付録B.1を参照してください。
The shorter tag length of 64 bits means that the simplification used in Appendix B.2 does not apply to AEAD_AES_128_CCM_8. If the goal is to preserve the same margins as other cipher suites, then the limit on forgeries is largely dictated by the first term of the advantage formula:
64ビットの短いタグ長は、付録B.2で使用されている単純化がAEAD_AES_128_CCM_8には適用されないことを意味します。目標が他の暗号スイートと同じマージンを保存することである場合、フォーメーリーの制限は、利点の最初の期間によって主に決定されます。
v <= 2^7
As this represents attempts that fail authentication, applying this limit might be feasible in some environments. However, applying this limit in an implementation intended for general use exposes connections to an inexpensive denial-of-service attack.
これは認証に失敗する試みを表しているため、この制限を適用することは、一部の環境で実行可能である可能性があります。ただし、一般的な使用を目的とした実装にこの制限を適用すると、接続が安価なサービス拒否攻撃にさらされます。
This analysis supports the view that TLS_AES_128_CCM_8_SHA256 is not suitable for general use. Specifically, TLS_AES_128_CCM_8_SHA256 cannot be used without additional measures to prevent forgery of records, or to mitigate the effect of forgeries. This might require understanding the constraints that exist in a particular deployment or application. For instance, it might be possible to set a different target for the advantage an attacker gains based on an understanding of the constraints imposed on a specific usage of DTLS.
この分析は、TLS_AES_128_CCM_8_SHA256が一般的な使用に適していないという見解をサポートしています。具体的には、TLS_AES_128_CCM_8_SHA256は、記録の偽造を防止したり、偽造の効果を軽減するための追加の措置なしには使用できません。これには、特定の展開またはアプリケーションに存在する制約を理解する必要がある場合があります。たとえば、DTLの特定の使用法に課される制約の理解に基づいて、攻撃者が得る利点のために異なるターゲットを設定することが可能かもしれません。
In addition to the aspects of TLS that have been a source of interoperability and security problems (Appendix C.3 of [TLS13]), DTLS presents a few new potential sources of issues, noted here.
相互運用性とセキュリティ問題の発生源となっているTLSの側面に加えて（[TLS13]の付録C.3）、DTLはここで述べたいくつかの新しい潜在的な問題源を提示します。
* Do you correctly handle messages received from multiple epochs during a key transition? This includes locating the correct key as well as performing replay detection, if enabled.
* キートランジション中に複数のエポックから受信したメッセージを正しく処理しますか？これには、正しいキーを見つけるとともに、リプレイ検出を実行することが含まれます。
* Do you retransmit handshake messages that are not (implicitly or explicitly) acknowledged (Section 5.8)?
* （暗黙的または明示的に）認められていない握手メッセージを再送信しますか（セクション5.8）？
* Do you correctly handle handshake message fragments received, including when they are out of order?
* 受信した握手の断片を正しく処理しますか？
* Do you correctly handle handshake messages received out of order? This may include either buffering or discarding them.
* あなたは順不同で受信したハンドシェイクメッセージを正しく処理しますか？これにはバッファリングまたは廃棄することが含まれます。
* Do you limit how much data you send to a peer before its address is validated?
* アドレスが検証される前に、ピアに送信するデータ量を制限しますか？
* Do you verify that the explicit record length is contained within the datagram in which it is contained?
* 明示的なレコード長が含まれているデータグラムに含まれていることを確認しますか？
Contributors
貢献者
Many people have contributed to previous DTLS versions, and they are acknowledged in prior versions of DTLS specifications or in the referenced specifications.
多くの人々が以前のDTLSバージョンに貢献しており、DTLS仕様の以前のバージョンまたは参照仕様で認められています。
Hanno Becker Arm Limited Email: Hanno.Becker@arm.com
Hanno Becker Arm Limited Eメール：hanno.becker@arm.com
David Benjamin Google Email: davidben@google.com
David Benjamin Google Eメール：davidben@google.com
Thomas Fossati Arm Limited Email: thomas.fossati@arm.com
Thomas Fossati Arm Limited Eメール：Thomas.fossati@arm.com
Tobias Gondrom Huawei Email: tobias.gondrom@gondrom.org
Tobias Gondrom Huawei Eメール：tobias.gondrom@gondrom.org.
Felix Günther ETH Zurich Email: mail@felixguenther.info
FelixGüntherETHZurich Email：mail@felixguenther.info
Benjamin Kaduk Akamai Technologies Email: kaduk@mit.edu
Benjamin Kaduk Akamai Technologies Eメール：kaduk@mit.edu.
Ilari Liusvaara Independent Email: ilariliusvaara@welho.com
ilari liusvaara独立電子メール：ilariliusvaara@welho.com
Martin Thomson Mozilla Email: martin.thomson@gmail.com
Martin Thomson Mozillaメール：Martin.Thomson@gmail.com
Christopher A. Wood Cloudflare Email: caw@heapingbits.net
Christopher A. Wood CloudFlare Eメール：caw@heapingbits.net
Yin Xinxing Huawei Email: yinxinxing@huawei.com
Yin Xinxing Huawei Email：yinxinxing@huawei.com
The sequence number encryption concept is taken from QUIC [RFC9000]. We would like to thank the authors of RFC 9000 for their work. Felix Günther and Martin Thomson contributed the analysis in Appendix B. We would like to thank Jonathan Hammell, Bernard Aboba, and Andy Cunningham for their review comments.
シーケンス番号暗号化の概念は、QUIC [RFC9000]から取得されます。私たちは彼らの仕事のためにRFC 9000の著者に感謝したいと思います。FelixGüntherとMartin Thomsonは付録Bで分析を貢献しました。
Additionally, we would like to thank the IESG members for their review comments: Martin Duke, Erik Kline, Francesca Palombini, Lars Eggert, Zaheduzzaman Sarker, John Scudder, Éric Vyncke, Robert Wilton, Roman Danyliw, Benjamin Kaduk, Murray Kucherawy, Martin Vigoureux, and Alvaro Retana.
さらに、私たちは彼らのレビューのためにIESGメンバーに感謝します、Alvaro Retana。
Authors' Addresses
著者の住所
Eric Rescorla Mozilla Email: ekr@rtfm.com
Eric Rescorla Mozillaメール：ekr@rtfm.com
Hannes Tschofenig Arm Limited Email: hannes.tschofenig@arm.com
Hannes Tschofenig ARM Limited Email：hannes.tchofenig@arm.com
Nagendra Modadugu Google, Inc. Email: nagendra@cs.stanford.edu
Nagendra Modadugu Google、Inc。Eメール：nagendra@cs.stanford.edu.