[要約] RFC 8446は、インターネット標準トラックの文書であり、Transport Layer Security (TLS) プロトコルのバージョン1.3を定義しています。このバージョンは、以前のバージョンに比べてセキュリティが強化され、接続の速度が向上しています。TLS 1.3は、ウェブブラウジング、電子メール、インスタントメッセージングなど、インターネット上での安全な通信を提供するために広く利用されています。重要な関連RFCには、RFC 8447（TLS 1.3のレジストリ更新）やRFC 8701（TLS 1.3の実験的な機能をテストするためのフレームワーク）があります。
Internet Engineering Task Force (IETF) E. Rescorla
Request for Comments: 8446 Mozilla
Obsoletes: 5077, 5246, 6961 August 2018
Updates: 5705, 6066
Category: Standards Track
ISSN: 2070-1721
The Transport Layer Security (TLS) Protocol Version 1.3
Abstract
概要
This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.
このドキュメントでは、Transport Layer Security（TLS）プロトコルのバージョン1.3を指定しています。 TLSを使用すると、クライアント/サーバーアプリケーションは、盗聴、改ざん、メッセージの偽造を防ぐように設計された方法で、インターネット経由で通信できます。
This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.
このドキュメントは、RFC 5705および6066を更新し、RFC 5077、5246、および6961を廃止します。このドキュメントは、TLS 1.2実装の新しい要件も指定しています。
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.
このドキュメントは、Internet Engineering Task Force（IETF）の製品です。 IETFコミュニティのコンセンサスを表しています。 これは公開レビューを受けており、Internet Engineering Steering Group（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/rfc8446.
このドキュメントの現在のステータス、エラッタ、およびフィードバックに関する情報は、https：//www.rfc-editor.org/info/rfc8446で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、この文書の発行日に有効なBCP 78およびIETF文書に関するIETFトラストの法的条項（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているので、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストを含める必要があり、Simplified BSD Licenseに記載されている保証なしで提供されます。
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標準プロセス外で変更されず、その派生物はIETF標準プロセス外で作成されません。RFCとしての公開用にフォーマットするか、英語以外の言語に翻訳する場合を除きます。
Table of Contents
目次
1. Introduction ....................................................6
1.1. Conventions and Terminology ................................7
1.2. Major Differences from TLS 1.2 .............................8
1.3. Updates Affecting TLS 1.2 ..................................9
2. Protocol Overview ..............................................10
2.1. Incorrect DHE Share .......................................14
2.2. Resumption and Pre-Shared Key (PSK) .......................15
2.3. 0-RTT Data ................................................17
3. Presentation Language ..........................................19
3.1. Basic Block Size ..........................................19
3.2. Miscellaneous .............................................20
3.3. Numbers ...................................................20
3.4. Vectors ...................................................20
3.5. Enumerateds ...............................................21
3.6. Constructed Types .........................................22
3.7. Constants .................................................23
3.8. Variants ..................................................23
4. Handshake Protocol .............................................24
4.1. Key Exchange Messages .....................................25
4.1.1. Cryptographic Negotiation ..........................26
4.1.2. Client Hello .......................................27
4.1.3. Server Hello .......................................31
4.1.4. Hello Retry Request ................................33
4.2. Extensions ................................................35
4.2.1. Supported Versions .................................39
4.2.2. Cookie .............................................40
4.2.3. Signature Algorithms ...............................41
4.2.4. Certificate Authorities ............................45
4.2.5. OID Filters ........................................45
4.2.6. Post-Handshake Client Authentication ...............47
4.2.7. Supported Groups ...................................47
4.2.8. Key Share ..........................................48
4.2.9. Pre-Shared Key Exchange Modes ......................51
4.2.10. Early Data Indication .............................52
4.2.11. Pre-Shared Key Extension ..........................55
4.3. Server Parameters .........................................59
4.3.1. Encrypted Extensions ...............................60
4.3.2. Certificate Request ................................60
4.4. Authentication Messages ...................................61
4.4.1. The Transcript Hash ................................63
4.4.2. Certificate ........................................64
4.4.3. Certificate Verify .................................69
4.4.4. Finished ...........................................71
4.5. End of Early Data .........................................72
4.6. Post-Handshake Messages ...................................73
4.6.1. New Session Ticket Message .........................73
4.6.2. Post-Handshake Authentication ......................75
4.6.3. Key and Initialization Vector Update ...............76
5. Record Protocol ................................................77
5.1. Record Layer ..............................................78
5.2. Record Payload Protection .................................80
5.3. Per-Record Nonce ..........................................82
5.4. Record Padding ............................................83
5.5. Limits on Key Usage .......................................84
6. Alert Protocol .................................................85
6.1. Closure Alerts ............................................87
6.2. Error Alerts ..............................................88
7. Cryptographic Computations .....................................90
7.1. Key Schedule ..............................................91
7.2. Updating Traffic Secrets ..................................94
7.3. Traffic Key Calculation ...................................95
7.4. (EC)DHE Shared Secret Calculation .........................95
7.4.1. Finite Field Diffie-Hellman ........................95
7.4.2. Elliptic Curve Diffie-Hellman ......................96
7.5. Exporters .................................................97
8. 0-RTT and Anti-Replay ..........................................98
8.1. Single-Use Tickets ........................................99
8.2. Client Hello Recording ....................................99
8.3. Freshness Checks .........................................101
9. Compliance Requirements .......................................102
9.1. Mandatory-to-Implement Cipher Suites .....................102
9.2. Mandatory-to-Implement Extensions ........................103
9.3. Protocol Invariants ......................................104
10. Security Considerations ......................................106
11. IANA Considerations ..........................................106
12. References ...................................................109
12.1. Normative References ....................................109
12.2. Informative References ..................................112
Appendix A. State Machine ........................................120
A.1. Client ....................................................120
A.2. Server ....................................................121
Appendix B. Protocol Data Structures and Constant Values .........122
B.1. Record Layer ..............................................122
B.2. Alert Messages ............................................123
B.3. Handshake Protocol ........................................124
B.3.1. Key Exchange Messages .................................125
B.3.2. Server Parameters Messages ............................131
B.3.3. Authentication Messages ...............................132
B.3.4. Ticket Establishment ..................................132
B.3.5. Updating Keys .........................................133
B.4. Cipher Suites .............................................133
Appendix C. Implementation Notes .................................134
C.1. Random Number Generation and Seeding ......................134
C.2. Certificates and Authentication ...........................135
C.3. Implementation Pitfalls ...................................135
C.4. Client Tracking Prevention ................................137
C.5. Unauthenticated Operation .................................137
Appendix D. Backward Compatibility ...............................138
D.1. Negotiating with an Older Server ..........................139
D.2. Negotiating with an Older Client ..........................139
D.3. 0-RTT Backward Compatibility ..............................140
D.4. Middlebox Compatibility Mode ..............................140
D.5. Security Restrictions Related to Backward Compatibility ...141
Appendix E. Overview of Security Properties ......................142
E.1. Handshake .................................................142
E.1.1. Key Derivation and HKDF ...............................145
E.1.2. Client Authentication .................................146
E.1.3. 0-RTT .................................................146
E.1.4. Exporter Independence .................................146
E.1.5. Post-Compromise Security ..............................146
E.1.6. External References ...................................147
E.2. Record Layer ..............................................147
E.2.1. External References ...................................148
E.3. Traffic Analysis ..........................................148
E.4. Side-Channel Attacks ......................................149
E.5. Replay Attacks on 0-RTT ...................................150
E.5.1. Replay and Exporters ..................................151
E.6. PSK Identity Exposure .....................................152
E.7. Sharing PSKs ..............................................152
E.8. Attacks on Static RSA .....................................152
Contributors .....................................................153
Author's Address .................................................160
The primary goal of TLS is to provide a secure channel between two communicating peers; the only requirement from the underlying transport is a reliable, in-order data stream. Specifically, the secure channel should provide the following properties:
TLSの主な目標は、通信する2つのピア間に安全なチャネルを提供することです。 基礎となるトランスポートからの唯一の要件は、信頼性のある順序どおりのデータストリームです。 具体的には、セキュアチャネルは次のプロパティを提供する必要があります。
- Authentication: The server side of the channel is always authenticated; the client side is optionally authenticated. Authentication can happen via asymmetric cryptography (e.g., RSA [RSA], the Elliptic Curve Digital Signature Algorithm (ECDSA) [ECDSA], or the Edwards-Curve Digital Signature Algorithm (EdDSA) [RFC8032]) or a symmetric pre-shared key (PSK).
- 認証：チャネルのサーバー側は常に認証されます。 クライアント側はオプションで認証されます。 認証は、非対称暗号化（RSA [RSA]、楕円曲線デジタル署名アルゴリズム（ECDSA）[ECDSA]、またはEdwards-Curveデジタル署名アルゴリズム（EdDSA）[RFC8032]）または対称事前共有キー（たとえば PSK）。
- Confidentiality: Data sent over the channel after establishment is only visible to the endpoints. TLS does not hide the length of the data it transmits, though endpoints are able to pad TLS records in order to obscure lengths and improve protection against traffic analysis techniques.
- 機密性：確立後にチャネルを介して送信されるデータは、エンドポイントにのみ表示されます。 TLSは、送信するデータの長さを隠しませんが、エンドポイントは長さを隠してトラフィック分析技術に対する保護を改善するためにTLSレコードを埋め込むことができます。
- Integrity: Data sent over the channel after establishment cannot be modified by attackers without detection.
- 整合性：確立後にチャネルを介して送信されたデータは、検出されない限り攻撃者によって変更できません。
These properties should be true even in the face of an attacker who has complete control of the network, as described in [RFC3552]. See Appendix E for a more complete statement of the relevant security properties.
[RFC3552]で説明されているように、これらのプロパティは、ネットワークを完全に制御している攻撃者に直面した場合でも正しいはずです。 関連するセキュリティプロパティのより完全な記述については、付録Eを参照してください。
TLS consists of two primary components:
TLSは、2つの主要なコンポーネントで構成されています。
- A handshake protocol (Section 4) that authenticates the communicating parties, negotiates cryptographic modes and parameters, and establishes shared keying material. The handshake protocol is designed to resist tampering; an active attacker should not be able to force the peers to negotiate different parameters than they would if the connection were not under attack.
- 通信相手を認証し、暗号化モードとパラメーターをネゴシエートし、共有キー情報を確立するハンドシェイクプロトコル（セクション4）。 ハンドシェイクプロトコルは、改ざんに耐えるように設計されています。 アクティブな攻撃者は、接続が攻撃を受けていない場合にピアとは異なるパラメータをネゴシエートさせることはできません。
- A record protocol (Section 5) that uses the parameters established by the handshake protocol to protect traffic between the communicating peers. The record protocol divides traffic up into a series of records, each of which is independently protected using the traffic keys.
- ハンドシェイクプロトコルによって確立されたパラメータを使用して、通信するピア間のトラフィックを保護するレコードプロトコル（セクション5）。 レコードプロトコルは、トラフィックを一連のレコードに分割します。各レコードは、トラフィックキーを使用して個別に保護されます。
TLS is application protocol independent; higher-level protocols can layer on top of TLS transparently. The TLS standard, however, does not specify how protocols add security with TLS; how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and implementors of protocols that run on top of TLS.
TLSはアプリケーションプロトコルに依存しません。 高レベルのプロトコルは、TLSの上に透過的にレイヤリングできます。 ただし、TLS標準は、プロトコルがTLSでセキュリティを追加する方法を指定していません。 TLSハンドシェイクの開始方法と、交換された認証証明書の解釈方法は、TLSの上で実行されるプロトコルの設計者と実装者の判断に委ねられます。
This document defines TLS version 1.3. While TLS 1.3 is not directly compatible with previous versions, all versions of TLS incorporate a versioning mechanism which allows clients and servers to interoperably negotiate a common version if one is supported by both peers.
このドキュメントでは、TLSバージョン1.3を定義しています。 TLS 1.3は以前のバージョンと直接の互換性はありませんが、TLSのすべてのバージョンには、クライアントとサーバーが両方のピアでサポートされている場合に共通バージョンを相互運用可能にネゴシエートできるバージョン管理メカニズムが組み込まれています。
This document supersedes and obsoletes previous versions of TLS, including version 1.2 [RFC5246]. It also obsoletes the TLS ticket mechanism defined in [RFC5077] and replaces it with the mechanism defined in Section 2.2. Because TLS 1.3 changes the way keys are derived, it updates [RFC5705] as described in Section 7.5. It also changes how Online Certificate Status Protocol (OCSP) messages are carried and therefore updates [RFC6066] and obsoletes [RFC6961] as described in Section 4.4.2.1.
このドキュメントは、バージョン1.2 [RFC5246]を含む、TLSの以前のバージョンに取って代わります。 また、[RFC5077]で定義されたTLSチケットメカニズムを廃止し、セクション2.2で定義されたメカニズムに置き換えます。 TLS 1.3はキーの導出方法を変更するため、セクション7.5で説明されているように[RFC5705]を更新します。 また、オンライン証明書ステータスプロトコル（OCSP）メッセージの搬送方法も変更するため、セクション4.4.2.1で説明されているように[RFC6066]を更新し、[RFC6961]を廃止します。
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 TLS connection.
クライアント：TLS接続を開始するエンドポイント。
connection: A transport-layer connection between two endpoints.
接続：2つのエンドポイント間のトランスポート層接続。
endpoint: Either the client or server of the connection.
エンドポイント：接続のクライアントまたはサーバー。
handshake: An initial negotiation between client and server that establishes the parameters of their subsequent interactions within TLS.
ハンドシェイク：TLS内の後続の相互作用のパラメーターを確立するクライアントとサーバー間の最初のネゴシエーション。
peer: An endpoint. When discussing a particular endpoint, "peer" refers to the endpoint that is not the primary subject of discussion.
ピア：エンドポイント。 特定のエンドポイントについて議論するとき、「ピア」とは、議論の主要な主題ではないエンドポイントを指します。
receiver: An endpoint that is receiving records.
受信者：レコードを受信しているエンドポイント。
sender: An endpoint that is transmitting records.
送信者：レコードを送信しているエンドポイント。
server: The endpoint that did not initiate the TLS connection.
サーバー：TLS接続を開始しなかったエンドポイント。
The following is a list of the major functional differences between TLS 1.2 and TLS 1.3. It is not intended to be exhaustive, and there are many minor differences.
以下は、TLS 1.2とTLS 1.3の主な機能の違いのリストです。 網羅的であることは意図されておらず、多くの小さな違いがあります。
- The list of supported symmetric encryption algorithms has been pruned of all algorithms that are considered legacy. Those that remain are all Authenticated Encryption with Associated Data (AEAD) algorithms. The cipher suite concept has been changed to separate the authentication and key exchange mechanisms from the record protection algorithm (including secret key length) and a hash to be used with both the key derivation function and handshake message authentication code (MAC).
-サポートされている対称暗号化アルゴリズムのリストは、レガシーと見なされるすべてのアルゴリズムから削除されました。 残っているのは、すべて関連データを使用した認証暗号化（AEAD）アルゴリズムです。 暗号スイートの概念が変更され、認証とキー交換メカニズムをレコード保護アルゴリズム（秘密キーの長さを含む）およびキー派生機能とハンドシェイクメッセージ認証コード（MAC）の両方で使用されるハッシュから分離しました。
- A zero round-trip time (0-RTT) mode was added, saving a round trip at connection setup for some application data, at the cost of certain security properties.
- ゼロラウンドトリップタイム（0-RTT）モードが追加され、特定のセキュリティプロパティを犠牲にして、一部のアプリケーションデータの接続セットアップ時のラウンドトリップが節約されました。
- Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.
- 静的RSAおよびDiffie-Hellman暗号スイートが削除されました。 すべての公開鍵ベースの鍵交換メカニズムは、前方秘密を提供するようになりました。
- All handshake messages after the ServerHello are now encrypted. The newly introduced EncryptedExtensions message allows various extensions previously sent in the clear in the ServerHello to also enjoy confidentiality protection.
- ServerHello後のすべてのハンドシェイクメッセージが暗号化されます。 新しく導入されたEncryptedExtensionsメッセージにより、ServerHelloで以前に平文で送信されたさまざまな拡張機能も機密保護を享受できます。
- The key derivation functions have been redesigned. The new design allows easier analysis by cryptographers due to their improved key separation properties. The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is used as an underlying primitive.
- 主要な派生関数が再設計されました。 新しい設計により、鍵分離特性が改善されているため、暗号作成者による分析が容易になります。 HMACベースの抽出および拡張キー派生関数（HKDF）は、基になるプリミティブとして使用されます。
- The handshake state machine has been significantly restructured to be more consistent and to remove superfluous messages such as ChangeCipherSpec (except when needed for middlebox compatibility).
- ハンドシェイクステートマシンが大幅に再構築されて、一貫性が向上し、ChangeCipherSpecなどの不要なメッセージが削除されました（ミドルボックスの互換性に必要な場合を除く）。
- Elliptic curve algorithms are now in the base spec, and new signature algorithms, such as EdDSA, are included. TLS 1.3 removed point format negotiation in favor of a single point format for each curve.
- 現在、楕円曲線アルゴリズムは基本仕様に含まれており、EdDSAなどの新しい署名アルゴリズムが含まれています。 TLS 1.3は、各曲線の単一のポイント形式を支持して、ポイント形式のネゴシエーションを削除しました。
- Other cryptographic improvements were made, including changing the RSA padding to use the RSA Probabilistic Signature Scheme (RSASSA-PSS), and the removal of compression, the Digital Signature Algorithm (DSA), and custom Ephemeral Diffie-Hellman (DHE) groups.
- RSA確率的署名スキーム（RSASSA-PSS）を使用するためのRSAパディングの変更、圧縮の削除、デジタル署名アルゴリズム（DSA）、およびカスタムEphemeral Diffie-Hellman（DHE）グループを含む、その他の暗号化の改善が行われました。
- The TLS 1.2 version negotiation mechanism has been deprecated in favor of a version list in an extension. This increases compatibility with existing servers that incorrectly implemented version negotiation.
- TLS 1.2バージョンネゴシエーションメカニズムは、拡張機能のバージョンリストを優先して廃止されました。 これにより、バージョンネゴシエーションを誤って実装した既存のサーバーとの互換性が向上します。
- Session resumption with and without server-side state as well as the PSK-based cipher suites of earlier TLS versions have been replaced by a single new PSK exchange.
- サーバー側の状態がある場合とない場合のセッション再開、および以前のTLSバージョンのPSKベースの暗号スイートは、単一の新しいPSK交換に置き換えられました。
- References have been updated to point to the updated versions of RFCs, as appropriate (e.g., RFC 5280 rather than RFC 3280).
- 必要に応じて、RFCの更新されたバージョンを指すように参照が更新されました（RFC 3280ではなくRFC 5280など）。
This document defines several changes that optionally affect implementations of TLS 1.2, including those which do not also support TLS 1.3:
このドキュメントでは、TLS 1.3をサポートしないものも含め、TLS 1.2の実装にオプションで影響するいくつかの変更を定義しています。
- A version downgrade protection mechanism is described in Section 4.1.3.
- バージョンダウングレード保護メカニズムについては、セクション4.1.3で説明しています。
- RSASSA-PSS signature schemes are defined in Section 4.2.3.
- RSASSA-PSS署名スキームは、セクション4.2.3で定義されています。
- The "supported_versions" ClientHello extension can be used to negotiate the version of TLS to use, in preference to the legacy_version field of the ClientHello.
-「supported_versions」ClientHello拡張機能を使用して、ClientHelloのlegacy_versionフィールドに優先して、使用するTLSのバージョンをネゴシエートできます。
- The "signature_algorithms_cert" extension allows a client to indicate which signature algorithms it can validate in X.509 certificates.
- "signature_algorithms_cert"拡張により、クライアントはX.509証明書で検証できる署名アルゴリズムを示すことができます。
Additionally, this document clarifies some compliance requirements for earlier versions of TLS; see Section 9.3.
さらに、このドキュメントでは、TLSの以前のバージョンのいくつかのコンプライアンス要件を明確にしています。 セクション9.3を参照してください。
The cryptographic parameters used by the secure channel are produced by the TLS handshake protocol. This sub-protocol of TLS is used by the client and server when first communicating with each other. The handshake protocol allows peers to negotiate a protocol version, select cryptographic algorithms, optionally authenticate each other, and establish shared secret keying material. Once the handshake is complete, the peers use the established keys to protect the application-layer traffic.
セキュアチャネルで使用される暗号化パラメーターは、TLSハンドシェイクプロトコルによって生成されます。 TLSのこのサブプロトコルは、クライアントとサーバーが最初に相互に通信するときに使用されます。 ハンドシェイクプロトコルにより、ピアはプロトコルバージョンをネゴシエートし、暗号化アルゴリズムを選択し、必要に応じて互いを認証し、共有秘密鍵素材を確立できます。 ハンドシェイクが完了すると、ピアは確立されたキーを使用して、アプリケーション層のトラフィックを保護します。
A failure of the handshake or other protocol error triggers the termination of the connection, optionally preceded by an alert message (Section 6).
ハンドシェイクの失敗またはその他のプロトコルエラーは、接続の終了をトリガーし、オプションでアラートメッセージが続きます（セクション6）。
TLS supports three basic key exchange modes:
TLSは、3つの基本的なキー交換モードをサポートしています。
- (EC)DHE (Diffie-Hellman over either finite fields or elliptic curves)
- (EC)DHE（有限体または楕円曲線上のディフィー・ヘルマン）
- PSK-only
- PSKのみ
- PSK with (EC)DHE
- (EC)DHEを使用したPSK
Figure 1 below shows the basic full TLS handshake:
次の図1は、完全なTLSハンドシェイクを示しています。
Client Server
Key ^ ClientHello
Exch | + key_share*
| + signature_algorithms*
| + psk_key_exchange_modes*
v + pre_shared_key* -------->
ServerHello ^ Key
+ key_share* | Exch
+ pre_shared_key* v
{EncryptedExtensions} ^ Server
{CertificateRequest*} v Params
{Certificate*} ^
{CertificateVerify*} | Auth
{Finished} v
<-------- [Application Data*]
^ {Certificate*}
Auth | {CertificateVerify*}
v {Finished} -------->
[Application Data] <-------> [Application Data]
+ 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.
{} は [sender] _handshake_traffic_secretから派生したキーを使用して保護されたメッセージを示します。
[] Indicates messages protected using keys derived from [sender]_application_traffic_secret_N.
[] は [sender] _application_traffic_secret_Nから派生したキーを使用して保護されたメッセージを示します。
Figure 1: Message Flow for Full TLS Handshake
図1：完全なTLSハンドシェイクのメッセージフロー
The handshake can be thought of as having three phases (indicated in the diagram above):
ハンドシェイクは、3つのフェーズ（上記の図に示されている）を持っていると考えることができます。
- Key Exchange: Establish shared keying material and select the cryptographic parameters. Everything after this phase is encrypted.
- 鍵交換：共有鍵素材を確立し、暗号化パラメーターを選択します。 このフェーズ以降はすべて暗号化されます。
- Server Parameters: Establish other handshake parameters (whether the client is authenticated, application-layer protocol support, etc.).
- サーバーパラメータ：他のハンドシェイクパラメータを確立します（クライアントが認証されているかどうか、アプリケーション層プロトコルのサポートなど）。
- Authentication: Authenticate the server (and, optionally, the client) and provide key confirmation and handshake integrity.
- 認証：サーバー（およびオプションでクライアント）を認証し、キーの確認とハンドシェイクの整合性を提供します。
In the Key Exchange phase, the client sends the ClientHello (Section 4.1.2) message, which contains a random nonce (ClientHello.random); its offered protocol versions; a list of symmetric cipher/HKDF hash pairs; either a set of Diffie-Hellman key shares (in the "key_share" (Section 4.2.8) extension), a set of pre-shared key labels (in the "pre_shared_key" (Section 4.2.11) extension), or both; and potentially additional extensions. Additional fields and/or messages may also be present for middlebox compatibility.
キー交換フェーズでは、クライアントは、ランダムなナンス（ClientHello.random）を含むClientHello（セクション4.1.2）メッセージを送信します。 提供されているプロトコルバージョン。 対称暗号/ HKDFハッシュペアのリスト。 Diffie-Hellmanキー共有のセット（「key_share」（セクション4.2.8）拡張内）、事前共有キーラベルのセット（「pre_shared_key」（セクション4.2.11）拡張内）、またはその両方。 潜在的に追加の拡張機能。 ミドルボックスの互換性のために、追加のフィールドやメッセージも存在する場合があります。
The server processes the ClientHello and determines the appropriate cryptographic parameters for the connection. It then responds with its own ServerHello (Section 4.1.3), which indicates the negotiated connection parameters. The combination of the ClientHello and the ServerHello determines the shared keys. If (EC)DHE key establishment is in use, then the ServerHello contains a "key_share" extension with the server's ephemeral Diffie-Hellman share; the server's share MUST be in the same group as one of the client's shares. If PSK key establishment is in use, then the ServerHello contains a "pre_shared_key" extension indicating which of the client's offered PSKs was selected. Note that implementations can use (EC)DHE and PSK together, in which case both extensions will be supplied.
サーバーはClientHelloを処理し、接続に適切な暗号化パラメーターを決定します。 その後、ネゴシエートされた接続パラメータを示す独自のServerHello（セクション4.1.3）で応答します。 ClientHelloとServerHelloの組み合わせにより、共有キーが決まります。 （EC）DHEキーの確立が使用されている場合、ServerHelloにはサーバーの一時的なDiffie-Hellman共有を含む「key_share」拡張が含まれます。 サーバーの共有は、クライアントの共有の1つと同じグループに属している必要があります。 PSKキーの確立が使用中の場合、ServerHelloには、クライアントが提供するPSKのどれが選択されたかを示す「pre_shared_key」拡張が含まれます。 実装では（EC）DHEとPSKを一緒に使用できることに注意してください。その場合、両方の拡張機能が提供されます。
The server then sends two messages to establish the Server Parameters:
次に、サーバーは2つのメッセージを送信してサーバーパラメーターを確立します。
EncryptedExtensions: responses to ClientHello extensions that are not required to determine the cryptographic parameters, other than those that are specific to individual certificates. [Section 4.3.1]
EncryptedExtensions：個々の証明書に固有のもの以外の、暗号化パラメーターを決定する必要のないClientHello拡張機能への応答。 [セクション4.3.1]
CertificateRequest: if certificate-based client authentication is desired, the desired parameters for that certificate. This message is omitted if client authentication is not desired. [Section 4.3.2]
CertificateRequest：証明書ベースのクライアント認証が必要な場合、その証明書に必要なパラメーター。 クライアント認証が望ましくない場合、このメッセージは省略されます。 [セクション4.3.2]
Finally, the client and server exchange Authentication messages. TLS uses the same set of messages every time that certificate-based authentication is needed. (PSK-based authentication happens as a side effect of key exchange.) Specifically:
最後に、クライアントとサーバーは認証メッセージを交換します。 TLSは、証明書ベースの認証が必要になるたびに同じメッセージのセットを使用します。（PSKベースの認証は、鍵交換の副作用として発生します。）特に：
Certificate: The certificate of the endpoint and any per-certificate extensions. This message is omitted by the server if not authenticating with a certificate and by the client if the server did not send CertificateRequest (thus indicating that the client should not authenticate with a certificate). Note that if raw public keys [RFC7250] or the cached information extension [RFC7924] are in use, then this message will not contain a certificate but rather some other value corresponding to the server's long-term key. [Section 4.4.2]
Certificate：エンドポイントの証明書および証明書ごとの拡張。 このメッセージは、証明書で認証されていない場合はサーバーによって省略され、サーバーがCertificateRequestを送信しなかった場合はクライアントによって省略されます（したがって、クライアントが証明書で認証されないことを示します）。 生の公開鍵[RFC7250]またはキャッシュされた情報拡張[RFC7924]が使用されている場合、このメッセージには証明書が含まれず、サーバーの長期鍵に対応する他の値が含まれます。 [セクション4.4.2]
CertificateVerify: A signature over the entire handshake using the private key corresponding to the public key in the Certificate message. This message is omitted if the endpoint is not authenticating via a certificate. [Section 4.4.3]
CertificateVerify：証明書メッセージ内の公開キーに対応する秘密キーを使用した、ハンドシェイク全体にわたる署名。 エンドポイントが証明書を介して認証していない場合、このメッセージは省略されます。 [セクション4.4.3]
Finished: A MAC (Message Authentication Code) over the entire handshake. This message provides key confirmation, binds the endpoint's identity to the exchanged keys, and in PSK mode also authenticates the handshake. [Section 4.4.4]
Finished：ハンドシェイク全体にわたるMAC（メッセージ認証コード）。 このメッセージはキーの確認を提供し、エンドポイントのIDを交換されたキーにバインドし、PSKモードではハンドシェイクも認証します。 [セクション4.4.4]
Upon receiving the server's messages, the client responds with its Authentication messages, namely Certificate and CertificateVerify (if requested), and Finished.
サーバーのメッセージを受信すると、クライアントは認証メッセージ、つまりCertificateとCertificateVerify（要求された場合）、およびFinishedで応答します。
At this point, the handshake is complete, and the client and server derive the keying material required by the record layer to exchange application-layer data protected through authenticated encryption. Application Data MUST NOT be sent prior to sending the Finished message, except as specified in Section 2.3. Note that while the server may send Application Data prior to receiving the client's Authentication messages, any data sent at that point is, of course, being sent to an unauthenticated peer.
この時点で、ハンドシェイクは完了し、クライアントとサーバーは、認証された暗号化によって保護されたアプリケーション層のデータを交換するためにレコード層が必要とするキー情報を取得します。 セクション2.3で指定されている場合を除き、Finishedメッセージを送信する前にアプリケーションデータを送信してはなりません。 サーバーは、クライアントの認証メッセージを受信する前にアプリケーションデータを送信できますが、その時点で送信されるデータは、認証されていないピアに送信されることに注意してください。
If the client has not provided a sufficient "key_share" extension (e.g., it includes only DHE or ECDHE groups unacceptable to or unsupported by the server), the server corrects the mismatch with a HelloRetryRequest and the client needs to restart the handshake with an appropriate "key_share" extension, as shown in Figure 2. If no common cryptographic parameters can be negotiated, the server MUST abort the handshake with an appropriate alert.
クライアントが十分な「key_share」拡張を提供していない場合（たとえば、サーバーで受け入れられない、またはサポートされないDHEまたはECDHEグループのみが含まれる）、サーバーはHelloRetryRequestで不一致を修正し、クライアントは適切なハンドシェイクを再開する必要があります 図2に示すように、「key_share」拡張。共通の暗号化パラメータをネゴシエートできない場合、サーバーは適切なアラートでハンドシェイクを中止する必要があります。
Client Server
ClientHello
+ key_share -------->
HelloRetryRequest
<-------- + key_share
ClientHello
+ key_share -------->
ServerHello
+ key_share
{EncryptedExtensions}
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}
{Finished}
<-------- [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished} -------->
[Application Data] <-------> [Application Data]
Figure 2: Message Flow for a Full Handshake with
Mismatched Parameters
Note: The handshake transcript incorporates the initial ClientHello/HelloRetryRequest exchange; it is not reset with the new ClientHello.
注：ハンドシェイクのトランスクリプトには、最初のClientHello / HelloRetryRequest交換が組み込まれています。 新しいClientHelloではリセットされません。
TLS also allows several optimized variants of the basic handshake, as described in the following sections.
TLSでは、次のセクションで説明するように、基本的なハンドシェイクのいくつかの最適化されたバリアントも使用できます。
Although TLS PSKs can be established out of band, PSKs can also be established in a previous connection and then used to establish a new connection ("session resumption" or "resuming" with a PSK). Once a handshake has completed, the server can send the client a PSK identity that corresponds to a unique key derived from the initial handshake (see Section 4.6.1). The client can then use that PSK identity in future handshakes to negotiate the use of the associated PSK. If the server accepts the PSK, then the security context of the new connection is cryptographically tied to the original connection and the key derived from the initial handshake is used to bootstrap the cryptographic state instead of a full handshake. In TLS 1.2 and below, this functionality was provided by "session IDs" and "session tickets" [RFC5077]. Both mechanisms are obsoleted in TLS 1.3.
TLS PSKは帯域外で確立できますが、PSKは以前の接続で確立してから、新しい接続の確立に使用することもできます（「セッション再開」またはPSKとの「再開」）。 ハンドシェイクが完了すると、サーバーはクライアントに最初のハンドシェイクから派生した一意のキーに対応するPSK IDを送信できます（セクション4.6.1を参照）。 その後、クライアントはそのPSK IDを将来のハンドシェイクで使用して、関連付けられたPSKの使用をネゴシエートできます。 サーバーがPSKを受け入れる場合、新しい接続のセキュリティコンテキストは元の接続に暗号で結び付けられ、最初のハンドシェイクから派生したキーは、完全なハンドシェイクではなく暗号状態をブートストラップするために使用されます。 TLS 1.2以前では、この機能は「セッションID」と「セッションチケット」[RFC5077]によって提供されていました。 両方のメカニズムはTLS 1.3で廃止されました。
PSKs can be used with (EC)DHE key exchange in order to provide forward secrecy in combination with shared keys, or can be used alone, at the cost of losing forward secrecy for the application data.
PSKは、（EC）DHEキー交換で使用して、共有キーと組み合わせて転送秘密を提供するか、単独で使用できますが、アプリケーションデータの転送秘密が失われます。
Figure 3 shows a pair of handshakes in which the first handshake establishes a PSK and the second handshake uses it:
図3は、最初のハンドシェイクがPSKを確立し、2番目のハンドシェイクがそれを使用するハンドシェイクのペアを示しています。
Client Server
Initial Handshake:
ClientHello
+ key_share -------->
ServerHello
+ key_share
{EncryptedExtensions}
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}
{Finished}
<-------- [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished} -------->
<-------- [NewSessionTicket]
[Application Data] <-------> [Application Data]
Subsequent Handshake:
ClientHello
+ key_share*
+ pre_shared_key -------->
ServerHello
+ pre_shared_key
+ key_share*
{EncryptedExtensions}
{Finished}
<-------- [Application Data*]
{Finished} -------->
[Application Data] <-------> [Application Data]
Figure 3: Message Flow for Resumption and PSK
図3：再開とPSKのメッセージフロー
As the server is authenticating via a PSK, it does not send a Certificate or a CertificateVerify message. When a client offers resumption via a PSK, it SHOULD also supply a "key_share" extension to the server to allow the server to decline resumption and fall back to a full handshake, if needed. The server responds with a "pre_shared_key" extension to negotiate the use of PSK key establishment and can (as shown here) respond with a "key_share" extension to do (EC)DHE key establishment, thus providing forward secrecy.
サーバーはPSKを介して認証を行うため、証明書またはCertificateVerifyメッセージは送信しません。 クライアントがPSKを介して再開を提供する場合、サーバーが再開を拒否し、必要に応じて完全なハンドシェイクにフォールバックできるように、サーバーに「key_share」拡張機能も提供する必要があります。 サーバーはPSKキー確立の使用をネゴシエートするために「pre_shared_key」拡張機能で応答し、（ここに示すように）「key_share」拡張機能で応答して（EC）DHEキーを確立し、前方秘匿性を提供します。
When PSKs are provisioned out of band, the PSK identity and the KDF hash algorithm to be used with the PSK MUST also be provisioned.
PSKが帯域外でプロビジョニングされる場合、PSKアイデンティティとPSKで使用されるKDFハッシュアルゴリズムもプロビジョニングする必要があります。
Note: When using an out-of-band provisioned pre-shared secret, a critical consideration is using sufficient entropy during the key generation, as discussed in [RFC4086]. Deriving a shared secret from a password or other low-entropy sources is not secure. A low-entropy secret, or password, is subject to dictionary attacks based on the PSK binder. The specified PSK authentication is not a strong password-based authenticated key exchange even when used with Diffie-Hellman key establishment. Specifically, it does not prevent an attacker that can observe the handshake from performing a brute-force attack on the password/pre-shared key.
注：帯域外でプロビジョニングされた事前共有シークレットを使用する場合、[RFC4086]で説明されているように、鍵の生成時に十分なエントロピーを使用することが重要な考慮事項です。 パスワードまたは他の低エントロピーソースから共有シークレットを取得することは安全ではありません。 低エントロピーシークレット、またはパスワードは、PSKバインダに基づいた辞書攻撃の影響を受けます。 指定されたPSK認証は、Diffie-Hellmanキー確立で使用される場合でも、強力なパスワードベースの認証キー交換ではありません。 具体的には、ハンドシェイクを監視できる攻撃者がパスワード/事前共有キーに対してブルートフォース攻撃を実行することを防ぎません。
When clients and servers share a PSK (either obtained externally or via a previous handshake), TLS 1.3 allows clients to send data on the first flight ("early data"). The client uses the PSK to authenticate the server and to encrypt the early data.
クライアントとサーバーが（外部または以前のハンドシェイクを介して取得された）PSKを共有する場合、TLS 1.3により、クライアントは最初のフライトでデータ（「初期データ」）を送信できます。 クライアントはPSKを使用してサーバーを認証し、初期データを暗号化します。
As shown in Figure 4, the 0-RTT data is just added to the 1-RTT handshake in the first flight. The rest of the handshake uses the same messages as for a 1-RTT handshake with PSK resumption.
図4に示すように、最初のフライトで0-RTTデータが1-RTTハンドシェイクに追加されます。 ハンドシェイクの残りは、PSK再開を伴う1-RTTハンドシェイクと同じメッセージを使用します。
Client Server
ClientHello
+ early_data
+ key_share*
+ psk_key_exchange_modes
+ pre_shared_key
(Application Data*) -------->
ServerHello
+ pre_shared_key
+ key_share*
{EncryptedExtensions}
+ early_data*
{Finished}
<-------- [Application Data*]
(EndOfEarlyData)
{Finished} -------->
[Application Data] <-------> [Application Data]
+ 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 client_early_traffic_secret.
() は client_early_traffic_secretから派生したキーを使用して保護されたメッセージを示します。
{} Indicates messages protected using keys derived from a [sender]_handshake_traffic_secret.
{} は [sender] _handshake_traffic_secretから派生したキーを使用して保護されたメッセージを示します。
[] Indicates messages protected using keys derived from [sender]_application_traffic_secret_N.
[] は [sender] _application_traffic_secret_Nから派生したキーを使用して保護されたメッセージを示します。
Figure 4: Message Flow for a 0-RTT Handshake
図4：0-RTTハンドシェイクのメッセージフロー
IMPORTANT NOTE: The security properties for 0-RTT data are weaker than those for other kinds of TLS data. Specifically:
重要な注意：0-RTTデータのセキュリティプロパティは、他の種類のTLSデータのセキュリティプロパティよりも脆弱です。 具体的には：
1. This data is not forward secret, as it is encrypted solely under keys derived using the offered PSK.
1. このデータは、提供されたPSKを使用して導出された鍵の下でのみ暗号化されるため、前方秘密ではありません。
2. There are no guarantees of non-replay between connections. Protection against replay for ordinary TLS 1.3 1-RTT data is provided via the server's Random value, but 0-RTT data does not depend on the ServerHello and therefore has weaker guarantees. This is especially relevant if the data is authenticated either with TLS client authentication or inside the application protocol. The same warnings apply to any use of the early_exporter_master_secret.
2. リプレイ攻撃ではないという保証はありません。 通常のTLS 1.3 1-RTTデータのリプレイ攻撃に対する保護はサーバーのランダム値を介して提供されますが、0-RTTデータはServerHelloに依存しないため、保証が弱くなります。 これは、データがTLSクライアント認証またはアプリケーションプロトコル内で認証される場合に特に関連します。 同じ警告は、early_exporter_master_secretの使用にも適用されます。
0-RTT data cannot be duplicated within a connection (i.e., the server will not process the same data twice for the same connection), and an attacker will not be able to make 0-RTT data appear to be 1-RTT data (because it is protected with different keys). Appendix E.5 contains a description of potential attacks, and Section 8 describes mechanisms which the server can use to limit the impact of replay.
接続内で0-RTTデータを複製することはできません（つまり、サーバーは同じ接続に対して同じデータを2回処理しません）。攻撃者は0-RTTデータを1-RTTデータのように見せることはできません（異なるキーで保護されているので）。 付録E.5には、潜在的な攻撃の説明が含まれます。セクション8では、サーバーがリプレイ攻撃の影響を制限するために使用できるメカニズムについて説明します。
This document deals with the formatting of data in an external representation. The following very basic and somewhat casually defined presentation syntax will be used.
このドキュメントでは、外部表現でのデータのフォーマットを扱います。 次の非常に基本的な、やや不定に定義されたプレゼンテーション構文が使用されます。
The representation of all data items is explicitly specified. The basic data block size is one byte (i.e., 8 bits). Multiple-byte data items are concatenations of bytes, from left to right, from top to bottom. From the byte stream, a multi-byte item (a numeric in the following example) is formed (using C notation) by:
すべてのデータ項目の表現は明示的に指定されます。 基本的なデータブロックサイズは1バイト（つまり、8ビット）です。 複数バイトのデータ項目は、左から右へ、上から下へのバイトの連結です。 バイトストリームから、マルチバイト項目（次の例では数値）が（C表記を使用して）形成されます。
value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
... | byte[n-1];
This byte ordering for multi-byte values is the commonplace network byte order or big-endian format.
マルチバイト値のこのバイト順序は、一般的なネットワークバイト順序またはビッグエンディアン形式です。
Comments begin with "/*" and end with "*/".
コメントは「/*」で始まり、「*/」で終わります。
Optional components are denoted by enclosing them in "[[ ]]" (double brackets).
オプションのコンポーネントは、「[[ ]]」（二重角括弧）で囲むことによって示されます。
Single-byte entities containing uninterpreted data are of type opaque.
解釈されないデータを含むシングルバイトエンティティは、不透明タイプです。
A type alias T' for an existing type T is defined by:
既存の型Tの別名の型 T' は、以下によって定義されます。
T T';
The basic numeric data type is an unsigned byte (uint8). All larger numeric data types are constructed from a fixed-length series of bytes concatenated as described in Section 3.1 and are also unsigned. The following numeric types are predefined.
基本的な数値データ型は、符号なしバイト（uint8）です。 すべての大きな数値データ型は、セクション3.1で説明されているように連結された固定長の一連のバイトから構築され、符号もありません。 次の数値タイプが事前定義されています。
uint8 uint16[2];
uint8 uint24[3];
uint8 uint32[4];
uint8 uint64[8];
All values, here and elsewhere in the specification, are transmitted in network byte (big-endian) order; the uint32 represented by the hex bytes 01 02 03 04 is equivalent to the decimal value 16909060.
ここおよび仕様の別の場所にあるすべての値は、ネットワークバイト（ビッグエンディアン）順序で送信されます。 16進バイト01 02 03 04で表されるuint32は、10進値16909060と同等です。
A vector (single-dimensioned array) is a stream of homogeneous data elements. The size of the vector may be specified at documentation time or left unspecified until runtime. In either case, the length declares the number of bytes, not the number of elements, in the vector. The syntax for specifying a new type, T', that is a fixed-length vector of type T is
ベクトル（一次元配列）は、同種のデータ要素のストリームです。 ベクターのサイズは、ドキュメント作成時に指定するか、実行時まで指定しないままにすることができます。 どちらの場合でも、長さはベクトルの要素数ではなくバイト数を宣言します。 T型の固定長ベクトルである新しい型T' を指定するための構文は次のとおりです。
T T'[n];
Here, T' occupies n bytes in the data stream, where n is a multiple of the size of T. The length of the vector is not included in the encoded stream.
ここで、T' はデータストリームでnバイトを占有します。nはTのサイズの倍数です。ベクトルの長さはエンコードされたストリームに含まれません。
In the following example, Datum is defined to be three consecutive bytes that the protocol does not interpret, while Data is three consecutive Datum, consuming a total of nine bytes.
次の例では、プロトコルが解釈しない3つの連続したバイトとしてDatumが定義されていますが、Dataは合計9つのバイトを消費する3つの連続したDatumです。
opaque Datum[3]; /* three uninterpreted bytes */
Datum Data[9]; /* three consecutive 3-byte vectors */
Variable-length vectors are defined by specifying a subrange of legal lengths, inclusively, using the notation <floor..ceiling>. When these are encoded, the actual length precedes the vector's contents in the byte stream. The length will be in the form of a number consuming as many bytes as required to hold the vector's specified maximum (ceiling) length. A variable-length vector with an actual length field of zero is referred to as an empty vector.
可変長ベクトルは、表記<下限..上限>を使用して、有効な長さのサブ範囲を包括的に指定することによって定義されます。 これらがエンコードされると、実際の長さがバイトストリーム内のベクターのコンテンツに先行します。 長さは、ベクトルの指定された最大（上限）長を保持するのに必要なバイト数を消費する数値の形式になります。 実際の長さフィールドがゼロの可変長ベクトルは、空のベクトルと呼ばれます。
T T'<floor..ceiling>;
In the following example, "mandatory" is a vector that must contain between 300 and 400 bytes of type opaque. It can never be empty. The actual length field consumes two bytes, a uint16, which is sufficient to represent the value 400 (see Section 3.3). Similarly, "longer" can represent up to 800 bytes of data, or 400 uint16 elements, and it may be empty. Its encoding will include a two-byte actual length field prepended to the vector. The length of an encoded vector must be an exact multiple of the length of a single element (e.g., a 17-byte vector of uint16 would be illegal).
次の例では、変数「mandatory」は不透明型の300〜400バイトを含む必要があるベクトルです。 空にすることはできません。 実際の長さフィールドは、値400を表すのに十分なuint16という2バイトを消費します（セクション3.3を参照）。 同様に、変数「longer」は最大800バイトのデータ、または400 uint16要素を表すことができ、空の場合もあります。 そのエンコードには、ベクトルの前に付加される2バイトの実際の長さフィールドが含まれます。 エンコードされたベクトルの長さは、単一の要素の長さの正確な倍数でなければなりません（たとえば、uint16の17バイトのベクトルは不正です）。
opaque mandatory<300..400>;
/* length field is two bytes, cannot be empty */
uint16 longer<0..800>;
/* zero to 400 16-bit unsigned integers */
An additional sparse data type, called "enum" or "enumerated", is available. Each definition is a different type. Only enumerateds of the same type may be assigned or compared. Every element of an enumerated must be assigned a value, as demonstrated in the following example. Since the elements of the enumerated are not ordered, they can be assigned any unique value, in any order.
「enum」または「enumerated」と呼ばれるデータ型も利用可能です。 各定義は異なるタイプです。 同じタイプの列挙のみを割り当てまたは比較できます。 次の例に示すように、列挙型のすべての要素に値を割り当てる必要があります。 列挙型の要素は順序付けされていないため、任意の一意の値を任意の順序で割り当てることができます。
enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
Future extensions or additions to the protocol may define new values. Implementations need to be able to parse and ignore unknown values unless the definition of the field states otherwise.
プロトコルの将来の拡張または追加により、新しい値が定義される可能性があります。 実装では、フィールドの定義に特に明記されていない限り、未知の値を解析および無視できる必要があります。
An enumerated occupies as much space in the byte stream as would its maximal defined ordinal value. The following definition would cause one byte to be used to carry fields of type Color.
列挙型は、バイトストリーム内で、定義された最大の順序値と同じくらいのスペースを占有します。 次の定義により、Color型のフィールドを保持するために1バイトが使用されます。
enum { red(3), blue(5), white(7) } Color;
One may optionally specify a value without its associated tag to force the width definition without defining a superfluous element.
オプションで、関連付けられたタグなしで値を指定して、余分な要素を定義せずに幅を強制的に定義できます。
In the following example, Taste will consume two bytes in the data stream but can only assume the values 1, 2, or 4 in the current version of the protocol.
次の例では、Tasteはデータストリームで2バイトを消費しますが、プロトコルの現在のバージョンでは値1、2、または4のみを想定できます。
enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
The names of the elements of an enumeration are scoped within the defined type. In the first example, a fully qualified reference to the second element of the enumeration would be Color.blue. Such qualification is not required if the target of the assignment is well specified.
列挙の要素の名前は、定義された型内でスコープされます。 最初の例では、列挙の2番目の要素への完全修飾参照はColor.blueになります。 割り当ての対象が明確に指定されている場合、そのような資格は必要ありません。
Color color = Color.blue; /* overspecified, legal */
Color color = blue; /* correct, type implicit */
The names assigned to enumerateds do not need to be unique. The numerical value can describe a range over which the same name applies. The value includes the minimum and maximum inclusive values in that range, separated by two period characters. This is principally useful for reserving regions of the space.
列挙に割り当てられる名前は一意である必要はありません。 数値は、同じ名前が適用される範囲を説明できます。 値には、2つのピリオド文字で区切られた、その範囲の最小値と最大値が含まれます。 これは、主にスペースの領域を予約するのに役立ちます。
enum { sad(0), meh(1..254), happy(255) } Mood;
Structure types may be constructed from primitive types for convenience. Each specification declares a new, unique type. The syntax used for definitions is much like that of C.
構造型は、便宜上、プリミティブ型から構築できます。 各仕様は、新しい一意の型を宣言します。 定義に使用される構文は、Cの構文によく似ています。
struct {
T1 f1;
T2 f2;
...
Tn fn;
} T;
Fixed- and variable-length vector fields are allowed using the standard vector syntax. Structures V1 and V2 in the variants example (Section 3.8) demonstrate this.
標準ベクトル構文を使用して、固定長および可変長のベクトルフィールドを使用できます。 バリアントの例（セクション3.8）の構造V1およびV2は、これを示しています。
The fields within a structure may be qualified using the type's name, with a syntax much like that available for enumerateds. For example, T.f2 refers to the second field of the previous declaration.
構造体内のフィールドは、列挙型で使用可能な構文によく似た構文で、型の名前を使用して修飾できます。 たとえば、T.f2は前の宣言の2番目のフィールドを参照します。
Fields and variables may be assigned a fixed value using "=", as in:
フィールドと変数には、次のように「=」を使用して固定値を割り当てることができます。
struct {
T1 f1 = 8; /* T.f1 must always be 8 */
T2 f2;
} T;
Defined structures may have variants based on some knowledge that is available within the environment. The selector must be an enumerated type that defines the possible variants the structure defines. Each arm of the select (below) specifies the type of that variant's field and an optional field label. The mechanism by which the variant is selected at runtime is not prescribed by the presentation language.
定義された構造には、環境内で利用可能な知識に基づいたバリアントが含まれる場合があります。 セレクターは、構造が定義する可能性のあるバリアントを定義する列挙型である必要があります。 選択の各アーム（下）は、そのバリアントのフィールドのタイプとオプションのフィールドラベルを指定します。 実行時にバリアントを選択するメカニズムは、プレゼンテーション言語で規定されていません。
struct {
T1 f1;
T2 f2;
....
Tn fn;
select (E) {
case e1: Te1 [[fe1]];
case e2: Te2 [[fe2]];
....
case en: Ten [[fen]];
};
} Tv;
For example:
例えば：
enum { apple(0), orange(1) } VariantTag;
struct {
uint16 number;
opaque string<0..10>; /* variable length */
} V1;
struct {
uint32 number;
opaque string[10]; /* fixed length */
} V2;
struct {
VariantTag type;
select (VariantRecord.type) {
case apple: V1;
case orange: V2;
};
} VariantRecord;
The handshake protocol is used to negotiate the security parameters of a connection. Handshake messages are supplied to the TLS record layer, where they are encapsulated within one or more TLSPlaintext or TLSCiphertext structures which are processed and transmitted as specified by the current active connection state.
ハンドシェイクプロトコルは、接続のセキュリティパラメータをネゴシエートするために使用されます。 ハンドシェイクメッセージはTLSレコード層に提供され、現在のアクティブな接続状態の指定に従って処理および送信される1つ以上のTLSPlaintextまたはTLSCiphertext構造内にカプセル化されます。
enum {
client_hello(1),
server_hello(2),
new_session_ticket(4),
end_of_early_data(5),
encrypted_extensions(8),
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; /* remaining bytes in message */
select (Handshake.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;
};
} Handshake;
Protocol messages MUST be sent in the order defined in Section 4.4.1 and shown in the diagrams in Section 2. A peer which receives a handshake message in an unexpected order MUST abort the handshake with an "unexpected_message" alert.
プロトコルメッセージは、セクション4.4.1で定義され、セクション2の図に示されている順序で送信する必要があります。予期しない順序でハンドシェイクメッセージを受信するピアは、「unexpected_message」アラートでハンドシェイクを中止する必要があります。
New handshake message types are assigned by IANA as described in Section 11.
セクション11で説明されているように、新しいハンドシェイクメッセージタイプはIANAによって割り当てられます。
The key exchange messages are used to determine the security capabilities of the client and the server and to establish shared secrets, including the traffic keys used to protect the rest of the handshake and the data.
鍵交換メッセージは、クライアントとサーバーのセキュリティ機能を決定し、後に続くハンドシェイクとデータを保護するために使用されるトラフィックキーなどの共有シークレットを確立するために使用されます。
In TLS, the cryptographic negotiation proceeds by the client offering the following four sets of options in its ClientHello:
TLSでは、暗号ネゴシエーションは、ClientHelloで次の4つのオプションセットを提供するクライアントによって続行されます。
- A list of cipher suites which indicates the AEAD algorithm/HKDF hash pairs which the client supports.
- クライアントがサポートするAEADアルゴリズムとHKDFハッシュのペアを示す暗号スイートのリスト。
- A "supported_groups" (Section 4.2.7) extension which indicates the (EC)DHE groups which the client supports and a "key_share" (Section 4.2.8) extension which contains (EC)DHE shares for some or all of these groups.
- クライアントがサポートする（EC）DHEグループを示す「supported_groups」（セクション4.2.7）拡張、およびこれらのグループの一部またはすべての（EC）DHE共有を含む「key_share」（セクション4.2.8）拡張 。
- A "signature_algorithms" (Section 4.2.3) extension which indicates the signature algorithms which the client can accept. A "signature_algorithms_cert" extension (Section 4.2.3) may also be added to indicate certificate-specific signature algorithms.
- クライアントが受け入れることができる署名アルゴリズムを示す「signature_algorithms」（セクション4.2.3）拡張。 「signature_algorithms_cert」拡張機能（セクション4.2.3）を追加して、証明書固有の署名アルゴリズムを示すこともできます。
- A "pre_shared_key" (Section 4.2.11) extension which contains a list of symmetric key identities known to the client and a "psk_key_exchange_modes" (Section 4.2.9) extension which indicates the key exchange modes that may be used with PSKs.
- クライアントが認識している対称キーIDのリストを含む「pre_shared_key」（セクション4.2.11）拡張と、PSKで使用できるキー交換モードを示す「psk_key_exchange_modes」（セクション4.2.9）拡張。
If the server does not select a PSK, then the first three of these options are entirely orthogonal: the server independently selects a cipher suite, an (EC)DHE group and key share for key establishment, and a signature algorithm/certificate pair to authenticate itself to the client. If there is no overlap between the received "supported_groups" and the groups supported by the server, then the server MUST abort the handshake with a "handshake_failure" or an "insufficient_security" alert.
サーバーがPSKを選択しない場合、これらのオプションの最初の3つは完全に直交します。サーバーは、暗号スイート、（EC）DHEグループ、鍵確立用の鍵共有、および認証する署名アルゴリズム/証明書ペアを個別に選択します それ自体をクライアントに。 受信した「supported_groups」とサーバーがサポートするグループの間に重複がない場合、サーバーは「handshake_failure」または「insufficient_security」アラートでハンドシェイクを中止する必要があります。
If the server selects a PSK, then it MUST also select a key establishment mode from the set indicated by the client's "psk_key_exchange_modes" extension (at present, PSK alone or with (EC)DHE). Note that if the PSK can be used without (EC)DHE, then non-overlap in the "supported_groups" parameters need not be fatal, as it is in the non-PSK case discussed in the previous paragraph.
サーバーがPSKを選択する場合、クライアントの「psk_key_exchange_modes」拡張（現在、PSK単独または（EC）DHEを使用）で示されるセットから鍵確立モードも選択する必要があります。 PSKを（EC）DHEなしで使用できる場合、前の段落で説明した非PSKの場合のように、「supported_groups」パラメーターの非重複が致命的である必要はないことに注意してください。
If the server selects an (EC)DHE group and the client did not offer a compatible "key_share" extension in the initial ClientHello, the server MUST respond with a HelloRetryRequest (Section 4.1.4) message.
サーバーが（EC）DHEグループを選択し、クライアントが初期ClientHelloで互換性のある「key_share」拡張を提供しなかった場合、サーバーはHelloRetryRequest（セクション4.1.4）メッセージで応答しなければなりません。
If the server successfully selects parameters and does not require a HelloRetryRequest, it indicates the selected parameters in the ServerHello as follows:
サーバーがパラメーターを正常に選択し、HelloRetryRequestを必要としない場合、ServerHelloで選択されたパラメーターを次のように示します。
- If PSK is being used, then the server will send a "pre_shared_key" extension indicating the selected key.
- PSKが使用されている場合、サーバーは選択されたキーを示す「pre_shared_key」拡張子を送信します。
- When (EC)DHE is in use, the server will also provide a "key_share" extension. If PSK is not being used, then (EC)DHE and certificate-based authentication are always used.
- (EC)DHEが使用されている場合、サーバーは「key_share」拡張機能も提供します。 PSKが使用されていない場合、(EC)DHEおよび証明書ベースの認証が常に使用されます。
- When authenticating via a certificate, the server will send the Certificate (Section 4.4.2) and CertificateVerify (Section 4.4.3) messages. In TLS 1.3 as defined by this document, either a PSK or a certificate is always used, but not both. Future documents may define how to use them together.
- 証明書を介して認証する場合、サーバーは証明書（セクション4.4.2）および証明書検証（セクション4.4.3）メッセージを送信します。 このドキュメントで定義されているTLS 1.3では、PSKまたは証明書のいずれかが常に使用されますが、両方は使用されません。 将来のドキュメントは、それらを一緒に使用する方法を定義するかもしれません。
If the server is unable to negotiate a supported set of parameters (i.e., there is no overlap between the client and server parameters), it MUST abort the handshake with either a "handshake_failure" or "insufficient_security" fatal alert (see Section 6).
サーバーがサポートされているパラメーターのセットをネゴシエートできない場合（つまり、クライアントとサーバーのパラメーターが重複していない場合）、「handshake_failure」または「insufficient_security」致命的アラートでハンドシェイクを中止する必要があります（セクション6を参照）。
When a client first connects to a server, it is REQUIRED to send the ClientHello as its first TLS message. The client will also send a ClientHello when the server has responded to its ClientHello with a HelloRetryRequest. In that case, the client MUST send the same ClientHello without modification, except as follows:
クライアントが最初にサーバーに接続するとき、ClientHelloを最初のTLSメッセージとして送信する必要があります。 サーバーは、HelloRetryRequestでClientHelloに応答したときに、クライアントもClientHelloを送信します。 その場合、クライアントは次の場合を除いて、変更せずに同じClientHelloを送信する必要があります。
- If a "key_share" extension was supplied in the HelloRetryRequest, replacing the list of shares with a list containing a single KeyShareEntry from the indicated group.
-「key_share」拡張機能がHelloRetryRequestで指定された場合、指定されたグループの単一のKeyShareEntryを含むリストで共有のリストを置き換えます。
- Removing the "early_data" extension (Section 4.2.10) if one was present. Early data is not permitted after a HelloRetryRequest.
-「early_data」拡張機能（4.2.10項）が存在する場合は削除します。 HelloRetryRequestの後の初期データは許可されません。
- Including a "cookie" extension if one was provided in the HelloRetryRequest.
- HelloRetryRequestで「Cookie」拡張機能が提供された場合、その拡張機能を含めます。
- Updating the "pre_shared_key" extension if present by recomputing the "obfuscated_ticket_age" and binder values and (optionally) removing any PSKs which are incompatible with the server's indicated cipher suite.
-「obfuscated_ticket_age」とバインダーの値を再計算し、（オプションで）サーバーの指定された暗号スイートと互換性のないPSKを削除することにより、「pre_shared_key」拡張機能を更新します。
- Optionally adding, removing, or changing the length of the "padding" extension [RFC7685].
- オプションで、「パディング」拡張機能の長さを追加、削除、または変更します[RFC7685]。
- Other modifications that may be allowed by an extension defined in the future and present in the HelloRetryRequest.
- 将来定義され、HelloRetryRequestに存在する拡張機能によって許可される可能性があるその他の変更。
Because TLS 1.3 forbids renegotiation, if a server has negotiated TLS 1.3 and receives a ClientHello at any other time, it MUST terminate the connection with an "unexpected_message" alert.
TLS 1.3は再ネゴシエーションを禁止しているため、サーバーがTLS 1.3をネゴシエートし、それ以外の時間にClientHelloを受信した場合、「unexpected_message」アラートで接続を終了する必要があります。
If a server established a TLS connection with a previous version of TLS and receives a TLS 1.3 ClientHello in a renegotiation, it MUST retain the previous protocol version. In particular, it MUST NOT negotiate TLS 1.3.
サーバーが以前のバージョンのTLSとのTLS接続を確立し、再ネゴシエーションでTLS 1.3 ClientHelloを受信した場合、以前のプロトコルバージョンを保持する必要があります。 特に、TLS 1.3をネゴシエートしてはなりません。
Structure of this message:
このメッセージの構造：
uint16 ProtocolVersion;
opaque Random[32];
uint8 CipherSuite[2]; /* Cryptographic suite selector */
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id<0..32>;
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 TLS, 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 TLS 1.3, the client indicates its version preferences in the "supported_versions" extension (Section 4.2.1) and the legacy_version field MUST be set to 0x0303, which is the version number for TLS 1.2. TLS 1.3 ClientHellos are identified as having a legacy_version of 0x0303 and a supported_versions extension present with 0x0304 as the highest version indicated therein. (See Appendix D for details about backward compatibility.)
legacy_version：TLSの以前のバージョンでは、このフィールドはバージョンネゴシエーションに使用され、クライアントでサポートされている最大のバージョン番号を表していました。 多くのサーバーはバージョンネゴシエーションを適切に実装していないため、サーバーがサポートするバージョン番号よりも高いバージョンのClientHelloを拒否する「バージョン不寛容」につながることが経験からわかっています。 TLS 1.3では、クライアントは「supported_versions」拡張子（セクション4.2.1）でバージョン設定を示し、legacy_versionフィールドは0x0303（TLS 1.2のバージョン番号）に設定する必要があります。 TLS 1.3 ClientHellosは、legacy_versionが0x0303であり、supported_versions拡張子がその中に示されている最高バージョンとして0x0304であると識別されます。 （後方互換性の詳細については、付録Dを参照してください。）
random: 32 bytes generated by a secure random number generator. See Appendix C for additional information.
random：安全な乱数ジェネレーターによって生成された32バイト。 追加情報については、付録Cを参照してください。
legacy_session_id: Versions of TLS before TLS 1.3 supported a "session resumption" feature which has been merged with pre-shared keys in this version (see Section 2.2). A client which has a cached session ID set by a pre-TLS 1.3 server SHOULD set this field to that value. In compatibility mode (see Appendix D.4), this field MUST be non-empty, so a client not offering a pre-TLS 1.3 session MUST generate a new 32-byte value. This value need not be random but SHOULD be unpredictable to avoid implementations fixating on a specific value (also known as ossification). Otherwise, it MUST be set as a zero-length vector (i.e., a zero-valued single byte length field).
legacy_session_id：TLS 1.3より前のTLSのバージョンは、このバージョンの事前共有キーとマージされた「セッション再開」機能をサポートしていました（セクション2.2を参照）。 TLS 1.3以前のサーバーによって設定されたキャッシュセッションIDを持つクライアントは、このフィールドをその値に設定する必要があります。 互換性モード（付録D.4を参照）では、このフィールドは空でない必要があるため、TLS 1.3以前のセッションを提供しないクライアントは新しい32バイト値を生成する必要があります。 この値はランダムである必要はありませんが、実装が特定の値に固定されるのを避けるために予測不可能である必要があります（オッシフィケーションとも呼ばれます）。 それ以外の場合、長さゼロのベクトル（つまり、ゼロ値の単一バイト長フィールド）として設定する必要があります。
cipher_suites: A list of the symmetric cipher options supported by the client, specifically the record protection algorithm (including secret key length) and a hash to be used with HKDF, in descending order of client preference. Values are defined in Appendix B.4. If the list contains cipher suites that the server does not recognize, support, or wish to use, the server MUST ignore those cipher suites and process the remaining ones as usual. If the client is attempting a PSK key establishment, it SHOULD advertise at least one cipher suite indicating a Hash associated with the PSK.
cipher_suites：クライアントがサポートする対称暗号オプションのリスト、具体的には、レコード保護アルゴリズム（秘密鍵の長さを含む）およびHKDFで使用されるハッシュを、クライアントの優先度の降順で示します。 値は付録B.4で定義されています。 サーバーが認識、サポート、または使用を希望しない暗号スイートがリストに含まれている場合、サーバーはそれらの暗号スイートを無視し、残りの暗号スイートを通常どおりに処理する必要があります。 クライアントがPSKキーの確立を試みている場合、PSKに関連付けられたハッシュを示す少なくとも1つの暗号スイートをアドバタイズする必要があります。
legacy_compression_methods: Versions of TLS before 1.3 supported compression with the list of supported compression methods being sent in this field. For every TLS 1.3 ClientHello, this vector MUST contain exactly one byte, set to zero, which corresponds to the "null" compression method in prior versions of TLS. If a TLS 1.3 ClientHello is received with any other value in this field, the server MUST abort the handshake with an "illegal_parameter" alert. Note that TLS 1.3 servers might receive TLS 1.2 or prior ClientHellos which contain other compression methods and (if negotiating such a prior version) MUST follow the procedures for the appropriate prior version of TLS.
legacy_compression_methods：1.3より前のTLSのバージョンは、このフィールドで送信されるサポートされている圧縮方法のリストで圧縮をサポートしていました。 すべてのTLS 1.3 ClientHelloについて、このベクトルには、ゼロに設定された正確に1バイトが含まれている必要があります。これは、以前のバージョンのTLSの「null」圧縮方式に対応します。 このフィールドの他の値でTLS 1.3 ClientHelloを受信した場合、サーバーは「illegal_parameter」アラートでハンドシェイクを中止する必要があります。 TLS 1.3サーバーは、他の圧縮方法を含むTLS 1.2または以前のClientHellosを受信する場合があり、（そのような以前のバージョンをネゴシエートする場合）TLSの適切な以前のバージョンの手順に従う必要があることに注意してください。
extensions: Clients request extended functionality from servers by sending data in the extensions field. The actual "Extension" format is defined in Section 4.2. In TLS 1.3, the use of certain extensions is mandatory, as functionality has moved into extensions to preserve ClientHello compatibility with previous versions of TLS. Servers MUST ignore unrecognized extensions.
extensions：クライアントは拡張機能フィールドにデータを送信して、サーバーに拡張機能を要求します。 実際の「拡張」フォーマットは、セクション4.2で定義されています。 TLS 1.3では、ClientHelloとTLSの以前のバージョンとの互換性を維持するために機能が拡張機能に移行したため、特定の拡張機能の使用は必須です。 サーバーは認識されない拡張子を無視しなければなりません。
All versions of TLS allow an extensions field to optionally follow the compression_methods field. TLS 1.3 ClientHello messages always contain extensions (minimally "supported_versions", otherwise, they will be interpreted as TLS 1.2 ClientHello messages). However, TLS 1.3 servers might receive ClientHello messages without an extensions field from prior versions of TLS. The presence of extensions can be detected by determining whether there are bytes following the compression_methods field at the end of the ClientHello. Note that this method of detecting optional data differs from the normal TLS method of having a variable-length field, but it is used for compatibility with TLS before extensions were defined. TLS 1.3 servers will need to perform this check first and only attempt to negotiate TLS 1.3 if the "supported_versions" extension is present. If negotiating a version of TLS prior to 1.3, a server MUST check that the message either contains no data after legacy_compression_methods or that it contains a valid extensions block with no data following. If not, then it MUST abort the handshake with a "decode_error" alert.
TLSのすべてのバージョンでは、オプションで拡張フィールドをcompression_methodsフィールドの後に続けることができます。 TLS 1.3 ClientHelloメッセージには、常に拡張子が含まれます（最小で「supported_versions」、それ以外の場合、TLS 1.2 ClientHelloメッセージとして解釈されます）。ただし、TLS 1.3サーバーは、以前のバージョンのTLSから拡張フィールドのないClientHelloメッセージを受信する場合があります。拡張機能の存在は、ClientHelloの最後のcompression_methodsフィールドに続くバイトがあるかどうかを判断することで検出できます。このオプションのデータを検出する方法は、可変長フィールドを持つ通常のTLS方法とは異なりますが、拡張機能が定義される前のTLSとの互換性のために使用されることに注意してください。 TLS 1.3サーバーは、最初にこのチェックを実行する必要があり、「supported_versions」拡張機能が存在する場合にのみTLS 1.3をネゴシエートしようとします。 1.3より前のバージョンのTLSをネゴシエートする場合、サーバーは、legacy_compression_methodsの後にメッセージにデータが含まれていないか、データが後続しない有効な拡張ブロックが含まれていることを確認する必要があります。そうでない場合、「decode_error」アラートでハンドシェイクを中止する必要があります。
In the event that a client requests additional functionality using extensions and this functionality is not supplied by the server, the client MAY abort the handshake.
クライアントが拡張機能を使用して追加機能を要求し、この機能がサーバーによって提供されていない場合、クライアントはハンドシェイクを中止することができます。
After sending the ClientHello message, the client waits for a ServerHello or HelloRetryRequest message. If early data is in use, the client may transmit early Application Data (Section 2.3) while waiting for the next handshake message.
ClientHelloメッセージを送信した後、クライアントはServerHelloまたはHelloRetryRequestメッセージを待ちます。 初期データが使用されている場合、クライアントは次のハンドシェイクメッセージを待っている間に初期アプリケーションデータ（2.3節）を送信できます。
The server will send this message in response to a ClientHello message to proceed with the handshake if it is able to negotiate an acceptable set of handshake parameters based on the ClientHello.
サーバーは、ClientHelloに基づいてハンドシェイクパラメータの許容セットをネゴシエートできる場合、ClientHelloメッセージへの応答としてこのメッセージを送信してハンドシェイクを続行します。
Structure of this message:
このメッセージの構造：
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id_echo<0..32>;
CipherSuite cipher_suite;
uint8 legacy_compression_method = 0;
Extension extensions<6..2^16-1>;
} ServerHello;
legacy_version: In previous versions of TLS, this field was used for version negotiation and represented the selected version number for the connection. Unfortunately, some middleboxes fail when presented with new values. In TLS 1.3, the TLS server indicates its version using the "supported_versions" extension (Section 4.2.1), and the legacy_version field MUST be set to 0x0303, which is the version number for TLS 1.2. (See Appendix D for details about backward compatibility.)
legacy_version：TLSの以前のバージョンでは、このフィールドはバージョンネゴシエーションに使用され、接続用に選択されたバージョン番号を表していました。 残念ながら、新しい値を提示すると一部のミドルボックスが失敗します。 TLS 1.3では、TLSサーバーは「supported_versions」拡張子（セクション4.2.1）を使用してバージョンを示し、legacy_versionフィールドは0x0303（TLS 1.2のバージョン番号）に設定する必要があります。 （後方互換性の詳細については、付録Dを参照してください。）
random: 32 bytes generated by a secure random number generator. See Appendix C for additional information. The last 8 bytes MUST be overwritten as described below if negotiating TLS 1.2 or TLS 1.1, but the remaining bytes MUST be random. This structure is generated by the server and MUST be generated independently of the ClientHello.random.
random：安全な乱数ジェネレーターによって生成された32バイト。 追加情報については、付録Cを参照してください。 TLS 1.2またはTLS 1.1をネゴシエートする場合、最後の8バイトは以下で説明するように上書きする必要がありますが、残りのバイトはランダムでなければなりません。 この構造はサーバーによって生成され、ClientHello.randomとは独立して生成されなければなりません。
legacy_session_id_echo: The contents of the client's legacy_session_id field. Note that this field is echoed even if the client's value corresponded to a cached pre-TLS 1.3 session which the server has chosen not to resume. A client which receives a legacy_session_id_echo field that does not match what it sent in the ClientHello MUST abort the handshake with an "illegal_parameter" alert.
legacy_session_id_echo：クライアントのlegacy_session_idフィールドの内容。 クライアントの値が、サーバーが再開しないことを選択したキャッシュされたTLS 1.3以前のセッションに対応していても、このフィールドはエコーされることに注意してください。 ClientHelloで送信したものと一致しないlegacy_session_id_echoフィールドを受信したクライアントは、「illegal_parameter」アラートでハンドシェイクを中止する必要があります。
cipher_suite: The single cipher suite selected by the server from the list in ClientHello.cipher_suites. A client which receives a cipher suite that was not offered MUST abort the handshake with an "illegal_parameter" alert.
cipher_suite：ClientHello.cipher_suitesのリストからサーバーによって選択された単一の暗号スイート。 提供されなかった暗号スイートを受け取るクライアントは、「illegal_parameter」アラートでハンドシェイクを中止しなければなりません。
legacy_compression_method: A single byte which MUST have the value 0.
legacy_compression_method：値0を持つ必要がある単一バイト。
extensions: A list of extensions. The ServerHello MUST only include extensions which are required to establish the cryptographic context and negotiate the protocol version. All TLS 1.3 ServerHello messages MUST contain the "supported_versions" extension. Current ServerHello messages additionally contain either the "pre_shared_key" extension or the "key_share" extension, or both (when using a PSK with (EC)DHE key establishment). Other extensions (see Section 4.2) are sent separately in the EncryptedExtensions message.
extensions：拡張機能のリスト。 ServerHelloには、暗号化コンテキストを確立し、プロトコルバージョンをネゴシエートするために必要な拡張のみを含める必要があります。 すべてのTLS 1.3 ServerHelloメッセージには、「supported_versions」拡張子を含める必要があります。 現在のServerHelloメッセージには、「pre_shared_key」拡張機能または「key_share」拡張機能のいずれか、または両方が含まれます（PSKを（EC）DHEキー確立で使用する場合）。 他の拡張機能（セクション4.2を参照）は、EncryptedExtensionsメッセージで個別に送信されます。
For reasons of backward compatibility with middleboxes (see Appendix D.4), the HelloRetryRequest message uses the same structure as the ServerHello, but with Random set to the special value of the SHA-256 of "HelloRetryRequest":
ミドルボックスとの下位互換性のため（付録D.4を参照）、HelloRetryRequestメッセージはServerHelloと同じ構造を使用しますが、Randomは「HelloRetryRequest」のSHA-256の特別な値に設定されます。
CF 21 AD 74 E5 9A 61 11 BE 1D 8C 02 1E 65 B8 91
C2 A2 11 16 7A BB 8C 5E 07 9E 09 E2 C8 A8 33 9C
Upon receiving a message with type server_hello, implementations MUST first examine the Random value and, if it matches this value, process it as described in Section 4.1.4).
タイプserver_helloのメッセージを受信すると、実装は最初にRandom値を調べ、この値に一致する場合、セクション4.1.4で説明されているように処理する必要があります。
TLS 1.3 has a downgrade protection mechanism embedded in the server's random value. TLS 1.3 servers which negotiate TLS 1.2 or below in response to a ClientHello MUST set the last 8 bytes of their Random value specially in their ServerHello.
TLS 1.3には、サーバーのランダム値に埋め込まれたダウングレード保護メカニズムがあります。 ClientHelloに応答してTLS 1.2以下をネゴシエートするTLS 1.3サーバーは、ServerHelloでランダム値の最後の8バイトを特別に設定する必要があります。
If negotiating TLS 1.2, TLS 1.3 servers MUST set the last 8 bytes of their Random value to the bytes:
TLS 1.2をネゴシエートする場合、TLS 1.3サーバーは、ランダム値の最後の8バイトをバイトに設定する必要があります。
44 4F 57 4E 47 52 44 01
If negotiating TLS 1.1 or below, TLS 1.3 servers MUST, and TLS 1.2 servers SHOULD, set the last 8 bytes of their ServerHello.Random value to the bytes:
TLS 1.1以下をネゴシエートする場合、TLS 1.3サーバーは必須であり、TLS 1.2サーバーは、ServerHello.Random値の最後の8バイトをバイトに設定する必要があります（SHOULD）。
44 4F 57 4E 47 52 44 00
TLS 1.3 clients receiving a ServerHello indicating TLS 1.2 or below MUST check that the last 8 bytes are not equal to either of these values. TLS 1.2 clients SHOULD also check that the last 8 bytes are not equal to the second value if the ServerHello indicates TLS 1.1 or below. If a match is found, the client MUST abort the handshake with an "illegal_parameter" alert. This mechanism provides limited protection against downgrade attacks over and above what is provided by the Finished exchange: because the ServerKeyExchange, a message present in TLS 1.2 and below, includes a signature over both random values, it is not possible for an active attacker to modify the random values without detection as long as ephemeral ciphers are used. It does not provide downgrade protection when static RSA is used.
TLS 1.2以下を示すServerHelloを受信するTLS 1.3クライアントは、最後の8バイトがこれらの値のいずれとも等しくないことを確認する必要があります。 TLS 1.2クライアントは、ServerHelloがTLS 1.1以下を示している場合、最後の8バイトが2番目の値と等しくないことも確認する必要があります。 一致が見つかった場合、クライアントは「illegal_parameter」アラートでハンドシェイクを中止する必要があります。 このメカニズムは、Finished Exchangeが提供するもの以上のダウングレード攻撃に対する限定的な保護を提供します：ServerKeyExchange（TLS 1.2以下に存在するメッセージ）には両方のランダムな値に対する署名が含まれているため、アクティブな攻撃者が変更することはできません はかない暗号が使用されている限り、検出されないランダムな値。 静的RSAが使用されている場合、ダウングレード保護は提供されません。
Note: This is a change from [RFC5246], so in practice many TLS 1.2 clients and servers will not behave as specified above.
注：これは[RFC5246]からの変更であるため、実際には多くのTLS 1.2クライアントおよびサーバーは上記のように動作しません。
A legacy TLS client performing renegotiation with TLS 1.2 or prior and which receives a TLS 1.3 ServerHello during renegotiation MUST abort the handshake with a "protocol_version" alert. Note that renegotiation is not possible when TLS 1.3 has been negotiated.
TLS 1.2以前で再ネゴシエーションを実行し、再ネゴシエーション中にTLS 1.3 ServerHelloを受信するレガシーTLSクライアントは、「protocol_version」アラートでハンドシェイクを中止しなければなりません。 TLS 1.3がネゴシエートされた場合、再ネゴシエーションは不可能であることに注意してください。
The server will send this message in response to a ClientHello message if it is able to find an acceptable set of parameters but the ClientHello does not contain sufficient information to proceed with the handshake. As discussed in Section 4.1.3, the HelloRetryRequest has the same format as a ServerHello message, and the legacy_version, legacy_session_id_echo, cipher_suite, and legacy_compression_method fields have the same meaning. However, for convenience we discuss "HelloRetryRequest" throughout this document as if it were a distinct message.
サーバーは、許容可能なパラメーターセットを見つけることができるが、ClientHelloにハンドシェイクを続行するための十分な情報が含まれていない場合、ClientHelloメッセージへの応答としてこのメッセージを送信します。 セクション4.1.3で説明したように、HelloRetryRequestの形式はServerHelloメッセージと同じで、legacy_version、legacy_session_id_echo、cipher_suite、およびlegacy_compression_methodフィールドの意味は同じです。 ただし、便宜上、このドキュメント全体で「HelloRetryRequest」を個別のメッセージであるかのように説明します。
The server's extensions MUST contain "supported_versions". Additionally, it SHOULD contain the minimal set of extensions necessary for the client to generate a correct ClientHello pair. As with the ServerHello, a HelloRetryRequest MUST NOT contain any extensions that were not first offered by the client in its ClientHello, with the exception of optionally the "cookie" (see Section 4.2.2) extension.
サーバーの拡張機能には、「supported_versions」を含める必要があります。 さらに、クライアントが正しいClientHelloペアを生成するために必要な拡張機能の最小限のセットを含める必要があります。 ServerHelloと同様に、HelloRetryRequestには、オプションで「cookie」（セクション4.2.2を参照）拡張を除き、ClientHelloでクライアントによって最初に提供されなかった拡張を含めることはできません。
Upon receipt of a HelloRetryRequest, the client MUST check the legacy_version, legacy_session_id_echo, cipher_suite, and legacy_compression_method as specified in Section 4.1.3 and then process the extensions, starting with determining the version using "supported_versions". Clients MUST abort the handshake with an "illegal_parameter" alert if the HelloRetryRequest would not result in any change in the ClientHello. If a client receives a second HelloRetryRequest in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest), it MUST abort the handshake with an "unexpected_message" alert.
HelloRetryRequestを受信したクライアントは、セクション4.1.3で指定されているlegacy_version、legacy_session_id_echo、cipher_suite、およびlegacy_compression_methodを確認し、「supported_versions」を使用してバージョンを判断することから始めて、拡張機能を処理する必要があります。 HelloRetryRequestによってClientHelloが変更されない場合、クライアントは「illegal_parameter」アラートでハンドシェイクを中止する必要があります。 クライアントが同じ接続で2番目のHelloRetryRequestを受信した場合（つまり、ClientHelloがHelloRetryRequestへの応答としてそれ自体であった場合）、「unexpected_message」アラートでハンドシェイクを中止する必要があります。
Otherwise, the client MUST process all extensions in the HelloRetryRequest and send a second updated ClientHello. The HelloRetryRequest extensions defined in this specification are:
それ以外の場合、クライアントはHelloRetryRequestのすべての拡張機能を処理し、2番目に更新されたClientHelloを送信する必要があります。 この仕様で定義されているHelloRetryRequest拡張機能は次のとおりです。
- supported_versions (see Section 4.2.1)
- supported_versions（セクション4.2.1を参照）
- cookie (see Section 4.2.2)
- Cookie（セクション4.2.2を参照）
- key_share (see Section 4.2.8)
- key_share（セクション4.2.8を参照）
A client which receives a cipher suite that was not offered MUST abort the handshake. Servers MUST ensure that they negotiate the same cipher suite when receiving a conformant updated ClientHello (if the server selects the cipher suite as the first step in the negotiation, then this will happen automatically). Upon receiving the ServerHello, clients MUST check that the cipher suite supplied in the ServerHello is the same as that in the HelloRetryRequest and otherwise abort the handshake with an "illegal_parameter" alert.
提供されなかった暗号スイートを受信したクライアントは、ハンドシェイクを中止しなければなりません。 サーバーは、適合した更新済みClientHelloを受信するときに、同じ暗号スイートをネゴシエートすることを確認する必要があります（サーバーがネゴシエーションの最初のステップとして暗号スイートを選択した場合、これは自動的に行われます）。 ServerHelloを受信すると、クライアントは、ServerHelloで提供される暗号スイートがHelloRetryRequestの暗号スイートと同じであることを確認する必要があります。そうでなければ、「illegal_parameter」アラートでハンドシェイクを中止します。
In addition, in its updated ClientHello, the client SHOULD NOT offer any pre-shared keys associated with a hash other than that of the selected cipher suite. This allows the client to avoid having to compute partial hash transcripts for multiple hashes in the second ClientHello.
さらに、更新されたClientHelloでは、クライアントは、選択した暗号スイートのハッシュ以外のハッシュに関連付けられた事前共有キーを提供するべきではありません。 これにより、クライアントは2番目のClientHelloで複数のハッシュの部分的なハッシュトランスクリプトを計算する必要がなくなります。
The value of selected_version in the HelloRetryRequest "supported_versions" extension MUST be retained in the ServerHello, and a client MUST abort the handshake with an "illegal_parameter" alert if the value changes.
HelloRetryRequest "supported_versions"拡張のselected_versionの値はServerHelloに保持されなければならず、値が変更された場合、クライアントは "illegal_parameter"アラートでハンドシェイクを中止しなければなりません。
A number of TLS messages contain tag-length-value encoded extensions structures.
多くのTLSメッセージには、タグ長値エンコードされた拡張構造が含まれています。
struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
enum {
server_name(0), /* RFC 6066 */
max_fragment_length(1), /* RFC 6066 */
status_request(5), /* RFC 6066 */
supported_groups(10), /* RFC 8422, 7919 */
signature_algorithms(13), /* RFC 8446 */
use_srtp(14), /* RFC 5764 */
heartbeat(15), /* RFC 6520 */
application_layer_protocol_negotiation(16), /* RFC 7301 */
signed_certificate_timestamp(18), /* RFC 6962 */
client_certificate_type(19), /* RFC 7250 */
server_certificate_type(20), /* RFC 7250 */
padding(21), /* RFC 7685 */
pre_shared_key(41), /* RFC 8446 */
early_data(42), /* RFC 8446 */
supported_versions(43), /* RFC 8446 */
cookie(44), /* RFC 8446 */
psk_key_exchange_modes(45), /* RFC 8446 */
certificate_authorities(47), /* RFC 8446 */
oid_filters(48), /* RFC 8446 */
post_handshake_auth(49), /* RFC 8446 */
signature_algorithms_cert(50), /* RFC 8446 */
key_share(51), /* RFC 8446 */
(65535)
} ExtensionType;
Here:
ここで：
- "extension_type" identifies the particular extension type.
-「extension_type」は、特定の拡張タイプを識別します。
- "extension_data" contains information specific to the particular extension type.
-「extension_data」には、特定の拡張機能タイプに固有の情報が含まれます。
The list of extension types is maintained by IANA as described in Section 11.
セクション11で説明されるように、拡張タイプのリストはIANAによって維持されます。
Extensions are generally structured in a request/response fashion, though some extensions are just indications with no corresponding response. The client sends its extension requests in the ClientHello message, and the server sends its extension responses in the ServerHello, EncryptedExtensions, HelloRetryRequest, and Certificate messages. The server sends extension requests in the CertificateRequest message which a client MAY respond to with a Certificate message. The server MAY also send unsolicited extensions in the NewSessionTicket, though the client does not respond directly to these.
拡張機能は通常、要求/応答形式で構成されますが、一部の拡張機能は、対応する応答のない単なる指標です。 クライアントはClientHelloメッセージで拡張要求を送信し、サーバーはServerHello、EncryptedExtensions、HelloRetryRequest、およびCertificateメッセージで拡張応答を送信します。 サーバーは、CertificateRequestメッセージで拡張要求を送信し、クライアントは証明書メッセージで応答する場合があります。 サーバーは、要求されていない拡張機能をNewSessionTicketで送信することもできますが、クライアントはこれらに直接応答しません。
Implementations MUST NOT send extension responses if the remote endpoint did not send the corresponding extension requests, with the exception of the "cookie" extension in the HelloRetryRequest. Upon receiving such an extension, an endpoint MUST abort the handshake with an "unsupported_extension" alert.
リモートエンドポイントが対応する拡張要求を送信しなかった場合、HelloRetryRequestの「cookie」拡張を除き、実装は拡張応答を送信してはなりません。 このような拡張機能を受信すると、エンドポイントは「unsupported_extension」アラートでハンドシェイクを中止する必要があります。
The table below indicates the messages where a given extension may appear, using the following notation: CH (ClientHello), SH (ServerHello), EE (EncryptedExtensions), CT (Certificate), CR (CertificateRequest), NST (NewSessionTicket), and HRR (HelloRetryRequest). If an implementation receives an extension which it recognizes and which is not specified for the message in which it appears, it MUST abort the handshake with an "illegal_parameter" alert.
次の表は、CH（ClientHello）、SH（ServerHello）、EE（EncryptedExtensions）、CT（Certificate）、CR（CertificateRequest）、NST（NewSessionTicket）、およびHRRの表記を使用して、特定の拡張機能が表示される可能性があるメッセージを示しています （HelloRetryRequest）。 実装が認識し、出現するメッセージに指定されていない拡張機能を受け取った場合、「illegal_parameter」アラートでハンドシェイクを中止する必要があります。
+--------------------------------------------------+-------------+
| Extension | TLS 1.3 |
+--------------------------------------------------+-------------+
| server_name [RFC6066] | CH, EE |
| | |
| max_fragment_length [RFC6066] | CH, EE |
| | |
| status_request [RFC6066] | CH, CR, CT |
| | |
| supported_groups [RFC7919] | CH, EE |
| | |
| signature_algorithms (RFC 8446) | CH, CR |
| | |
| use_srtp [RFC5764] | CH, EE |
| | |
| heartbeat [RFC6520] | CH, EE |
| | |
| application_layer_protocol_negotiation [RFC7301] | CH, EE |
| | |
| signed_certificate_timestamp [RFC6962] | CH, CR, CT |
| | |
| client_certificate_type [RFC7250] | CH, EE |
| | |
| server_certificate_type [RFC7250] | CH, EE |
| | |
| padding [RFC7685] | CH |
| | |
| key_share (RFC 8446) | CH, SH, HRR |
| | |
| pre_shared_key (RFC 8446) | CH, SH |
| | |
| psk_key_exchange_modes (RFC 8446) | CH |
| | |
| early_data (RFC 8446) | CH, EE, NST |
| | |
| cookie (RFC 8446) | CH, HRR |
| | |
| supported_versions (RFC 8446) | CH, SH, HRR |
| | |
| certificate_authorities (RFC 8446) | CH, CR |
| | |
| oid_filters (RFC 8446) | CR |
| | |
| post_handshake_auth (RFC 8446) | CH |
| | |
| signature_algorithms_cert (RFC 8446) | CH, CR |
+--------------------------------------------------+-------------+
When multiple extensions of different types are present, the extensions MAY appear in any order, with the exception of "pre_shared_key" (Section 4.2.11) which MUST be the last extension in the ClientHello (but can appear anywhere in the ServerHello extensions block). There MUST NOT be more than one extension of the same type in a given extension block.
異なるタイプの複数の拡張機能が存在する場合、ClientHelloの最後の拡張機能である必要がある「pre_shared_key」（セクション4.2.11）を除き、拡張機能は任意の順序で表示できます（ただし、ServerHello拡張機能ブロックのどこにでも表示できます） 。 特定の拡張ブロックに同じタイプの拡張が複数あってはなりません。
In TLS 1.3, unlike TLS 1.2, extensions are negotiated for each handshake even when in resumption-PSK mode. However, 0-RTT parameters are those negotiated in the previous handshake; mismatches may require rejecting 0-RTT (see Section 4.2.10).
TLS 1.2とは異なり、TLS 1.3では、再開PSKモードであっても、ハンドシェイクごとに拡張機能がネゴシエートされます。 ただし、0-RTTパラメーターは、前のハンドシェイクでネゴシエートされたパラメーターです。 不一致の場合、0-RTTの拒否が必要になる場合があります（セクション4.2.10を参照）。
There are subtle (and not so subtle) interactions that may occur in this protocol between new features and existing features which may result in a significant reduction in overall security. The following considerations should be taken into account when designing new extensions:
このプロトコルでは、新しい機能と既存の機能の間で微妙な（それほど微妙ではない）相互作用が発生し、全体的なセキュリティが大幅に低下する可能性があります。 新しい拡張機能を設計するときは、次の考慮事項を考慮する必要があります。
- Some cases where a server does not agree to an extension are error conditions (e.g., the handshake cannot continue), and some are simply refusals to support particular features. In general, error alerts should be used for the former and a field in the server extension response for the latter.
- サーバーが拡張機能に同意しない場合はエラー状態（例：ハンドシェイクを継続できない）であり、特定の機能をサポートするための単なる拒否です。 一般に、前者にはエラーアラートを使用し、後者にはサーバーエクステンションレスポンスのフィールドを使用する必要があります。
- Extensions should, as far as possible, be designed to prevent any attack that forces use (or non-use) of a particular feature by manipulation of handshake messages. This principle should be followed regardless of whether the feature is believed to cause a security problem. Often the fact that the extension fields are included in the inputs to the Finished message hashes will be sufficient, but extreme care is needed when the extension changes the meaning of messages sent in the handshake phase. Designers and implementors should be aware of the fact that until the handshake has been authenticated, active attackers can modify messages and insert, remove, or replace extensions.
- 拡張機能は、可能な限り、ハンドシェイクメッセージの操作によって特定の機能の使用（または不使用）を強制する攻撃を防ぐように設計する必要があります。 機能がセキュリティ問題を引き起こすと考えられるかどうかに関係なく、この原則に従う必要があります。 多くの場合、拡張フィールドがFinishedメッセージハッシュへの入力に含まれているという事実で十分ですが、拡張機能がハンドシェイクフェーズで送信されるメッセージの意味を変更する場合は細心の注意が必要です。 設計者と実装者は、ハンドシェイクが認証されるまで、アクティブな攻撃者がメッセージを変更し、拡張機能を挿入、削除、または置換できるという事実を認識する必要があります。
struct {
select (Handshake.msg_type) {
case client_hello:
ProtocolVersion versions<2..254>;
case server_hello: /* and HelloRetryRequest */
ProtocolVersion selected_version;
};
} SupportedVersions;
The "supported_versions" extension is used by the client to indicate which versions of TLS it supports and by the server to indicate which version it is using. The extension contains a list of supported versions in preference order, with the most preferred version first. Implementations of this specification MUST send this extension in the ClientHello containing all versions of TLS which they are prepared to negotiate (for this specification, that means minimally 0x0304, but if previous versions of TLS are allowed to be negotiated, they MUST be present as well).
「supported_versions」拡張機能は、クライアントがサポートするTLSのバージョンを示すために、サーバーが使用しているバージョンを示すために使用されます。 拡張機能には、サポートされているバージョンのリストが優先順に含まれており、最も優先されるバージョンが最初になります。 この仕様の実装は、ネゴシエートする準備ができているすべてのバージョンのTLSを含むClientHelloでこの拡張機能を送信する必要があります（この仕様では、少なくとも0x0304を意味しますが、TLSの以前のバージョンがネゴシエートできる場合、それらも存在しなければなりません（MUST） ）。
If this extension is not present, servers which are compliant with this specification and which also support TLS 1.2 MUST negotiate TLS 1.2 or prior as specified in [RFC5246], even if ClientHello.legacy_version is 0x0304 or later. Servers MAY abort the handshake upon receiving a ClientHello with legacy_version 0x0304 or later.
この拡張が存在しない場合、ClientHello.legacy_versionが0x0304以降であっても、この仕様に準拠し、TLS 1.2もサポートするサーバーは、[RFC5246]で指定されているTLS 1.2以前をネゴシエートしなければなりません。 サーバーは、legacy_version 0x0304以降でClientHelloを受信すると、ハンドシェイクを中止できます。
If this extension is present in the ClientHello, servers MUST NOT use the ClientHello.legacy_version value for version negotiation and MUST use only the "supported_versions" extension to determine client preferences. Servers MUST only select a version of TLS present in that extension and MUST ignore any unknown versions that are present in that extension. Note that this mechanism makes it possible to negotiate a version prior to TLS 1.2 if one side supports a sparse range. Implementations of TLS 1.3 which choose to support prior versions of TLS SHOULD support TLS 1.2. Servers MUST be prepared to receive ClientHellos that include this extension but do not include 0x0304 in the list of versions.
この拡張がClientHelloに存在する場合、サーバーはバージョンネゴシエーションにClientHello.legacy_version値を使用してはならず、「supported_versions」拡張のみを使用してクライアントの設定を決定する必要があります。 サーバーは、その拡張機能に存在するTLSのバージョンのみを選択する必要があり、その拡張機能に存在する不明なバージョンは無視する必要があります。 このメカニズムにより、一方がスパース範囲をサポートしている場合、TLS 1.2より前のバージョンをネゴシエートできることに注意してください。 TLSの以前のバージョンをサポートすることを選択するTLS 1.3の実装は、TLS 1.2をサポートする必要があります。 サーバーは、この拡張子を含むClientHellosを受信する準備ができていなければなりませんが、バージョンのリストに0x0304は含まれていません。
A server which negotiates a version of TLS prior to TLS 1.3 MUST set ServerHello.version and MUST NOT send the "supported_versions" extension. A server which negotiates TLS 1.3 MUST respond by sending a "supported_versions" extension containing the selected version value (0x0304). It MUST set the ServerHello.legacy_version field to 0x0303 (TLS 1.2). Clients MUST check for this extension prior to processing the rest of the ServerHello (although they will have to parse the ServerHello in order to read the extension). If this extension is present, clients MUST ignore the ServerHello.legacy_version value and MUST use only the "supported_versions" extension to determine the selected version. If the "supported_versions" extension in the ServerHello contains a version not offered by the client or contains a version prior to TLS 1.3, the client MUST abort the handshake with an "illegal_parameter" alert.
TLS 1.3より前のバージョンのTLSをネゴシエートするサーバーは、ServerHello.versionを設定する必要があり、「supported_versions」拡張を送信してはなりません。 TLS 1.3をネゴシエートするサーバーは、選択されたバージョン値（0x0304）を含む「supported_versions」拡張機能を送信することによって応答する必要があります。 ServerHello.legacy_versionフィールドを0x0303（TLS 1.2）に設定する必要があります。 クライアントは、ServerHelloの残りを処理する前にこの拡張機能を確認する必要があります（ただし、拡張機能を読み取るにはServerHelloを解析する必要があります）。 この拡張機能が存在する場合、クライアントはServerHello.legacy_version値を無視する必要があり、「supported_versions」拡張機能のみを使用して選択したバージョンを決定する必要があります。 ServerHelloの「supported_versions」拡張機能にクライアントが提供していないバージョンが含まれているか、TLS 1.3より前のバージョンが含まれている場合、クライアントは「illegal_parameter」アラートでハンドシェイクを中止する必要があります。
struct {
opaque cookie<1..2^16-1>;
} Cookie;
Cookies serve two primary purposes:
Cookieは、主に2つの目的に使用されます。
- Allowing the server to force the client to demonstrate reachability at their apparent network address (thus providing a measure of DoS protection). This is primarily useful for non-connection-oriented transports (see [RFC6347] for an example of this).
- サーバーがクライアントに見かけのネットワークアドレスでの到達可能性を強制することを許可する（したがって、DoS保護の手段を提供する）。 これは主に非接続指向のトランスポートに役立ちます（この例については[RFC6347]を参照）。
- Allowing the server to offload state to the client, thus allowing it to send a HelloRetryRequest without storing any state. The server can do this by storing the hash of the ClientHello in the HelloRetryRequest cookie (protected with some suitable integrity protection algorithm).
- サーバーがクライアントに状態をオフロードできるようにするため、状態を保存せずにHelloRetryRequestを送信できます。 サーバーは、ClientHelloのハッシュをHelloRetryRequest Cookie（適切な整合性保護アルゴリズムで保護されている）に保存することでこれを実行できます。
When sending a HelloRetryRequest, the server MAY provide a "cookie" extension to the client (this is an exception to the usual rule that the only extensions that may be sent are those that appear in the ClientHello). When sending the new ClientHello, the client MUST copy the contents of the extension received in the HelloRetryRequest into a "cookie" extension in the new ClientHello. Clients MUST NOT use cookies in their initial ClientHello in subsequent connections.
HelloRetryRequestを送信するとき、サーバーはクライアントに「cookie」拡張機能を提供することができます（これは、送信される可能性がある拡張機能はClientHelloに表示される拡張機能のみであるという通常の規則の例外です）。 新しいClientHelloを送信するとき、クライアントは、HelloRetryRequestで受信した拡張機能の内容を、新しいClientHelloの「cookie」拡張機能にコピーする必要があります。 クライアントは、後続の接続で最初のClientHelloでCookieを使用しないでください。
When a server is operating statelessly, it may receive an unprotected record of type change_cipher_spec between the first and second ClientHello (see Section 5). Since the server is not storing any state, this will appear as if it were the first message to be received. Servers operating statelessly MUST ignore these records.
サーバーがステートレスに動作している場合、最初と2番目のClientHelloの間でchange_cipher_spec型の保護されていないレコードを受信する場合があります（セクション5を参照）。 サーバーは状態を保存していないため、これが最初に受信されるメッセージであるかのように表示されます。 ステートレスに動作するサーバーはこれらのレコードを無視しなければなりません。
TLS 1.3 provides two extensions for indicating which signature algorithms may be used in digital signatures. The "signature_algorithms_cert" extension applies to signatures in certificates, and the "signature_algorithms" extension, which originally appeared in TLS 1.2, applies to signatures in CertificateVerify messages. The keys found in certificates MUST also be of appropriate type for the signature algorithms they are used with. This is a particular issue for RSA keys and PSS signatures, as described below. If no "signature_algorithms_cert" extension is present, then the "signature_algorithms" extension also applies to signatures appearing in certificates. Clients which desire the server to authenticate itself via a certificate MUST send the "signature_algorithms" extension. If a server is authenticating via a certificate and the client has not sent a "signature_algorithms" extension, then the server MUST abort the handshake with a "missing_extension" alert (see Section 9.2).
TLS 1.3は、デジタル署名で使用できる署名アルゴリズムを示す2つの拡張機能を提供します。 「signature_algorithms_cert」拡張機能は証明書の署名に適用され、TLS 1.2で最初に登場した「signature_algorithms」拡張機能は、CertificateVerifyメッセージの署名に適用されます。 証明書で見つかったキーは、使用される署名アルゴリズムに適したタイプでなければなりません。 これは、以下で説明するように、RSAキーとPSS署名の特定の問題です。 「signature_algorithms_cert」拡張機能が存在しない場合、「signature_algorithms」拡張機能は、証明書に表示される署名にも適用されます。 サーバーが証明書を介して自身を認証することを望むクライアントは、「signature_algorithms」拡張を送信しなければなりません。 サーバーが証明書を介して認証を行い、クライアントが「signature_algorithms」拡張を送信していない場合、サーバーは「missing_extension」アラートでハンドシェイクを中止しなければなりません（セクション9.2を参照）。
The "signature_algorithms_cert" extension was added to allow implementations which supported different sets of algorithms for certificates and in TLS itself to clearly signal their capabilities. TLS 1.2 implementations SHOULD also process this extension. Implementations which have the same policy in both cases MAY omit the "signature_algorithms_cert" extension.
「signature_algorithms_cert」拡張機能が追加され、証明書およびTLS自体のさまざまなアルゴリズムのセットをサポートする実装がその機能を明確に通知できるようになりました。 TLS 1.2実装は、この拡張機能も処理する必要があります。 どちらの場合も同じポリシーを持つ実装では、「signature_algorithms_cert」拡張機能を省略できます。
The "extension_data" field of these extensions contains a SignatureSchemeList value:
これらの拡張機能の「extension_data」フィールドには、SignatureSchemeList値が含まれています。
enum {
/* RSASSA-PKCS1-v1_5 algorithms */
rsa_pkcs1_sha256(0x0401),
rsa_pkcs1_sha384(0x0501),
rsa_pkcs1_sha512(0x0601),
/* ECDSA algorithms */
ecdsa_secp256r1_sha256(0x0403),
ecdsa_secp384r1_sha384(0x0503),
ecdsa_secp521r1_sha512(0x0603),
/* RSASSA-PSS algorithms with public key OID rsaEncryption */
rsa_pss_rsae_sha256(0x0804),
rsa_pss_rsae_sha384(0x0805),
rsa_pss_rsae_sha512(0x0806),
/* EdDSA algorithms */
ed25519(0x0807),
ed448(0x0808),
/* RSASSA-PSS algorithms with public key OID RSASSA-PSS */
rsa_pss_pss_sha256(0x0809),
rsa_pss_pss_sha384(0x080a),
rsa_pss_pss_sha512(0x080b),
/* Legacy algorithms */
rsa_pkcs1_sha1(0x0201),
ecdsa_sha1(0x0203),
/* Reserved Code Points */
private_use(0xFE00..0xFFFF),
(0xFFFF)
} SignatureScheme;
struct {
SignatureScheme supported_signature_algorithms<2..2^16-2>;
} SignatureSchemeList;
Note: This enum is named "SignatureScheme" because there is already a "SignatureAlgorithm" type in TLS 1.2, which this replaces. We use the term "signature algorithm" throughout the text.
注：この列挙型の名前は「SignatureScheme」です。これは、TLS 1.2に「SignatureAlgorithm」タイプが既に存在するためです。 テキスト全体で「署名アルゴリズム」という用語を使用します。
Each SignatureScheme value lists a single signature algorithm that the client is willing to verify. The values are indicated in descending order of preference. Note that a signature algorithm takes as input an arbitrary-length message, rather than a digest. Algorithms which traditionally act on a digest should be defined in TLS to first hash the input with a specified hash algorithm and then proceed as usual. The code point groups listed above have the following meanings:
各SignatureScheme値には、クライアントが検証を希望する単一の署名アルゴリズムがリストされます。 値は優先順位の降順で示されます。 署名アルゴリズムは、ダイジェストではなく、任意の長さのメッセージを入力として使用することに注意してください。 従来はダイジェストに作用するアルゴリズムをTLSで定義して、指定されたハッシュアルゴリズムで最初に入力をハッシュしてから、通常どおりに続行する必要があります。 上記のコードポイントグループには、次の意味があります。
RSASSA-PKCS1-v1_5 algorithms: Indicates a signature algorithm using RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm as defined in [SHS]. These values refer solely to signatures which appear in certificates (see Section 4.4.2.2) and are not defined for use in signed TLS handshake messages, although they MAY appear in "signature_algorithms" and "signature_algorithms_cert" for backward compatibility with TLS 1.2.
RSASSA-PKCS1-v1_5アルゴリズム：[SASS]で定義された対応するハッシュアルゴリズムとともにRSASSA-PKCS1-v1_5 [RFC8017]を使用する署名アルゴリズムを示します。 これらの値は、証明書（セクション4.4.2.2を参照）に現れる署名のみを参照し、TLS 1.2との後方互換性のために「signature_algorithms」および「signature_algorithms_cert」に現れる場合がありますが、署名付きTLSハンドシェイクメッセージで使用するために定義されていません。
ECDSA algorithms: Indicates a signature algorithm using ECDSA [ECDSA], the corresponding curve as defined in ANSI X9.62 [ECDSA] and FIPS 186-4 [DSS], and the corresponding hash algorithm as defined in [SHS]. The signature is represented as a DER-encoded [X690] ECDSA-Sig-Value structure.
ECDSAアルゴリズム：ECDSA [ECDSA]、ANSI X9.62 [ECDSA]およびFIPS 186-4 [DSS]で定義された対応する曲線、および[SHS]で定義された対応するハッシュアルゴリズムを使用した署名アルゴリズムを示します。 署名は、DERエンコード[X690] ECDSA-Sig-Value構造として表されます。
RSASSA-PSS RSAE algorithms: Indicates a signature algorithm using RSASSA-PSS [RFC8017] with mask generation function 1. The digest used in the mask generation function and the digest being signed are both the corresponding hash algorithm as defined in [SHS]. The length of the Salt MUST be equal to the length of the output of the digest algorithm. If the public key is carried in an X.509 certificate, it MUST use the rsaEncryption OID [RFC5280].
RSASSA-PSS RSAEアルゴリズム：マスク生成機能1でRSASSA-PSS [RFC8017]を使用する署名アルゴリズムを示します。マスク生成機能で使用されるダイジェストと署名されるダイジェストは、両方とも[SHS]で定義された対応するハッシュアルゴリズムです。 ソルトの長さは、ダイジェストアルゴリズムの出力の長さと等しくなければなりません。 公開鍵がX.509証明書で運ばれる場合、rsaEncryption OID [RFC5280]を使用しなければなりません。
EdDSA algorithms: Indicates a signature algorithm using EdDSA as defined in [RFC8032] or its successors. Note that these correspond to the "PureEdDSA" algorithms and not the "prehash" variants.
EdDSAアルゴリズム：[RFC8032]で定義されているEdDSAを使用した署名アルゴリズムまたはその後継を示します。 これらは「prehash」バリアントではなく、「PureEdDSA」アルゴリズムに対応していることに注意してください。
RSASSA-PSS PSS algorithms: Indicates a signature algorithm using RSASSA-PSS [RFC8017] with mask generation function 1. The digest used in the mask generation function and the digest being signed are both the corresponding hash algorithm as defined in [SHS]. The length of the Salt MUST be equal to the length of the digest algorithm. If the public key is carried in an X.509 certificate, it MUST use the RSASSA-PSS OID [RFC5756]. When used in certificate signatures, the algorithm parameters MUST be DER encoded. If the corresponding public key's parameters are present, then the parameters in the signature MUST be identical to those in the public key.
RSASSA-PSS PSSアルゴリズム：RSASSA-PSS [RFC8017]とマスク生成機能1を使用した署名アルゴリズムを示します。マスク生成機能で使用されるダイジェストと署名されるダイジェストは、両方とも[SHS]で定義された対応するハッシュアルゴリズムです。 ソルトの長さは、ダイジェストアルゴリズムの長さと等しくなければなりません。 公開鍵がX.509証明書で運ばれる場合、RSASSA-PSS OID [RFC5756]を使用しなければなりません。 証明書の署名で使用する場合、アルゴリズムパラメータはDERエンコードする必要があります。 対応する公開鍵のパラメータが存在する場合、署名のパラメータは公開鍵のパラメータと同一でなければなりません。
Legacy algorithms: Indicates algorithms which are being deprecated because they use algorithms with known weaknesses, specifically SHA-1 which is used in this context with either (1) RSA using RSASSA-PKCS1-v1_5 or (2) ECDSA. These values refer solely to signatures which appear in certificates (see Section 4.4.2.2) and are not defined for use in signed TLS handshake messages, although they MAY appear in "signature_algorithms" and "signature_algorithms_cert" for backward compatibility with TLS 1.2. Endpoints SHOULD NOT negotiate these algorithms but are permitted to do so solely for backward compatibility. Clients offering these values MUST list them as the lowest priority (listed after all other algorithms in SignatureSchemeList). TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no valid certificate chain can be produced without it (see Section 4.4.2.2).
レガシーアルゴリズム：既知の脆弱性を持つアルゴリズム、具体的には（1）RSASSA-PKCS1-v1_5を使用するRSAまたは（2）ECDSAでこのコンテキストで使用されるSHA-1を使用するため、非推奨のアルゴリズムを示します。 これらの値は、証明書（セクション4.4.2.2を参照）に現れる署名のみを参照し、TLS 1.2との後方互換性のために「signature_algorithms」および「signature_algorithms_cert」に現れる場合がありますが、署名付きTLSハンドシェイクメッセージで使用するために定義されていません。 エンドポイントはこれらのアルゴリズムをネゴシエートするべきではありませんが、下位互換性のためだけにネゴシエートすることが許可されています。 これらの値を提供するクライアントは、それらを最も低い優先度（SignatureSchemeListの他のすべてのアルゴリズムの後にリストされる）としてリストしなければなりません。 TLS 1.3サーバーは、有効な証明書チェーンが作成されない限り、SHA-1署名付き証明書を提供してはなりません（セクション4.4.2.2を参照）。
The signatures on certificates that are self-signed or certificates that are trust anchors are not validated, since they begin a certification path (see [RFC5280], Section 3.2). A certificate that begins a certification path MAY use a signature algorithm that is not advertised as being supported in the "signature_algorithms" extension.
自己署名証明書またはトラストアンカー証明書の署名は、証明書パスを開始するため、検証されません（[RFC5280]、セクション3.2を参照）。 証明書パスを開始する証明書は、「signature_algorithms」拡張機能でサポートされているとしてアドバタイズされていない署名アルゴリズムを使用する場合があります。
Note that TLS 1.2 defines this extension differently. TLS 1.3 implementations willing to negotiate TLS 1.2 MUST behave in accordance with the requirements of [RFC5246] when negotiating that version. In particular:
TLS 1.2はこの拡張を異なる方法で定義することに注意してください。 TLS 1.2をネゴシエートする意思のあるTLS 1.3実装は、そのバージョンをネゴシエートするときに[RFC5246]の要件に従って動作する必要があります。 特に：
- TLS 1.2 ClientHellos MAY omit this extension.
- TLS 1.2 ClientHellosは、この拡張機能を省略できます。
- In TLS 1.2, the extension contained hash/signature pairs. The pairs are encoded in two octets, so SignatureScheme values have been allocated to align with TLS 1.2's encoding. Some legacy pairs are left unallocated. These algorithms are deprecated as of TLS 1.3. They MUST NOT be offered or negotiated by any implementation. In particular, MD5 [SLOTH], SHA-224, and DSA MUST NOT be used.
- TLS 1.2では、拡張機能にハッシュ/署名のペアが含まれていました。 ペアは2オクテットでエンコードされるため、SignatureScheme値はTLS 1.2のエンコードに合わせて割り当てられています。 一部のレガシーペアは未割り当てのままです。 これらのアルゴリズムは、TLS 1.3で非推奨になりました。 実装によって提供または交渉してはなりません。 特に、MD5 [SLOTH]、SHA-224、およびDSAは使用しないでください。
- ECDSA signature schemes align with TLS 1.2's ECDSA hash/signature pairs. However, the old semantics did not constrain the signing curve. If TLS 1.2 is negotiated, implementations MUST be prepared to accept a signature that uses any curve that they advertised in the "supported_groups" extension.
- ECDSA署名スキームは、TLS 1.2のECDSAハッシュ/署名のペアと一致します。 ただし、古いセマンティクスは署名曲線を制約しませんでした。 TLS 1.2がネゴシエートされる場合、「supported_groups」拡張でアドバタイズした曲線を使用する署名を受け入れるように実装を準備する必要があります。
- Implementations that advertise support for RSASSA-PSS (which is mandatory in TLS 1.3) MUST be prepared to accept a signature using that scheme even when TLS 1.2 is negotiated. In TLS 1.2, RSASSA-PSS is used with RSA cipher suites.
- RSASSA-PSS（TLS 1.3では必須です）のサポートをアドバタイズする実装は、TLS 1.2がネゴシエートされる場合でも、そのスキームを使用して署名を受け入れるように準備する必要があります。 TLS 1.2では、RSASA暗号スイートでRSASSA-PSSが使用されます。
The "certificate_authorities" extension is used to indicate the certificate authorities (CAs) which an endpoint supports and which SHOULD be used by the receiving endpoint to guide certificate selection.
「certificate_authorities」拡張は、エンドポイントがサポートする認証局（CA）を示すために使用され、証明書の選択をガイドするために受信エンドポイントによって使用される必要があります。
The body of the "certificate_authorities" extension consists of a CertificateAuthoritiesExtension structure.
「certificate_authorities」拡張の本体は、CertificateAuthoritiesExtension構造で構成されます。
opaque DistinguishedName<1..2^16-1>;
struct {
DistinguishedName authorities<3..2^16-1>;
} CertificateAuthoritiesExtension;
authorities: A list of the distinguished names [X501] of acceptable certificate authorities, represented in DER-encoded [X690] format. These distinguished names specify a desired distinguished name for a trust anchor or subordinate CA; thus, this message can be used to describe known trust anchors as well as a desired authorization space.
authorities：DERエンコード[X690]形式で表される、受け入れ可能な認証機関の識別名[X501]のリスト。 これらの識別名は、トラストアンカーまたは下位CAに必要な識別名を指定します。 したがって、このメッセージを使用して、既知のトラストアンカーと目的の承認スペースを説明できます。
The client MAY send the "certificate_authorities" extension in the ClientHello message. The server MAY send it in the CertificateRequest message.
クライアントは、ClientHelloメッセージで「certificate_authorities」拡張機能を送信する場合があります。 サーバーは、それをCertificateRequestメッセージで送信する場合があります。
The "trusted_ca_keys" extension [RFC6066], which serves a similar purpose but is more complicated, is not used in TLS 1.3 (although it may appear in ClientHello messages from clients which are offering prior versions of TLS).
「trusted_ca_keys」拡張機能[RFC6066]は、同様の目的を果たしますが、より複雑ですが、TLS 1.3では使用されません（以前のバージョンのTLSを提供しているクライアントからのClientHelloメッセージに表示される場合があります）。
The "oid_filters" extension allows servers to provide a set of OID/value pairs which it would like the client's certificate to match. This extension, if provided by the server, MUST only be sent in the CertificateRequest message.
「oid_filters」拡張機能を使用すると、サーバーは、クライアントの証明書と一致させる一連のOID /値ペアを提供できます。 この拡張機能は、サーバーによって提供される場合、CertificateRequestメッセージでのみ送信する必要があります。
struct {
opaque certificate_extension_oid<1..2^8-1>;
opaque certificate_extension_values<0..2^16-1>;
} OIDFilter;
struct {
OIDFilter filters<0..2^16-1>;
} OIDFilterExtension;
filters: A list of certificate extension OIDs [RFC5280] with their allowed value(s) and represented in DER-encoded [X690] format. Some certificate extension OIDs allow multiple values (e.g., Extended Key Usage). If the server has included a non-empty filters list, the client certificate included in the response MUST contain all of the specified extension OIDs that the client recognizes. For each extension OID recognized by the client, all of the specified values MUST be present in the client certificate (but the certificate MAY have other values as well). However, the client MUST ignore and skip any unrecognized certificate extension OIDs. If the client ignored some of the required certificate extension OIDs and supplied a certificate that does not satisfy the request, the server MAY at its discretion either continue the connection without client authentication or abort the handshake with an "unsupported_certificate" alert. Any given OID MUST NOT appear more than once in the filters list.
フィルター：証明書拡張OID [RFC5280]とその許容値のリストで、DERエンコード[X690]形式で表されます。一部の証明書拡張OIDでは、複数の値が許可されています（例：拡張キー使用法）。サーバーに空でないフィルターリストが含まれている場合、応答に含まれるクライアント証明書には、クライアントが認識する指定された拡張OIDがすべて含まれている必要があります。クライアントによって認識される各拡張OIDについて、指定されたすべての値がクライアント証明書に存在する必要があります（ただし、証明書には他の値もある場合があります）。ただし、クライアントは、認識されていない証明書拡張OIDを無視してスキップする必要があります。クライアントが必要な証明書拡張OIDの一部を無視し、要求を満たさない証明書を提供した場合、サーバーはその裁量でクライアント認証なしで接続を続行するか、「unsupported_certificate」アラートでハンドシェイクを中止できます。指定されたOIDは、フィルターリストに複数回表示してはなりません。
PKIX RFCs define a variety of certificate extension OIDs and their corresponding value types. Depending on the type, matching certificate extension values are not necessarily bitwise-equal. It is expected that TLS implementations will rely on their PKI libraries to perform certificate selection using certificate extension OIDs.
PKIX RFCは、さまざまな証明書拡張OIDとそれに対応する値タイプを定義します。 タイプによっては、一致する証明書拡張値は必ずしもビットごとに等しいとは限りません。 TLS実装は、証明書拡張OIDを使用して証明書選択を実行するためにPKIライブラリに依存することが予想されます。
This document defines matching rules for two standard certificate extensions defined in [RFC5280]:
このドキュメントは、[RFC5280]で定義された2つの標準証明書拡張のマッチングルールを定義します。
- The Key Usage extension in a certificate matches the request when all key usage bits asserted in the request are also asserted in the Key Usage certificate extension.
- 要求でアサートされたすべてのキー使用ビットがキー使用証明書拡張でもアサートされている場合、証明書のキー使用拡張はリクエストと一致します。
- The Extended Key Usage extension in a certificate matches the request when all key purpose OIDs present in the request are also found in the Extended Key Usage certificate extension. The special anyExtendedKeyUsage OID MUST NOT be used in the request.
- 証明書内の拡張キー使用法拡張機能は、要求に含まれるすべてのキー目的OIDが拡張キー使用法証明書拡張機能でも見つかった場合、要求と一致します。 特別なanyExtendedKeyUsage OIDをリクエストで使用してはなりません。
Separate specifications may define matching rules for other certificate extensions.
別の仕様では、他の証明書拡張機能のマッチングルールを定義できます。
The "post_handshake_auth" extension is used to indicate that a client is willing to perform post-handshake authentication (Section 4.6.2). Servers MUST NOT send a post-handshake CertificateRequest to clients which do not offer this extension. Servers MUST NOT send this extension.
「post_handshake_auth」拡張機能は、クライアントがポストハンドシェイク認証を実行する意思があることを示すために使用されます（セクション4.6.2）。 サーバーは、この拡張機能を提供しないクライアントにハンドシェイク後のCertificateRequestを送信してはなりません。 サーバーはこの拡張機能を送信してはなりません。
struct {} PostHandshakeAuth;
The "extension_data" field of the "post_handshake_auth" extension is zero length.
「post_handshake_auth」拡張機能の「extension_data」フィールドの長さはゼロです。
When sent by the client, the "supported_groups" extension indicates the named groups which the client supports for key exchange, ordered from most preferred to least preferred.
クライアントによって送信される場合、「supported_groups」拡張機能は、クライアントがキー交換のためにサポートする名前付きグループを、最も優先度の高いものから最も優先度の低いものの順に示します。
Note: In versions of TLS prior to TLS 1.3, this extension was named "elliptic_curves" and only contained elliptic curve groups. See [RFC8422] and [RFC7919]. This extension was also used to negotiate ECDSA curves. Signature algorithms are now negotiated independently (see Section 4.2.3).
注：TLS 1.3より前のTLSのバージョンでは、この拡張機能は「elliptic_curves」という名前で、楕円曲線グループのみが含まれていました。 [RFC8422]および[RFC7919]を参照してください。 この拡張は、ECDSA曲線のネゴシエートにも使用されました。 署名アルゴリズムは、個別にネゴシエートされるようになりました（セクション4.2.3を参照）。
The "extension_data" field of this extension contains a "NamedGroupList" value:
この拡張機能の「extension_data」フィールドには、「NamedGroupList」値が含まれます。
enum {
/* Elliptic Curve Groups (ECDHE) */
secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019),
x25519(0x001D), x448(0x001E),
/* Finite Field Groups (DHE) */
ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102),
ffdhe6144(0x0103), ffdhe8192(0x0104),
/* Reserved Code Points */
ffdhe_private_use(0x01FC..0x01FF),
ecdhe_private_use(0xFE00..0xFEFF),
(0xFFFF)
} NamedGroup;
struct {
NamedGroup named_group_list<2..2^16-1>;
} NamedGroupList;
Elliptic Curve Groups (ECDHE): Indicates support for the corresponding named curve, defined in either FIPS 186-4 [DSS] or [RFC7748]. Values 0xFE00 through 0xFEFF are reserved for Private Use [RFC8126].
楕円曲線グループ（ECDHE）：FIPS 186-4 [DSS]または[RFC7748]で定義されている、対応する名前付き曲線のサポートを示します。 値0xFE00〜0xFEFFは、プライベート使用のために予約されています[RFC8126]。
Finite Field Groups (DHE): Indicates support for the corresponding finite field group, defined in [RFC7919]. Values 0x01FC through 0x01FF are reserved for Private Use.
有限フィールドグループ（DHE）：[RFC7919]で定義されている、対応する有限フィールドグループのサポートを示します。 値0x01FCから0x01FFは、プライベート使用のために予約されています。
Items in named_group_list are ordered according to the sender's preferences (most preferred choice first).
named_group_listの項目は、送信者の設定に従って順序付けられます（最も優先される選択肢が最初）。
As of TLS 1.3, servers are permitted to send the "supported_groups" extension to the client. Clients MUST NOT act upon any information found in "supported_groups" prior to successful completion of the handshake but MAY use the information learned from a successfully completed handshake to change what groups they use in their "key_share" extension in subsequent connections. If the server has a group it prefers to the ones in the "key_share" extension but is still willing to accept the ClientHello, it SHOULD send "supported_groups" to update the client's view of its preferences; this extension SHOULD contain all groups the server supports, regardless of whether they are currently supported by the client.
TLS 1.3以降、サーバーは「supported_groups」拡張機能をクライアントに送信できます。 クライアントは、ハンドシェイクが正常に完了する前に「supported_groups」で見つかった情報に基づいて行動してはなりませんが、正常に完了したハンドシェイクから学習した情報を使用して、後続の接続の「key_share」拡張で使用するグループを変更することができます。 サーバーに「key_share」拡張子のグループよりも優先されるが、ClientHelloを受け入れる意思があるグループがある場合、「supported_groups」を送信してクライアントの設定のビューを更新する必要があります。 この拡張は、クライアントが現在サポートしているかどうかにかかわらず、サーバーがサポートするすべてのグループを含む必要があります。
The "key_share" extension contains the endpoint's cryptographic parameters.
「key_share」拡張には、エンドポイントの暗号化パラメーターが含まれます。
Clients MAY send an empty client_shares vector in order to request group selection from the server, at the cost of an additional round trip (see Section 4.1.4).
クライアントは、追加の往復の費用で、サーバーからのグループ選択を要求するために空のclient_sharesベクトルを送信することができます（セクション4.1.4を参照）。
struct {
NamedGroup group;
opaque key_exchange<1..2^16-1>;
} KeyShareEntry;
group: The named group for the key being exchanged.
group：交換されるキーの名前付きグループ。
key_exchange: Key exchange information. The contents of this field are determined by the specified group and its corresponding definition. Finite Field Diffie-Hellman [DH76] parameters are described in Section 4.2.8.1; Elliptic Curve Diffie-Hellman parameters are described in Section 4.2.8.2.
key_exchange：鍵交換情報。 このフィールドの内容は、指定されたグループとそれに対応する定義によって決定されます。 有限フィールドDiffie-Hellman [DH76]パラメータについては、セクション4.2.8.1で説明しています。 楕円曲線Diffie-Hellmanパラメーターについては、セクション4.2.8.2で説明しています。
In the ClientHello message, the "extension_data" field of this extension contains a "KeyShareClientHello" value:
ClientHelloメッセージでは、この拡張機能の「extension_data」フィールドに「KeyShareClientHello」値が含まれています。
struct {
KeyShareEntry client_shares<0..2^16-1>;
} KeyShareClientHello;
client_shares: A list of offered KeyShareEntry values in descending order of client preference.
client_shares：クライアント設定の降順で提供されるKeyShareEntry値のリスト。
This vector MAY be empty if the client is requesting a HelloRetryRequest. Each KeyShareEntry value MUST correspond to a group offered in the "supported_groups" extension and MUST appear in the same order. However, the values MAY be a non-contiguous subset of the "supported_groups" extension and MAY omit the most preferred groups. Such a situation could arise if the most preferred groups are new and unlikely to be supported in enough places to make pregenerating key shares for them efficient.
クライアントがHelloRetryRequestを要求している場合、このベクトルは空の場合があります。 各KeyShareEntry値は、「supported_groups」拡張で提供されるグループに対応しなければならず、同じ順序で表示されなければなりません。 ただし、値は「supported_groups」拡張の不連続なサブセットである場合があり、最も優先されるグループを省略する場合があります。 そのような状況は、最も優先されるグループが新しく、それらのキー共有を効率的に事前生成するのに十分な場所でサポートされる可能性が低い場合に発生する可能性があります。
Clients can offer as many KeyShareEntry values as the number of supported groups it is offering, each representing a single set of key exchange parameters. For instance, a client might offer shares for several elliptic curves or multiple FFDHE groups. The key_exchange values for each KeyShareEntry MUST be generated independently. Clients MUST NOT offer multiple KeyShareEntry values for the same group. Clients MUST NOT offer any KeyShareEntry values for groups not listed in the client's "supported_groups" extension. Servers MAY check for violations of these rules and abort the handshake with an "illegal_parameter" alert if one is violated.
クライアントは、提供するサポートされているグループの数と同じ数のKeyShareEntry値を提供できます。各値は、鍵交換パラメーターの単一セットを表します。 たとえば、クライアントは複数の楕円曲線または複数のFFDHEグループの共有を提供する場合があります。 各KeyShareEntryのkey_exchange値は、個別に生成する必要があります。 クライアントは、同じグループに対して複数のKeyShareEntry値を提供してはなりません。 クライアントは、クライアントの「supported_groups」拡張にリストされていないグループにKeyShareEntry値を提供してはなりません。 サーバーは、これらのルールの違反をチェックし、違反がある場合は「illegal_parameter」アラートでハンドシェイクを中止できます。
In a HelloRetryRequest message, the "extension_data" field of this extension contains a KeyShareHelloRetryRequest value:
HelloRetryRequestメッセージでは、この拡張機能の「extension_data」フィールドにKeyShareHelloRetryRequest値が含まれています。
struct {
NamedGroup selected_group;
} KeyShareHelloRetryRequest;
selected_group: The mutually supported group the server intends to negotiate and is requesting a retried ClientHello/KeyShare for.
selected_group：サーバーがネゴシエートしようとし、再試行されたClientHello / KeyShareを要求している相互にサポートされているグループ。
Upon receipt of this extension in a HelloRetryRequest, the client MUST verify that (1) the selected_group field corresponds to a group which was provided in the "supported_groups" extension in the original ClientHello and (2) the selected_group field does not correspond to a group which was provided in the "key_share" extension in the original ClientHello. If either of these checks fails, then the client MUST abort the handshake with an "illegal_parameter" alert. Otherwise, when sending the new ClientHello, the client MUST replace the original "key_share" extension with one containing only a new KeyShareEntry for the group indicated in the selected_group field of the triggering HelloRetryRequest.
HelloRetryRequestでこの拡張を受信すると、クライアントは、（1）selected_groupフィールドが元のClientHelloの「supported_groups」拡張で提供されたグループに対応し、（2）selected_groupフィールドがグループに対応しないことを確認する必要があります これは、元のClientHelloの「key_share」拡張機能で提供されていました。 これらのチェックのいずれかが失敗した場合、クライアントは「illegal_parameter」アラートでハンドシェイクを中止する必要があります。 それ以外の場合、新しいClientHelloを送信するとき、クライアントは、元の「key_share」拡張を、トリガーHelloRetryRequestのselected_groupフィールドに示されたグループの新しいKeyShareEntryのみを含むものに置き換えなければなりません。
In a ServerHello message, the "extension_data" field of this extension contains a KeyShareServerHello value:
ServerHelloメッセージでは、この拡張機能の「extension_data」フィールドにKeyShareServerHello値が含まれています。
struct {
KeyShareEntry server_share;
} KeyShareServerHello;
server_share: A single KeyShareEntry value that is in the same group as one of the client's shares.
server_share：クライアントの共有の1つと同じグループにある単一のKeyShareEntry値。
If using (EC)DHE key establishment, servers offer exactly one KeyShareEntry in the ServerHello. This value MUST be in the same group as the KeyShareEntry value offered by the client that the server has selected for the negotiated key exchange. Servers MUST NOT send a KeyShareEntry for any group not indicated in the client's "supported_groups" extension and MUST NOT send a KeyShareEntry when using the "psk_ke" PskKeyExchangeMode. If using (EC)DHE key establishment and a HelloRetryRequest containing a "key_share" extension was received by the client, the client MUST verify that the selected NamedGroup in the ServerHello is the same as that in the HelloRetryRequest. If this check fails, the client MUST abort the handshake with an "illegal_parameter" alert.
（EC）DHEキー確立を使用する場合、サーバーはServerHelloでKeyShareEntryを1つだけ提供します。 この値は、サーバーがネゴシエートされたキー交換のために選択したクライアントによって提供されるKeyShareEntry値と同じグループになければなりません。 サーバーは、クライアントの「supported_groups」拡張で示されていないグループに対してKeyShareEntryを送信してはならず、「psk_ke」PskKeyExchangeModeを使用する場合はKeyShareEntryを送信してはなりません。 （EC）DHEキー確立を使用し、クライアントが「key_share」拡張を含むHelloRetryRequestを受信した場合、クライアントは、ServerHelloで選択したNamedGroupがHelloRetryRequestのNamedGroupと同じであることを確認する必要があります。 このチェックが失敗した場合、クライアントは「illegal_parameter」アラートでハンドシェイクを中止する必要があります。
Diffie-Hellman [DH76] parameters for both clients and servers are encoded in the opaque key_exchange field of a KeyShareEntry in a KeyShare structure. The opaque value contains the Diffie-Hellman public value (Y = g^X mod p) for the specified group (see [RFC7919] for group definitions) encoded as a big-endian integer and padded to the left with zeros to the size of p in bytes.
クライアントとサーバーの両方のDiffie-Hellman [DH76]パラメーターは、KeyShare構造のKeyShareEntryの不透明なkey_exchangeフィールドにエンコードされます。 不透明な値には、ビッグエンディアン整数としてエンコードされ、サイズがゼロになるまで左側にゼロが埋め込まれた、指定されたグループ（グループ定義については[RFC7919]を参照）のDiffie-Hellmanパブリック値（Y = g ^ X mod p）が含まれます バイト単位のp。
Note: For a given Diffie-Hellman group, the padding results in all public keys having the same length.
注：特定のDiffie-Hellmanグループでは、パディングにより、すべての公開キーの長さが同じになります。
Peers MUST validate each other's public key Y by ensuring that 1 < Y < p-1. This check ensures that the remote peer is properly behaved and isn't forcing the local system into a small subgroup.
ピアは、1 < Y < p-1であることを確認することにより、互いの公開鍵Yを検証する必要があります。 このチェックにより、リモートピアが適切に動作し、ローカルシステムが小さなサブグループに強制されないことが保証されます。
ECDHE parameters for both clients and servers are encoded in the opaque key_exchange field of a KeyShareEntry in a KeyShare structure.
クライアントとサーバーの両方のECDHEパラメーターは、KeyShare構造のKeyShareEntryの不透明なkey_exchangeフィールドでエンコードされます。
For secp256r1, secp384r1, and secp521r1, the contents are the serialized value of the following struct:
secp256r1、secp384r1、およびsecp521r1の場合、内容は次の構造体のシリアル化された値です。
struct {
uint8 legacy_form = 4;
opaque X[coordinate_length];
opaque Y[coordinate_length];
} UncompressedPointRepresentation;
X and Y, respectively, are the binary representations of the x and y values in network byte order. There are no internal length markers, so each number representation occupies as many octets as implied by the curve parameters. For P-256, this means that each of X and Y use 32 octets, padded on the left by zeros if necessary. For P-384, they take 48 octets each. For P-521, they take 66 octets each.
XとYは、それぞれネットワークバイト順のx値とy値のバイナリ表現です。 内部の長さマーカーはないため、各数値表現は、曲線パラメーターで示されるオクテットと同じ数のオクテットを占有します。 P-256の場合、これはXとYのそれぞれが32オクテットを使用し、必要に応じて左側にゼロが埋め込まれることを意味します。 P-384の場合、それぞれ48オクテットかかります。 P-521の場合、それぞれ66オクテットかかります。
For the curves secp256r1, secp384r1, and secp521r1, peers MUST validate each other's public value Q by ensuring that the point is a valid point on the elliptic curve. The appropriate validation procedures are defined in Section 4.3.7 of [ECDSA] and alternatively in Section 5.6.2.3 of [KEYAGREEMENT]. This process consists of three steps: (1) verify that Q is not the point at infinity (O), (2) verify that for Q = (x, y) both integers x and y are in the correct interval, and (3) ensure that (x, y) is a correct solution to the elliptic curve equation. For these curves, implementors do not need to verify membership in the correct subgroup.
曲線secp256r1、secp384r1、およびsecp521r1について、ピアは、ポイントが楕円曲線上の有効なポイントであることを確認することにより、互いのパブリック値Qを検証する必要があります。 適切な検証手順は、[ECDSA]のセクション4.3.7、または[KEYAGREEMENT]のセクション5.6.2.3で定義されています。 このプロセスは、3つのステップで構成されます。（1）Qが無限大（O）でないことを確認し、（2）Q =（x、y）の整数xとyが両方とも正しい間隔にあることを確認し、 ）（x、y）が楕円曲線方程式の正しい解であることを確認してください。 これらの曲線の場合、実装者は正しいサブグループのメンバーシップを確認する必要はありません。
For X25519 and X448, the contents of the public value are the byte string inputs and outputs of the corresponding functions defined in [RFC7748]: 32 bytes for X25519 and 56 bytes for X448.
X25519およびX448の場合、パブリック値の内容は、[RFC7748]で定義されている対応する関数のバイト文字列入力および出力です。X25519の場合は32バイト、X448の場合は56バイト。
Note: Versions of TLS prior to 1.3 permitted point format negotiation; TLS 1.3 removes this feature in favor of a single point format for each curve.
注：1.3より前のバージョンのTLSでは、ポイント形式のネゴシエーションが許可されていました。 TLS 1.3は、この機能を削除して、各曲線に単一ポイント形式を採用しています。
In order to use PSKs, clients MUST also send a "psk_key_exchange_modes" extension. The semantics of this extension are that the client only supports the use of PSKs with these modes, which restricts both the use of PSKs offered in this ClientHello and those which the server might supply via NewSessionTicket.
PSKを使用するには、クライアントは「psk_key_exchange_modes」拡張機能も送信する必要があります。 この拡張のセマンティクスは、クライアントがこれらのモードでPSKの使用のみをサポートすることです。これにより、このClientHelloで提供されるPSKと、NewSessionTicketを介してサーバーが提供するPSKの使用が制限されます。
A client MUST provide a "psk_key_exchange_modes" extension if it offers a "pre_shared_key" extension. If clients offer "pre_shared_key" without a "psk_key_exchange_modes" extension, servers MUST abort the handshake. Servers MUST NOT select a key exchange mode that is not listed by the client. This extension also restricts the modes for use with PSK resumption. Servers SHOULD NOT send NewSessionTicket with tickets that are not compatible with the advertised modes; however, if a server does so, the impact will just be that the client's attempts at resumption fail.
クライアントは、「pre_shared_key」拡張機能を提供する場合、「psk_key_exchange_modes」拡張機能を提供する必要があります。 クライアントが「psk_key_exchange_modes」拡張機能なしで「pre_shared_key」を提供する場合、サーバーはハンドシェイクを中止する必要があります。 サーバーは、クライアントによってリストされていない鍵交換モードを選択してはなりません。 この拡張機能は、PSK再開で使用するモードも制限します。 サーバーは、アドバタイズされたモードと互換性のないチケットでNewSessionTicketを送信すべきではありません。 ただし、サーバーがこれを行うと、クライアントの再開の試みが失敗するという影響があります。
The server MUST NOT send a "psk_key_exchange_modes" extension.
サーバーは「psk_key_exchange_modes」拡張機能を送信してはなりません。
enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode;
struct {
PskKeyExchangeMode ke_modes<1..255>;
} PskKeyExchangeModes;
psk_ke: PSK-only key establishment. In this mode, the server MUST NOT supply a "key_share" value.
psk_ke：PSKのみのキー確立。 このモードでは、サーバーは「key_share」値を指定してはなりません。
psk_dhe_ke: PSK with (EC)DHE key establishment. In this mode, the client and server MUST supply "key_share" values as described in Section 4.2.8.
psk_dhe_ke：（EC）DHEキーを確立したPSK。 このモードでは、セクション4.2.8で説明されているように、クライアントとサーバーは「key_share」値を提供する必要があります。
Any future values that are allocated must ensure that the transmitted protocol messages unambiguously identify which mode was selected by the server; at present, this is indicated by the presence of the "key_share" in the ServerHello.
割り当てられる将来の値は、送信されたプロトコルメッセージがサーバーによって選択されたモードを明確に識別することを保証する必要があります。 現在、これはServerHelloの「key_share」の存在によって示されます。
When a PSK is used and early data is allowed for that PSK, the client can send Application Data in its first flight of messages. If the client opts to do so, it MUST supply both the "pre_shared_key" and "early_data" extensions.
PSKが使用され、そのPSKの初期データが許可されている場合、クライアントはメッセージの最初のフライトでアプリケーションデータを送信できます。 クライアントがそうすることを選択した場合、「pre_shared_key」と「early_data」の両方の拡張機能を提供する必要があります。
The "extension_data" field of this extension contains an "EarlyDataIndication" value.
この拡張の「extension_data」フィールドには、「EarlyDataIndication」値が含まれます。
struct {} Empty;
struct {
select (Handshake.msg_type) {
case new_session_ticket: uint32 max_early_data_size;
case client_hello: Empty;
case encrypted_extensions: Empty;
};
} EarlyDataIndication;
See Section 4.6.1 for details regarding the use of the max_early_data_size field.
max_early_data_sizeフィールドの使用に関する詳細については、セクション4.6.1を参照してください。
The parameters for the 0-RTT data (version, symmetric cipher suite, Application-Layer Protocol Negotiation (ALPN) [RFC7301] protocol, etc.) are those associated with the PSK in use. For externally provisioned PSKs, the associated values are those provisioned along with the key. For PSKs established via a NewSessionTicket message, the associated values are those which were negotiated in the connection which established the PSK. The PSK used to encrypt the early data MUST be the first PSK listed in the client's "pre_shared_key" extension.
0-RTTデータのパラメーター（バージョン、対称暗号スイート、アプリケーション層プロトコルネゴシエーション（ALPN）[RFC7301]プロトコルなど）は、使用中のPSKに関連付けられたものです。 外部でプロビジョニングされたPSKの場合、関連付けられている値は、キーとともにプロビジョニングされた値です。 NewSessionTicketメッセージを介して確立されたPSKの場合、関連付けられている値は、PSKを確立した接続でネゴシエートされた値です。 初期データの暗号化に使用されるPSKは、クライアントの「pre_shared_key」拡張機能にリストされている最初のPSKでなければなりません。
For PSKs provisioned via NewSessionTicket, a server MUST validate that the ticket age for the selected PSK identity (computed by subtracting ticket_age_add from PskIdentity.obfuscated_ticket_age modulo 2^32) is within a small tolerance of the time since the ticket was issued (see Section 8). If it is not, the server SHOULD proceed with the handshake but reject 0-RTT, and SHOULD NOT take any other action that assumes that this ClientHello is fresh.
NewSessionTicket経由でプロビジョニングされたPSKの場合、サーバーは、選択されたPSK IDのチケット経過時間（PskIdentity.obfuscated_ticket_ageモジュロ2 ^ 32からticket_age_addを引いて計算）が、チケットが発行されてからの時間の許容範囲内であることを検証する必要があります（セクション8を参照） ）。 そうでない場合、サーバーはハンドシェイクを続行する必要がありますが、0-RTTを拒否し、このClientHelloが新鮮であると想定する他のアクションを実行するべきではありません。
0-RTT messages sent in the first flight have the same (encrypted) content types as messages of the same type sent in other flights (handshake and application_data) but are protected under different keys. After receiving the server's Finished message, if the server has accepted early data, an EndOfEarlyData message will be sent to indicate the key change. This message will be encrypted with the 0-RTT traffic keys.
最初のフライトで送信される0-RTTメッセージは、他のフライト（ハンドシェイクおよびapplication_data）で送信される同じタイプのメッセージと同じ（暗号化された）コンテンツタイプを持ちますが、異なるキーで保護されます。 サーバーのFinishedメッセージを受信した後、サーバーが初期データを受け入れた場合、キーの変更を示すEndOfEarlyDataメッセージが送信されます。 このメッセージは、0-RTTトラフィックキーで暗号化されます。
A server which receives an "early_data" extension MUST behave in one of three ways:
「early_data」拡張機能を受信するサーバーは、次の3つの方法のいずれかで動作する必要があります。
- Ignore the extension and return a regular 1-RTT response. The server then skips past early data by attempting to deprotect received records using the handshake traffic key, discarding records which fail deprotection (up to the configured max_early_data_size). Once a record is deprotected successfully, it is treated as the start of the client's second flight and the server proceeds as with an ordinary 1-RTT handshake.
- 拡張機能を無視し、通常の1-RTT応答を返します。 サーバーは、ハンドシェイクトラフィックキーを使用して受信したレコードの保護を解除することにより、過去の初期データをスキップし、保護解除に失敗したレコードを破棄します（構成されたmax_early_data_sizeまで）。 レコードの保護が正常に解除されると、クライアントの2番目のフライトの開始として扱われ、サーバーは通常の1-RTTハンドシェイクと同様に処理を進めます。
- Request that the client send another ClientHello by responding with a HelloRetryRequest. A client MUST NOT include the "early_data" extension in its followup ClientHello. The server then ignores early data by skipping all records with an external content type of "application_data" (indicating that they are encrypted), up to the configured max_early_data_size.
- HelloRetryRequestで応答することにより、クライアントが別のClientHelloを送信することを要求します。 クライアントは、フォローアップClientHelloに「early_data」拡張子を含めてはなりません。 サーバーは、設定されたmax_early_data_sizeまでの「application_data」（暗号化されていることを示す）の外部コンテンツタイプを持つすべてのレコードをスキップすることにより、初期データを無視します。
- Return its own "early_data" extension in EncryptedExtensions, indicating that it intends to process the early data. It is not possible for the server to accept only a subset of the early data messages. Even though the server sends a message accepting early data, the actual early data itself may already be in flight by the time the server generates this message.
- EncryptedExtensionsで独自の「early_data」拡張子を返し、初期データを処理するつもりであることを示します。 サーバーが初期データメッセージのサブセットのみを受け入れることはできません。 サーバーは初期データを受け入れるメッセージを送信しますが、実際の初期データ自体は、サーバーがこのメッセージを生成するまでにすでに飛行している場合があります。
In order to accept early data, the server MUST have accepted a PSK cipher suite and selected the first key offered in the client's "pre_shared_key" extension. In addition, it MUST verify that the following values are the same as those associated with the selected PSK:
初期データを受け入れるために、サーバーはPSK暗号スイートを受け入れ、クライアントの「pre_shared_key」拡張機能で提供される最初のキーを選択する必要があります。 さらに、次の値が選択したPSKに関連付けられている値と同じであることを確認する必要があります。
- The TLS version number
- TLSバージョン番号
- The selected cipher suite
- 選択された暗号スイート
- The selected ALPN [RFC7301] protocol, if any
- 選択したALPN [RFC7301]プロトコル（存在する場合）
These requirements are a superset of those needed to perform a 1-RTT handshake using the PSK in question. For externally established PSKs, the associated values are those provisioned along with the key. For PSKs established via a NewSessionTicket message, the associated values are those negotiated in the connection during which the ticket was established.
これらの要件は、問題のPSKを使用して1-RTTハンドシェイクを実行するために必要な要件のスーパーセットです。 外部で確立されたPSKの場合、関連付けられている値は、キーとともにプロビジョニングされた値です。 NewSessionTicketメッセージを介して確立されたPSKの場合、関連付けられた値は、チケットが確立された接続でネゴシエートされた値です。
Future extensions MUST define their interaction with 0-RTT.
将来の拡張は、0-RTTとの相互作用を定義しなければなりません。
If any of these checks fail, the server MUST NOT respond with the extension and must discard all the first-flight data using one of the first two mechanisms listed above (thus falling back to 1-RTT or 2-RTT). If the client attempts a 0-RTT handshake but the server rejects it, the server will generally not have the 0-RTT record protection keys and must instead use trial decryption (either with the 1-RTT handshake keys or by looking for a cleartext ClientHello in the case of a HelloRetryRequest) to find the first non-0-RTT message.
これらのチェックのいずれかが失敗した場合、サーバーは拡張機能で応答してはならず、上記の最初の2つのメカニズムのいずれかを使用してすべての初回飛行データを破棄する必要があります（したがって、1-RTTまたは2-RTTにフォールバックします）。 クライアントが0-RTTハンドシェイクを試みても、サーバーがそれを拒否する場合、サーバーは通常0-RTTレコード保護キーを持たず、代わりにトライアル復号化を使用する必要があります（1-RTTハンドシェイクキーを使用するか、クリアテキストClientHelloを検索することにより） HelloRetryRequestの場合）、最初の非0-RTTメッセージを見つけます。
If the server chooses to accept the "early_data" extension, then it MUST comply with the same error-handling requirements specified for all records when processing early data records. Specifically, if the server fails to decrypt a 0-RTT record following an accepted "early_data" extension, it MUST terminate the connection with a "bad_record_mac" alert as per Section 5.2.
サーバーが「early_data」拡張機能を受け入れることを選択した場合、初期データレコードを処理するときに、すべてのレコードに対して指定された同じエラー処理要件に準拠する必要があります。 具体的には、サーバーが受け入れられた「early_data」拡張子に続く0-RTTレコードの復号化に失敗した場合、セクション5.2に従って「bad_record_mac」アラートで接続を終了する必要があります。
If the server rejects the "early_data" extension, the client application MAY opt to retransmit the Application Data previously sent in early data once the handshake has been completed. Note that automatic retransmission of early data could result in incorrect assumptions regarding the status of the connection. For instance, when the negotiated connection selects a different ALPN protocol from what was used for the early data, an application might need to construct different messages. Similarly, if early data assumes anything about the connection state, it might be sent in error after the handshake completes.
サーバーが「early_data」拡張子を拒否した場合、クライアントアプリケーションは、ハンドシェイクが完了すると、以前のデータで以前に送信されたアプリケーションデータを再送信することを選択できます。 初期データの自動再送信により、接続のステータスに関する誤った仮定が生じる可能性があることに注意してください。 たとえば、ネゴシエートされた接続が初期データに使用されたものとは異なるALPNプロトコルを選択する場合、アプリケーションは異なるメッセージを作成する必要があります。 同様に、初期データが接続状態について何かを仮定している場合、ハンドシェイクの完了後にエラーで送信される可能性があります。
A TLS implementation SHOULD NOT automatically resend early data; applications are in a better position to decide when retransmission is appropriate. A TLS implementation MUST NOT automatically resend early data unless the negotiated connection selects the same ALPN protocol.
TLS実装は、初期データを自動的に再送信するべきではありません。 アプリケーションは、再送信がいつ適切かを判断するのに適した立場にあります。 ネゴシエートされた接続が同じALPNプロトコルを選択しない限り、TLS実装は初期データを自動的に再送信してはなりません。
The "pre_shared_key" extension is used to negotiate the identity of the pre-shared key to be used with a given handshake in association with PSK key establishment.
「pre_shared_key」拡張は、PSKキーの確立に関連して特定のハンドシェイクで使用される事前共有キーのIDをネゴシエートするために使用されます。
The "extension_data" field of this extension contains a "PreSharedKeyExtension" value:
この拡張機能の「extension_data」フィールドには、「PreSharedKeyExtension」値が含まれています。
struct {
opaque identity<1..2^16-1>;
uint32 obfuscated_ticket_age;
} PskIdentity;
opaque PskBinderEntry<32..255>;
struct {
PskIdentity identities<7..2^16-1>;
PskBinderEntry binders<33..2^16-1>;
} OfferedPsks;
struct {
select (Handshake.msg_type) {
case client_hello: OfferedPsks;
case server_hello: uint16 selected_identity;
};
} PreSharedKeyExtension;
identity: A label for a key. For instance, a ticket (as defined in Appendix B.3.4) or a label for a pre-shared key established externally.
identity：キーのラベル。 たとえば、チケット（付録B.3.4で定義）または外部で確立された事前共有キーのラベル。
obfuscated_ticket_age: An obfuscated version of the age of the key. Section 4.2.11.1 describes how to form this value for identities established via the NewSessionTicket message. For identities established externally, an obfuscated_ticket_age of 0 SHOULD be used, and servers MUST ignore the value.
obfuscated_ticket_age：キーの年齢の難読化されたバージョン。 セクション4.2.11.1では、NewSessionTicketメッセージを介して確立されたIDに対してこの値を形成する方法について説明します。 外部で確立されたIDの場合、0のobfuscated_ticket_ageを使用する必要があり（SHOULD）、サーバーは値を無視しなければなりません（MUST）。
identities: A list of the identities that the client is willing to negotiate with the server. If sent alongside the "early_data" extension (see Section 4.2.10), the first identity is the one used for 0-RTT data.
identities：クライアントがサーバーと交渉する意思があるアイデンティティのリスト。 「early_data」拡張子（セクション4.2.10を参照）と共に送信される場合、最初のIDは0-RTTデータに使用されるIDです。
binders: A series of HMAC values, one for each value in the identities list and in the same order, computed as described below.
binders：一連のHMAC値。IDリストの各値に1つずつ、同じ順序で、以下で説明するように計算されます。
selected_identity: The server's chosen identity expressed as a (0-based) index into the identities in the client's list.
selected_identity：クライアントのリスト内のIDへの（0ベースの）インデックスとして表されるサーバーの選択されたID。
Each PSK is associated with a single Hash algorithm. For PSKs established via the ticket mechanism (Section 4.6.1), this is the KDF Hash algorithm on the connection where the ticket was established. For externally established PSKs, the Hash algorithm MUST be set when the PSK is established or default to SHA-256 if no such algorithm is defined. The server MUST ensure that it selects a compatible PSK (if any) and cipher suite.
各PSKは、単一のハッシュアルゴリズムに関連付けられています。 チケットメカニズム（セクション4.6.1）を介して確立されたPSKの場合、これはチケットが確立された接続でのKDFハッシュアルゴリズムです。 外部で確立されたPSKの場合、PSKが確立されたときにハッシュアルゴリズムを設定するか、そのようなアルゴリズムが定義されていない場合はデフォルトでSHA-256を設定する必要があります。 サーバーは、互換性のあるPSK（存在する場合）および暗号スイートを選択することを保証する必要があります。
In TLS versions prior to TLS 1.3, the Server Name Identification (SNI) value was intended to be associated with the session (Section 3 of [RFC6066]), with the server being required to enforce that the SNI value associated with the session matches the one specified in the resumption handshake. However, in reality the implementations were not consistent on which of two supplied SNI values they would use, leading to the consistency requirement being de facto enforced by the clients. In TLS 1.3, the SNI value is always explicitly specified in the resumption handshake, and there is no need for the server to associate an SNI value with the ticket. Clients, however, SHOULD store the SNI with the PSK to fulfill the requirements of Section 4.6.1.
TLS 1.3より前のTLSバージョンでは、サーバー名識別（SNI）値はセッション（[RFC6066]のセクション3）に関連付けられることを目的としており、サーバーはセッションに関連付けられたSNI値が 再開ハンドシェイクで指定されたもの。 ただし、実際には、2つの提供されたSNI値のどちらを使用するかについて実装が一貫しておらず、一貫性要件がクライアントによって事実上強制されています。 TLS 1.3では、SNI値は常に再開ハンドシェイクで明示的に指定され、サーバーがSNI値をチケットに関連付ける必要はありません。 ただし、クライアントは、セクション4.6.1の要件を満たすためにSNIをPSKに保存する必要があります。
Implementor's note: When session resumption is the primary use case of PSKs, the most straightforward way to implement the PSK/cipher suite matching requirements is to negotiate the cipher suite first and then exclude any incompatible PSKs. Any unknown PSKs (e.g., ones not in the PSK database or encrypted with an unknown key) SHOULD simply be ignored. If no acceptable PSKs are found, the server SHOULD perform a non-PSK handshake if possible. If backward compatibility is important, client-provided, externally established PSKs SHOULD influence cipher suite selection.
実装者注：セッションの再開がPSKの主な使用例である場合、PSK /暗号スイートの一致要件を実装する最も簡単な方法は、最初に暗号スイートをネゴシエートし、次に互換性のないPSKを除外することです。 不明なPSK（PSKデータベースにない、または不明なキーで暗号化されたもの）は、単に無視する必要があります（SHOULD）。 受け入れ可能なPSKが見つからない場合、サーバーは、可能であれば非PSKハンドシェイクを実行する必要があります。 下位互換性が重要な場合、クライアントが提供する、外部で確立されたPSKは、暗号スイートの選択に影響を与える必要があります。
Prior to accepting PSK key establishment, the server MUST validate the corresponding binder value (see Section 4.2.11.2 below). If this value is not present or does not validate, the server MUST abort the handshake. Servers SHOULD NOT attempt to validate multiple binders; rather, they SHOULD select a single PSK and validate solely the binder that corresponds to that PSK. See Section 8.2 and Appendix E.6 for the security rationale for this requirement. In order to accept PSK key establishment, the server sends a "pre_shared_key" extension indicating the selected identity.
PSKキーの確立を受け入れる前に、サーバーは対応するバインダー値を検証する必要があります（セクション4.2.11.2を参照）。 この値が存在しないか検証されない場合、サーバーはハンドシェイクを中止しなければなりません。 サーバーは、複数のバインダーを検証しようとすべきではありません。 むしろ、単一のPSKを選択し、そのPSKに対応するバインダーのみを検証する必要があります。 この要件のセキュリティ根拠については、セクション8.2および付録E.6を参照してください。 PSKキーの確立を受け入れるために、サーバーは選択されたIDを示す「pre_shared_key」拡張を送信します。
Clients MUST verify that the server's selected_identity is within the range supplied by the client, that the server selected a cipher suite indicating a Hash associated with the PSK, and that a server "key_share" extension is present if required by the ClientHello "psk_key_exchange_modes" extension. If these values are not consistent, the client MUST abort the handshake with an "illegal_parameter" alert.
クライアントは、サーバーのselected_identityがクライアントによって提供された範囲内にあること、サーバーがPSKに関連付けられたハッシュを示す暗号スイートを選択したこと、およびClientHello "psk_key_exchange_modes"拡張で必要な場合にサーバーの "key_share"拡張が存在することを確認しなければなりません 。 これらの値に一貫性がない場合、クライアントは「illegal_parameter」アラートでハンドシェイクを中止する必要があります。
If the server supplies an "early_data" extension, the client MUST verify that the server's selected_identity is 0. If any other value is returned, the client MUST abort the handshake with an "illegal_parameter" alert.
サーバーが「early_data」拡張機能を提供する場合、クライアントはサーバーのselected_identityが0であることを確認する必要があります。他の値が返される場合、クライアントは「illegal_parameter」アラートでハンドシェイクを中止する必要があります。
The "pre_shared_key" extension MUST be the last extension in the ClientHello (this facilitates implementation as described below). Servers MUST check that it is the last extension and otherwise fail the handshake with an "illegal_parameter" alert.
"pre_shared_key"拡張は、ClientHelloの最後の拡張でなければなりません（これにより、以下で説明するように実装が容易になります）。 サーバーは、それが最後の拡張子であることを確認する必要があります。そうでなければ、「illegal_parameter」アラートでハンドシェイクに失敗します。
The client's view of the age of a ticket is the time since the receipt of the NewSessionTicket message. Clients MUST NOT attempt to use tickets which have ages greater than the "ticket_lifetime" value which was provided with the ticket. The "obfuscated_ticket_age" field of each PskIdentity contains an obfuscated version of the ticket age formed by taking the age in milliseconds and adding the "ticket_age_add" value that was included with the ticket (see Section 4.6.1), modulo 2^32. This addition prevents passive observers from correlating connections unless tickets are reused. Note that the "ticket_lifetime" field in the NewSessionTicket message is in seconds but the "obfuscated_ticket_age" is in milliseconds. Because ticket lifetimes are restricted to a week, 32 bits is enough to represent any plausible age, even in milliseconds.
クライアントのチケットの経過時間のビューは、NewSessionTicketメッセージを受信してからの時間です。 クライアントは、チケットで提供された「ticket_lifetime」値よりも長い年齢のチケットを使用してはいけません。 各PskIdentityの「obfuscated_ticket_age」フィールドには、ミリ秒単位の経過時間を取り、チケットに含まれる「ticket_age_add」値（セクション4.6.1を参照）を2 ^ 32で加算することにより形成されるチケット経過時間の難読化バージョンが含まれます。 この追加により、パッシブオブザーバーは、チケットが再利用されない限り、接続を相関させなくなります。 NewSessionTicketメッセージの「ticket_lifetime」フィールドは秒単位ですが、「obfuscated_ticket_age」はミリ秒単位であることに注意してください。 チケットの有効期間は1週間に制限されているため、ミリ秒単位であっても、妥当な年齢を表すには32ビットで十分です。
The PSK binder value forms a binding between a PSK and the current handshake, as well as a binding between the handshake in which the PSK was generated (if via a NewSessionTicket message) and the current handshake. Each entry in the binders list is computed as an HMAC over a transcript hash (see Section 4.4.1) containing a partial ClientHello up to and including the PreSharedKeyExtension.identities field. That is, it includes all of the ClientHello but not the binders list itself. The length fields for the message (including the overall length, the length of the extensions block, and the length of the "pre_shared_key" extension) are all set as if binders of the correct lengths were present.
PSKバインダー値は、PSKと現在のハンドシェイク間のバインディング、およびPSKが生成されたハンドシェイク（NewSessionTicketメッセージ経由の場合）と現在のハンドシェイク間のバインディングを形成します。 バインダーリストの各エントリは、PreSharedKeyExtension.identitiesフィールドまでの部分的なClientHelloを含むトランスクリプトハッシュ（セクション4.4.1を参照）上のHMACとして計算されます。 つまり、ClientHelloのすべてが含まれますが、バインダーリスト自体は含まれません。 メッセージの長さフィールド（全体の長さ、拡張ブロックの長さ、および「pre_shared_key」拡張の長さを含む）はすべて、正しい長さのバインダーが存在するかのように設定されます。
The PskBinderEntry is computed in the same way as the Finished message (Section 4.4.4) but with the BaseKey being the binder_key derived via the key schedule from the corresponding PSK which is being offered (see Section 7.1).
PskBinderEntryはFinishedメッセージ（セクション4.4.4）と同じ方法で計算されますが、BaseKeyは、提供されている対応するPSKからキースケジュールを介して導出されたバインダーキーです（セクション7.1を参照）。
If the handshake includes a HelloRetryRequest, the initial ClientHello and HelloRetryRequest are included in the transcript along with the new ClientHello. For instance, if the client sends ClientHello1, its binder will be computed over:
ハンドシェイクにHelloRetryRequestが含まれる場合、最初のClientHelloとHelloRetryRequestは、新しいClientHelloとともにトランスクリプトに含まれます。 たとえば、クライアントがClientHello1を送信すると、そのバインダーは次のように計算されます。
Transcript-Hash(Truncate(ClientHello1))
Where Truncate() removes the binders list from the ClientHello.
Truncate() は、ClientHelloからバインダーリストを削除します。
If the server responds with a HelloRetryRequest and the client then sends ClientHello2, its binder will be computed over:
サーバーがHelloRetryRequestで応答し、クライアントがClientHello2を送信すると、そのバインダーは次のように計算されます。
Transcript-Hash(ClientHello1,
HelloRetryRequest,
Truncate(ClientHello2))
The full ClientHello1/ClientHello2 is included in all other handshake hash computations. Note that in the first flight, Truncate(ClientHello1) is hashed directly, but in the second flight, ClientHello1 is hashed and then reinjected as a "message_hash" message, as described in Section 4.4.1.
完全なClientHello1 / ClientHello2は、他のすべてのハンドシェイクハッシュ計算に含まれます。 最初のフライトでは、Truncate（ClientHello1）が直接ハッシュされますが、2番目のフライトでは、ClientHello1がハッシュされ、セクション4.4.1で説明されているように「message_hash」メッセージとして再注入されます。
Clients are permitted to "stream" 0-RTT data until they receive the server's Finished, only then sending the EndOfEarlyData message, followed by the rest of the handshake. In order to avoid deadlocks, when accepting "early_data", servers MUST process the client's ClientHello and then immediately send their flight of messages, rather than waiting for the client's EndOfEarlyData message before sending its ServerHello.
クライアントは、サーバーのFinishedを受信するまで0-RTTデータを「ストリーミング」し、その後EndOfEarlyDataメッセージを送信し、その後にハンドシェイクの残りを送信することが許可されます。 デッドロックを回避するために、「early_data」を受け入れる場合、サーバーは、ServerHelloを送信する前にクライアントのEndOfEarlyDataメッセージを待つのではなく、クライアントのClientHelloを処理し、すぐにメッセージのフライトを送信する必要があります。
The next two messages from the server, EncryptedExtensions and CertificateRequest, contain information from the server that determines the rest of the handshake. These messages are encrypted with keys derived from the server_handshake_traffic_secret.
サーバーからの次の2つのメッセージ、EncryptedExtensionsおよびCertificateRequestには、残りのハンドシェイクを決定するサーバーからの情報が含まれています。 これらのメッセージは、server_handshake_traffic_secretから派生したキーで暗号化されます。
In all handshakes, the server MUST send the EncryptedExtensions message immediately after the ServerHello message. This is the first message that is encrypted under keys derived from the server_handshake_traffic_secret.
すべてのハンドシェイクで、サーバーはServerHelloメッセージの直後にEncryptedExtensionsメッセージを送信する必要があります。 これは、server_handshake_traffic_secretから派生したキーで暗号化される最初のメッセージです。
The EncryptedExtensions message contains extensions that can be protected, i.e., any which are not needed to establish the cryptographic context but which are not associated with individual certificates. The client MUST check EncryptedExtensions for the presence of any forbidden extensions and if any are found MUST abort the handshake with an "illegal_parameter" alert.
EncryptedExtensionsメッセージには、保護できる拡張機能、つまり、暗号化コンテキストを確立するために必要ではないが、個々の証明書に関連付けられていない拡張機能が含まれています。 クライアントは、禁止されている拡張機能の存在についてEncryptedExtensionsをチェックする必要があり、存在する場合は「illegal_parameter」アラートでハンドシェイクを中止しなければなりません。
Structure of this message:
このメッセージの構造：
struct {
Extension extensions<0..2^16-1>;
} EncryptedExtensions;
extensions: A list of extensions. For more information, see the table in Section 4.2.
拡張機能：拡張機能のリスト。 詳細については、セクション4.2の表を参照してください。
A server which is authenticating with a certificate MAY optionally request a certificate from the client. This message, if sent, MUST follow EncryptedExtensions.
証明書で認証しているサーバーは、オプションでクライアントに証明書を要求できます。 このメッセージは、送信される場合、EncryptedExtensionsに従う必要があります。
Structure of this message:
このメッセージの構造：
struct {
opaque certificate_request_context<0..2^8-1>;
Extension extensions<2..2^16-1>;
} CertificateRequest;
certificate_request_context: An opaque string which identifies the certificate request and which will be echoed in the client's Certificate message. The certificate_request_context MUST be unique within the scope of this connection (thus preventing replay of client CertificateVerify messages). This field SHALL be zero length unless used for the post-handshake authentication exchanges described in Section 4.6.2. When requesting post-handshake authentication, the server SHOULD make the context unpredictable to the client (e.g., by randomly generating it) in order to prevent an attacker who has temporary access to the client's private key from pre-computing valid CertificateVerify messages.
certificate_request_context：証明書要求を識別し、クライアントの証明書メッセージにエコーされる不透明な文字列。 certificate_request_contextは、この接続のスコープ内で一意でなければなりません（したがって、クライアントのCertificateVerifyメッセージの再生を防ぎます）。 このフィールドは、セクション4.6.2で説明されているポストハンドシェイク認証交換に使用されない限り、長さがゼロでなければなりません。 ハンドシェイク後の認証を要求する場合、サーバーは、クライアントの秘密キーに一時的にアクセスする攻撃者が有効なCertificateVerifyメッセージを事前計算することを防ぐために、コンテキストをクライアントに予測不能にする必要があります（ランダムに生成するなど）。
extensions: A set of extensions describing the parameters of the certificate being requested. The "signature_algorithms" extension MUST be specified, and other extensions may optionally be included if defined for this message. Clients MUST ignore unrecognized extensions.
拡張機能：要求されている証明書のパラメーターを記述する拡張機能のセット。 「signature_algorithms」拡張機能を指定する必要があり、このメッセージに対して定義されている場合、他の拡張機能をオプションで含めることができます。 クライアントは認識されない拡張子を無視しなければなりません。
In prior versions of TLS, the CertificateRequest message carried a list of signature algorithms and certificate authorities which the server would accept. In TLS 1.3, the former is expressed by sending the "signature_algorithms" and optionally "signature_algorithms_cert" extensions. The latter is expressed by sending the "certificate_authorities" extension (see Section 4.2.4).
TLSの以前のバージョンでは、CertificateRequestメッセージには、サーバーが受け入れる署名アルゴリズムと認証局のリストが含まれていました。 TLS 1.3では、前者は「signature_algorithms」およびオプションで「signature_algorithms_cert」拡張機能を送信することで表現されます。 後者は、「certificate_authorities」拡張を送信することで表現されます（セクション4.2.4を参照）。
Servers which are authenticating with a PSK MUST NOT send the CertificateRequest message in the main handshake, though they MAY send it in post-handshake authentication (see Section 4.6.2) provided that the client has sent the "post_handshake_auth" extension (see Section 4.2.6).
クライアントが "post_handshake_auth"拡張（セクション4.2を参照）を送信した場合、PSKで認証しているサーバーは、メインハンドシェイクでCertificateRequestメッセージを送信してはなりません。 .6）。
As discussed in Section 2, TLS generally uses a common set of messages for authentication, key confirmation, and handshake integrity: Certificate, CertificateVerify, and Finished. (The PSK binders also perform key confirmation, in a similar fashion.) These three messages are always sent as the last messages in their handshake flight. The Certificate and CertificateVerify messages are only sent under certain circumstances, as defined below. The Finished message is always sent as part of the Authentication Block. These messages are encrypted under keys derived from the [sender]_handshake_traffic_secret.
セクション2で説明したように、TLSは通常、認証、キーの確認、およびハンドシェイクの整合性のために、証明書、CertificateVerify、およびFinishedの共通のメッセージセットを使用します。 （PSKバインダも同様にキー確認を実行します。）これら3つのメッセージは、常にハンドシェイクフライトの最後のメッセージとして送信されます。 CertificateおよびCertificateVerifyメッセージは、以下に定義する特定の状況でのみ送信されます。 Finishedメッセージは、常に認証ブロックの一部として送信されます。 これらのメッセージは、[sender] _handshake_traffic_secretから派生したキーで暗号化されます。
The computations for the Authentication messages all uniformly take the following inputs:
認証メッセージの計算はすべて、次の入力を一様に受け取ります。
- The certificate and signing key to be used.
- 使用する証明書と署名キー。
- A Handshake Context consisting of the set of messages to be included in the transcript hash.
- トランスクリプトハッシュに含まれるメッセージのセットで構成されるハンドシェイクコンテキスト。
- A Base Key to be used to compute a MAC key.
- MACキーの計算に使用されるベースキー。
Based on these inputs, the messages then contain:
これらの入力に基づいて、メッセージには以下が含まれます。
Certificate: The certificate to be used for authentication, and any supporting certificates in the chain. Note that certificate-based client authentication is not available in PSK handshake flows (including 0-RTT).
Certificate：認証に使用される証明書、およびチェーン内のサポート証明書。 証明書ベースのクライアント認証は、PSKハンドシェイクフロー（0-RTTを含む）では使用できないことに注意してください。
CertificateVerify: A signature over the value Transcript-Hash(Handshake Context, Certificate).
CertificateVerify：値Transcript-Hash（Handshake Context、Certificate）の署名。
Finished: A MAC over the value Transcript-Hash(Handshake Context, Certificate, CertificateVerify) using a MAC key derived from the Base Key.
Finished：ベースキーから派生したMACキーを使用して、値Transcript-Hash（Handshake Context、Certificate、CertificateVerify）に対するMAC。
The following table defines the Handshake Context and MAC Base Key for each scenario:
次の表は、各シナリオのハンドシェイクコンテキストとMACベースキーを定義しています。
+-----------+-------------------------+-----------------------------+
| Mode | Handshake Context | Base Key |
+-----------+-------------------------+-----------------------------+
| Server | ClientHello ... later | server_handshake_traffic_ |
| | of EncryptedExtensions/ | secret |
| | CertificateRequest | |
| | | |
| Client | ClientHello ... later | client_handshake_traffic_ |
| | of server | secret |
| | Finished/EndOfEarlyData | |
| | | |
| Post- | ClientHello ... client | client_application_traffic_ |
| Handshake | Finished + | secret_N |
| | CertificateRequest | |
+-----------+-------------------------+-----------------------------+
Many of the cryptographic computations in TLS make use of a transcript hash. This value is computed by hashing the concatenation of each included handshake message, including the handshake message header carrying the handshake message type and length fields, but not including record layer headers. I.e.,
TLSの暗号化計算の多くは、トランスクリプトハッシュを使用します。 この値は、含まれている各ハンドシェイクメッセージの連結をハッシュすることによって計算されます。これには、ハンドシェイクメッセージタイプと長さフィールドを含むハンドシェイクメッセージヘッダーが含まれますが、レコードレイヤーヘッダーは含まれません。 つまり、
Transcript-Hash(M1, M2, ... Mn) = Hash(M1 || M2 || ... || Mn)
As an exception to this general rule, when the server responds to a ClientHello with a HelloRetryRequest, the value of ClientHello1 is replaced with a special synthetic handshake message of handshake type "message_hash" containing Hash(ClientHello1). I.e.,
この一般的な規則の例外として、サーバーがHelloRetryRequestでClientHelloに応答すると、ClientHello1の値は、Hash（ClientHello1）を含むハンドシェイクタイプ「message_hash」の特別な合成ハンドシェイクメッセージに置き換えられます。 つまり、
Transcript-Hash(ClientHello1, HelloRetryRequest, ... Mn) =
Hash(message_hash || /* Handshake type */
00 00 Hash.length || /* Handshake message length (bytes) */
Hash(ClientHello1) || /* Hash of ClientHello1 */
HelloRetryRequest || ... || Mn)
The reason for this construction is to allow the server to do a stateless HelloRetryRequest by storing just the hash of ClientHello1 in the cookie, rather than requiring it to export the entire intermediate hash state (see Section 4.2.2).
この構成の理由は、中間ハッシュ状態全体をエクスポートするように要求するのではなく、CookieにClientHello1のハッシュのみを格納することにより、サーバーがステートレスHelloRetryRequestを実行できるようにするためです（セクション4.2.2を参照）。
For concreteness, the transcript hash is always taken from the following sequence of handshake messages, starting at the first ClientHello and including only those messages that were sent: ClientHello, HelloRetryRequest, ClientHello, ServerHello, EncryptedExtensions, server CertificateRequest, server Certificate, server CertificateVerify, server Finished, EndOfEarlyData, client Certificate, client CertificateVerify, client Finished.
具体的には、トランスクリプトハッシュは常に、次の一連のハンドシェイクメッセージから取得されます。最初のClientHelloから始まり、送信されたメッセージのみが含まれます：ClientHello、HelloRetryRequest、ClientHello、ServerHello、EncryptedExtensions、server CertificateRequest、server Certificate、server CertificateVerify、 サーバー終了、EndOfEarlyData、クライアント証明書、クライアント証明書検証、クライアント終了。
In general, implementations can implement the transcript by keeping a running transcript hash value based on the negotiated hash. Note, however, that subsequent post-handshake authentications do not include each other, just the messages through the end of the main handshake.
一般に、実装は、ネゴシエートされたハッシュに基づいて実行中のトランスクリプトハッシュ値を保持することにより、トランスクリプトを実装できます。 ただし、後続のハンドシェイク後の認証には、お互いが含まれず、メインハンドシェイクの最後までのメッセージのみが含まれることに注意してください。
This message conveys the endpoint's certificate chain to the peer.
このメッセージは、エンドポイントの証明書チェーンをピアに伝えます。
The server MUST send a Certificate message whenever the agreed-upon key exchange method uses certificates for authentication (this includes all key exchange methods defined in this document except PSK).
サーバーは、合意されたキー交換方法が認証に証明書を使用する場合は常に証明書メッセージを送信する必要があります（これには、PSKを除く、このドキュメントで定義されているすべてのキー交換方法が含まれます）。
The client MUST send a Certificate message if and only if the server has requested client authentication via a CertificateRequest message (Section 4.3.2). If the server requests client authentication but no suitable certificate is available, the client MUST send a Certificate message containing no certificates (i.e., with the "certificate_list" field having length 0). A Finished message MUST be sent regardless of whether the Certificate message is empty.
サーバーは、CertificateRequestメッセージ（セクション4.3.2）を介してクライアント認証を要求した場合にのみ、クライアントは証明書メッセージを送信する必要があります。 サーバーがクライアント認証を要求したが、適切な証明書が利用できない場合、クライアントは証明書を含まない証明書メッセージを送信する必要があります（つまり、「certificate_list」フィールドの長さは0）。 証明書メッセージが空かどうかに関係なく、Finishedメッセージを送信する必要があります。
Structure of this message:
このメッセージの構造：
enum {
X509(0),
RawPublicKey(2),
(255)
} CertificateType;
struct {
select (certificate_type) {
case RawPublicKey:
/* From RFC 7250 ASN.1_subjectPublicKeyInfo */
opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
case X509:
opaque cert_data<1..2^24-1>;
};
Extension extensions<0..2^16-1>;
} CertificateEntry;
struct {
opaque certificate_request_context<0..2^8-1>;
CertificateEntry certificate_list<0..2^24-1>;
} Certificate;
certificate_request_context: If this message is in response to a CertificateRequest, the value of certificate_request_context in that message. Otherwise (in the case of server authentication), this field SHALL be zero length.
certificate_request_context：このメッセージがCertificateRequestへの応答である場合、そのメッセージのcertificate_request_contextの値。 それ以外の場合（サーバー認証の場合）、このフィールドは長さがゼロでなければなりません。
certificate_list: A sequence (chain) of CertificateEntry structures, each containing a single certificate and set of extensions.
certificate_list：CertificateEntry構造のシーケンス（チェーン）。各構造には、単一の証明書と拡張機能のセットが含まれます。
extensions: A set of extension values for the CertificateEntry. The "Extension" format is defined in Section 4.2. Valid extensions for server certificates at present include the OCSP Status extension [RFC6066] and the SignedCertificateTimestamp extension [RFC6962]; future extensions may be defined for this message as well. Extensions in the Certificate message from the server MUST correspond to ones from the ClientHello message. Extensions in the Certificate message from the client MUST correspond to extensions in the CertificateRequest message from the server. If an extension applies to the entire chain, it SHOULD be included in the first CertificateEntry.
extensions：CertificateEntryの拡張値のセット。 「拡張」形式はセクション4.2で定義されています。 現在のサーバー証明書の有効な拡張には、OCSP Status拡張[RFC6066]およびSignedCertificateTimestamp拡張[RFC6962]が含まれます。 このメッセージにも将来の拡張が定義される可能性があります。 サーバーからの証明書メッセージの拡張子は、ClientHelloメッセージの拡張子に対応している必要があります。 クライアントからの証明書メッセージの拡張子は、サーバーからのCertificateRequestメッセージの拡張子に対応しなければなりません。 拡張機能がチェーン全体に適用される場合、最初のCertificateEntryに含める必要があります。
If the corresponding certificate type extension ("server_certificate_type" or "client_certificate_type") was not negotiated in EncryptedExtensions, or the X.509 certificate type was negotiated, then each CertificateEntry contains a DER-encoded X.509 certificate. The sender's certificate MUST come in the first CertificateEntry in the list. Each following certificate SHOULD directly certify the one immediately preceding it. Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates.
対応する証明書タイプ拡張（「server_certificate_type」または「client_certificate_type」）がEncryptedExtensionsでネゴシエートされなかった場合、またはX.509証明書タイプがネゴシエートされた場合、各CertificateEntryにはDERエンコードされたX.509証明書が含まれます。 送信者の証明書は、リストの最初のCertificateEntryに含まれなければなりません。 次の各証明書は、その直前の証明書を直接証明する必要があります。 証明書の検証ではトラストアンカーを個別に配布する必要があるため、トラストアンカーを指定する証明書は、サポートされているピアが省略された証明書を持っていることがわかっている場合、チェーンから省略できます。
Note: Prior to TLS 1.3, "certificate_list" ordering required each certificate to certify the one immediately preceding it; however, some implementations allowed some flexibility. Servers sometimes send both a current and deprecated intermediate for transitional purposes, and others are simply configured incorrectly, but these cases can nonetheless be validated properly. For maximum compatibility, all implementations SHOULD be prepared to handle potentially extraneous certificates and arbitrary orderings from any TLS version, with the exception of the end-entity certificate which MUST be first.
注：TLS 1.3より前の「certificate_list」の順序付けでは、各証明書が直前の証明書を証明する必要がありました。 ただし、一部の実装ではある程度の柔軟性がありました。 サーバーは、移行目的で現在および非推奨の中間の両方を送信する場合があり、他のサーバーは単純に誤って構成されますが、それでもこれらのケースは適切に検証できます。 最大限の互換性のために、すべての実装は、最初に存在しなければならないエンドエンティティ証明書を除いて、潜在的に無関係な証明書および任意のTLSバージョンからの任意の順序を処理するように準備する必要があります。
If the RawPublicKey certificate type was negotiated, then the certificate_list MUST contain no more than one CertificateEntry, which contains an ASN1_subjectPublicKeyInfo value as defined in [RFC7250], Section 3.
RawPublicKey証明書タイプがネゴシエートされた場合、certificate_listには[RFC7250]セクション3で定義されているASN1_subjectPublicKeyInfo値を含むCertificateEntryを1つだけ含める必要があります。
The OpenPGP certificate type [RFC6091] MUST NOT be used with TLS 1.3.
OpenPGP証明書タイプ[RFC6091]は、TLS 1.3で使用してはなりません（MUST NOT）。
The server's certificate_list MUST always be non-empty. A client will send an empty certificate_list if it does not have an appropriate certificate to send in response to the server's authentication request.
サーバーのcertificate_listは常に空ではない必要があります。 クライアントは、サーバーの認証要求への応答として送信する適切な証明書がない場合、空のcertificate_listを送信します。
[RFC6066] and [RFC6961] provide extensions to negotiate the server sending OCSP responses to the client. In TLS 1.2 and below, the server replies with an empty extension to indicate negotiation of this extension and the OCSP information is carried in a CertificateStatus message. In TLS 1.3, the server's OCSP information is carried in an extension in the CertificateEntry containing the associated certificate. Specifically, the body of the "status_request" extension from the server MUST be a CertificateStatus structure as defined in [RFC6066], which is interpreted as defined in [RFC6960].
[RFC6066]および[RFC6961]は、クライアントにOCSP応答を送信するサーバーをネゴシエートするための拡張機能を提供します。 TLS 1.2以前では、サーバーはこの拡張のネゴシエーションを示すために空の拡張で応答し、OCSP情報はCertificateStatusメッセージで運ばれます。 TLS 1.3では、サーバーのOCSP情報は、関連付けられた証明書を含むCertificateEntryの拡張で運ばれます。 具体的には、サーバーからの「status_request」拡張の本体は、[RFC6066]で定義されているCertificateStatus構造である必要があり、[RFC6960]で定義されていると解釈されます。
Note: The status_request_v2 extension [RFC6961] is deprecated. TLS 1.3 servers MUST NOT act upon its presence or information in it when processing ClientHello messages; in particular, they MUST NOT send the status_request_v2 extension in the EncryptedExtensions, CertificateRequest, or Certificate messages. TLS 1.3 servers MUST be able to process ClientHello messages that include it, as it MAY be sent by clients that wish to use it in earlier protocol versions.
注：status_request_v2拡張機能[RFC6961]は非推奨です。 TLS 1.3サーバーは、ClientHelloメッセージを処理するときに、その存在または情報に基づいて動作してはなりません。 特に、EncryptedExtensions、CertificateRequest、またはCertificateメッセージでstatus_request_v2拡張を送信してはなりません。 TLS 1.3サーバーは、それを含むClientHelloメッセージを処理できる必要があります。これは、以前のプロトコルバージョンで使用したいクライアントから送信される場合があるためです。
A server MAY request that a client present an OCSP response with its certificate by sending an empty "status_request" extension in its CertificateRequest message. If the client opts to send an OCSP response, the body of its "status_request" extension MUST be a CertificateStatus structure as defined in [RFC6066].
サーバーは、CertificateRequestメッセージで空の「status_request」拡張を送信することにより、クライアントが証明書とともにOCSP応答を提示するように要求する場合があります。 クライアントがOCSP応答を送信することを選択した場合、その「status_request」拡張の本体は、[RFC6066]で定義されているCertificateStatus構造でなければなりません。
Similarly, [RFC6962] provides a mechanism for a server to send a Signed Certificate Timestamp (SCT) as an extension in the ServerHello in TLS 1.2 and below. In TLS 1.3, the server's SCT information is carried in an extension in the CertificateEntry.
同様に、[RFC6962]は、サーバーがTLS 1.2以下のServerHelloの拡張として署名済み証明書タイムスタンプ（SCT）を送信するためのメカニズムを提供します。 TLS 1.3では、サーバーのSCT情報はCertificateEntryの拡張で運ばれます。
The following rules apply to the certificates sent by the server:
サーバーから送信される証明書には、次の規則が適用されます。
- The certificate type MUST be X.509v3 [RFC5280], unless explicitly negotiated otherwise (e.g., [RFC7250]).
- 明示的に別の方法でネゴシエートされない限り、証明書タイプはX.509v3 [RFC5280]でなければなりません（例：[RFC7250]）。
- The server's end-entity certificate's public key (and associated restrictions) MUST be compatible with the selected authentication algorithm from the client's "signature_algorithms" extension (currently RSA, ECDSA, or EdDSA).
- サーバーのエンドエンティティ証明書の公開鍵（および関連する制限）は、クライアントの「signature_algorithms」拡張機能（現在はRSA、ECDSA、またはEdDSA）から選択した認証アルゴリズムと互換性がなければなりません。
- The certificate MUST allow the key to be used for signing (i.e., the digitalSignature bit MUST be set if the Key Usage extension is present) with a signature scheme indicated in the client's "signature_algorithms"/"signature_algorithms_cert" extensions (see Section 4.2.3).
- 証明書は、クライアントの「signature_algorithms」/「signature_algorithms_cert」拡張機能で示された署名スキームを使用して、署名にキーを使用できるようにする必要があります（つまり、Key Usage拡張機能が存在する場合はdigitalSignatureビットを設定する必要があります）（セクション4.2を参照）。 3）。
- The "server_name" [RFC6066] and "certificate_authorities" extensions are used to guide certificate selection. As servers MAY require the presence of the "server_name" extension, clients SHOULD send this extension, when applicable.
-「server_name」[RFC6066]および「certificate_authorities」拡張機能は、証明書の選択をガイドするために使用されます。 サーバーは「server_name」拡張の存在を必要とする場合があるため、クライアントは該当する場合、この拡張を送信する必要があります。
All certificates provided by the server MUST be signed by a signature algorithm advertised by the client if it is able to provide such a chain (see Section 4.2.3). Certificates that are self-signed or certificates that are expected to be trust anchors are not validated as part of the chain and therefore MAY be signed with any algorithm.
サーバーが提供するすべての証明書は、そのようなチェーンを提供できる場合、クライアントがアドバタイズする署名アルゴリズムによって署名する必要があります（セクション4.2.3を参照）。 自己署名証明書またはトラストアンカーであると予想される証明書は、チェーンの一部として検証されないため、任意のアルゴリズムで署名することができます。
If the server cannot produce a certificate chain that is signed only via the indicated supported algorithms, then it SHOULD continue the handshake by sending the client a certificate chain of its choice that may include algorithms that are not known to be supported by the client. This fallback chain SHOULD NOT use the deprecated SHA-1 hash algorithm in general, but MAY do so if the client's advertisement permits it, and MUST NOT do so otherwise.
サーバーが、示されたサポートされているアルゴリズムを介してのみ署名された証明書チェーンを作成できない場合、クライアントがサポートしていないことがわかっているアルゴリズムを含む可能性のある選択した証明書チェーンをクライアントに送信して、ハンドシェイクを続行する必要があります。 このフォールバックチェーンは、一般的に非推奨のSHA-1ハッシュアルゴリズムを使用すべきではありませんが、クライアントの広告で許可されている場合は使用できます。
If the client cannot construct an acceptable chain using the provided certificates and decides to abort the handshake, then it MUST abort the handshake with an appropriate certificate-related alert (by default, "unsupported_certificate"; see Section 6.2 for more information).
クライアントが提供された証明書を使用して受け入れ可能なチェーンを構築できず、ハンドシェイクを中止することを決定した場合、適切な証明書関連のアラートでハンドシェイクを中止する必要があります（デフォルトでは、「unsupported_certificate」。詳細はセクション6.2を参照）。
If the server has multiple certificates, it chooses one of them based on the above-mentioned criteria (in addition to other criteria, such as transport-layer endpoint, local configuration, and preferences).
サーバーに複数の証明書がある場合、サーバーは上記の基準（トランスポート層エンドポイント、ローカル構成、設定などの他の基準に加えて）に基づいてそれらのいずれかを選択します。
The following rules apply to certificates sent by the client:
クライアントから送信される証明書には、次の規則が適用されます。
- The certificate type MUST be X.509v3 [RFC5280], unless explicitly negotiated otherwise (e.g., [RFC7250]).
- 明示的に別の方法でネゴシエートされない限り、証明書タイプはX.509v3 [RFC5280]でなければなりません（例：[RFC7250]）。
- If the "certificate_authorities" extension in the CertificateRequest message was present, at least one of the certificates in the certificate chain SHOULD be issued by one of the listed CAs.
- CertificateRequestメッセージに「certificate_authorities」拡張が存在する場合、証明書チェーン内の証明書の少なくとも1つが、リストされているCAの1つによって発行される必要があります。
- The certificates MUST be signed using an acceptable signature algorithm, as described in Section 4.3.2. Note that this relaxes the constraints on certificate-signing algorithms found in prior versions of TLS.
- 証明書は、セクション4.3.2で説明されているように、受け入れ可能な署名アルゴリズムを使用して署名する必要があります。 これにより、以前のバージョンのTLSで見つかった証明書署名アルゴリズムの制約が緩和されることに注意してください。
- If the CertificateRequest message contained a non-empty "oid_filters" extension, the end-entity certificate MUST match the extension OIDs that are recognized by the client, as described in Section 4.2.5.
- CertificateRequestメッセージに空でない「oid_filters」拡張が含まれている場合、エンドエンティティ証明書は、セクション4.2.5で説明されているように、クライアントによって認識される拡張OIDと一致する必要があります。
In general, detailed certificate validation procedures are out of scope for TLS (see [RFC5280]). This section provides TLS-specific requirements.
一般に、詳細な証明書検証手順はTLSの範囲外です（[RFC5280]を参照）。 このセクションでは、TLS固有の要件について説明します。
If the server supplies an empty Certificate message, the client MUST abort the handshake with a "decode_error" alert.
サーバーが空の証明書メッセージを提供する場合、クライアントは「decode_error」アラートでハンドシェイクを中止する必要があります。
If the client does not send any certificates (i.e., it sends an empty Certificate message), the server MAY at its discretion either continue the handshake without client authentication or abort the handshake with a "certificate_required" alert. Also, if some aspect of the certificate chain was unacceptable (e.g., it was not signed by a known, trusted CA), the server MAY at its discretion either continue the handshake (considering the client unauthenticated) or abort the handshake.
クライアントが証明書を送信しない場合（つまり、空の証明書メッセージを送信する場合）、サーバーはその裁量で、クライアント認証なしでハンドシェイクを続行するか、「certificate_required」アラートでハンドシェイクを中止する場合があります。 また、証明書チェーンの一部が受け入れられない場合（たとえば、既知の信頼できるCAによって署名されていない場合）、サーバーはその裁量でハンドシェイクを続行する（クライアントが認証されていないことを考慮する）か、ハンドシェイクを中止することができます。
Any endpoint receiving any certificate which it would need to validate using any signature algorithm using an MD5 hash MUST abort the handshake with a "bad_certificate" alert. SHA-1 is deprecated, and it is RECOMMENDED that any endpoint receiving any certificate which it would need to validate using any signature algorithm using a SHA-1 hash abort the handshake with a "bad_certificate" alert. For clarity, this means that endpoints can accept these algorithms for certificates that are self-signed or are trust anchors.
MD5ハッシュを使用する署名アルゴリズムを使用して検証する必要がある証明書を受信するエンドポイントは、「bad_certificate」アラートでハンドシェイクを中止する必要があります。 SHA-1は非推奨です。SHA-1ハッシュを使用する署名アルゴリズムを使用して検証する必要がある証明書を受信するエンドポイントは、「bad_certificate」アラートでハンドシェイクを中止することをお勧めします。 明確にするため、これは、エンドポイントが自己署名証明書またはトラストアンカーである証明書に対してこれらのアルゴリズムを受け入れることができることを意味します。
All endpoints are RECOMMENDED to transition to SHA-256 or better as soon as possible to maintain interoperability with implementations currently in the process of phasing out SHA-1 support.
すべてのエンドポイントは、SHA-1サポートを段階的に廃止している実装との相互運用性を維持するために、できるだけ早くSHA-256以上に移行することを推奨します。
Note that a certificate containing a key for one signature algorithm MAY be signed using a different signature algorithm (for instance, an RSA key signed with an ECDSA key).
1つの署名アルゴリズムのキーを含む証明書は、別の署名アルゴリズム（たとえば、ECDSAキーで署名されたRSAキー）を使用して署名される場合があります。
This message is used to provide explicit proof that an endpoint possesses the private key corresponding to its certificate. The CertificateVerify message also provides integrity for the handshake up to this point. Servers MUST send this message when authenticating via a certificate. Clients MUST send this message whenever authenticating via a certificate (i.e., when the Certificate message is non-empty). When sent, this message MUST appear immediately after the Certificate message and immediately prior to the Finished message.
このメッセージは、エンドポイントがその証明書に対応する秘密鍵を所有していることを明示的に証明するために使用されます。 CertificateVerifyメッセージは、この時点までのハンドシェイクの整合性も提供します。 サーバーは、証明書を介して認証するときにこのメッセージを送信する必要があります。 クライアントは、証明書を介して認証するたびに（つまり、証明書メッセージが空でない場合）このメッセージを送信する必要があります。 送信されると、このメッセージは、証明書メッセージの直後で、完了メッセージの直前に表示されなければなりません。
Structure of this message:
このメッセージの構造：
struct {
SignatureScheme algorithm;
opaque signature<0..2^16-1>;
} CertificateVerify;
The algorithm field specifies the signature algorithm used (see Section 4.2.3 for the definition of this type). The signature is a digital signature using that algorithm. The content that is covered under the signature is the hash output as described in Section 4.4.1, namely:
アルゴリズムフィールドは、使用される署名アルゴリズムを指定します（このタイプの定義については、セクション4.2.3を参照してください）。 署名は、そのアルゴリズムを使用したデジタル署名です。 署名の対象となるコンテンツは、セクション4.4.1で説明されているハッシュ出力です。
Transcript-Hash(Handshake Context, Certificate)
The digital signature is then computed over the concatenation of:
デジタル署名は、次の連結を介して計算されます。
- A string that consists of octet 32 (0x20) repeated 64 times
- 64回繰り返されるオクテット32（0x20）で構成される文字列
- The context string
- コンテキスト文字列
- A single 0 byte which serves as the separator
- セパレータとして機能する単一の0バイト
- The content to be signed
- 署名するコンテンツ
This structure is intended to prevent an attack on previous versions of TLS in which the ServerKeyExchange format meant that attackers could obtain a signature of a message with a chosen 32-byte prefix (ClientHello.random). The initial 64-byte pad clears that prefix along with the server-controlled ServerHello.random.
この構造は、ServerKeyExchange形式により、攻撃者が選択した32バイトのプレフィックス（ClientHello.random）を持つメッセージの署名を取得できることを意味する、以前のバージョンのTLSに対する攻撃を防ぐことを目的としています。 最初の64バイトパッドは、サーバー制御のServerHello.randomとともにそのプレフィックスをクリアします。
The context string for a server signature is "TLS 1.3, server CertificateVerify". The context string for a client signature is "TLS 1.3, client CertificateVerify". It is used to provide separation between signatures made in different contexts, helping against potential cross-protocol attacks.
サーバー署名のコンテキスト文字列は「TLS 1.3、サーバー証明書検証」です。 クライアント署名のコンテキスト文字列は「TLS 1.3、クライアント証明書検証」です。 異なるコンテキストで作成された署名を分離するために使用され、潜在的なクロスプロトコル攻撃を防ぎます。
For example, if the transcript hash was 32 bytes of 01 (this length would make sense for SHA-256), the content covered by the digital signature for a server CertificateVerify would be:
たとえば、トランスクリプトハッシュが32バイトの01であった場合（この長さはSHA-256にとって意味があります）、サーバーCertificateVerifyのデジタル署名でカバーされるコンテンツは次のようになります。
2020202020202020202020202020202020202020202020202020202020202020
2020202020202020202020202020202020202020202020202020202020202020
544c5320312e332c207365727665722043657274696669636174655665726966
79
00
0101010101010101010101010101010101010101010101010101010101010101
On the sender side, the process for computing the signature field of the CertificateVerify message takes as input:
送信側では、CertificateVerifyメッセージの署名フィールドを計算するプロセスが入力として使用されます。
- The content covered by the digital signature
- デジタル署名の対象となるコンテンツ
- The private signing key corresponding to the certificate sent in the previous message
- 前のメッセージで送信された証明書に対応する秘密署名キー
If the CertificateVerify message is sent by a server, the signature algorithm MUST be one offered in the client's "signature_algorithms" extension unless no valid certificate chain can be produced without unsupported algorithms (see Section 4.2.3).
CertificateVerifyメッセージがサーバーによって送信される場合、サポートされていないアルゴリズムなしで有効な証明書チェーンを作成できない場合を除き、署名アルゴリズムはクライアントの「signature_algorithms」拡張で提供されるものでなければなりません（セクション4.2.3を参照）。
If sent by a client, the signature algorithm used in the signature MUST be one of those present in the supported_signature_algorithms field of the "signature_algorithms" extension in the CertificateRequest message.
クライアントによって送信される場合、署名で使用される署名アルゴリズムは、CertificateRequestメッセージの「signature_algorithms」拡張機能のsupported_signature_algorithmsフィールドに存在するものの1つでなければなりません。
In addition, the signature algorithm MUST be compatible with the key in the sender's end-entity certificate. RSA signatures MUST use an RSASSA-PSS algorithm, regardless of whether RSASSA-PKCS1-v1_5 algorithms appear in "signature_algorithms". The SHA-1 algorithm MUST NOT be used in any signatures of CertificateVerify messages.
さらに、署名アルゴリズムは、送信者のエンドエンティティ証明書のキーと互換性がなければなりません。 RSASA-PKCS1-v1_5アルゴリズムが「signature_algorithms」に表示されるかどうかに関係なく、RSA署名はRSASSA-PSSアルゴリズムを使用する必要があります。 SHA-1アルゴリズムは、CertificateVerifyメッセージの署名で使用してはなりません。
All SHA-1 signature algorithms in this specification are defined solely for use in legacy certificates and are not valid for CertificateVerify signatures.
この仕様のすべてのSHA-1署名アルゴリズムは、レガシー証明書での使用のみを目的として定義されており、CertificateVerify署名には無効です。
The receiver of a CertificateVerify message MUST verify the signature field. The verification process takes as input:
CertificateVerifyメッセージの受信者は、署名フィールドを検証する必要があります。 検証プロセスは入力として使用します。
- The content covered by the digital signature
- デジタル署名の対象となるコンテンツ
- The public key contained in the end-entity certificate found in the associated Certificate message
- 関連する証明書メッセージにあるエンドエンティティ証明書に含まれる公開鍵
- The digital signature received in the signature field of the CertificateVerify message
- CertificateVerifyメッセージの署名フィールドで受信したデジタル署名
If the verification fails, the receiver MUST terminate the handshake with a "decrypt_error" alert.
検証に失敗した場合、受信者は「decrypt_error」アラートでハンドシェイクを終了する必要があります。
The Finished message is the final message in the Authentication Block. It is essential for providing authentication of the handshake and of the computed keys.
Finishedメッセージは、認証ブロックの最後のメッセージです。 ハンドシェイクと計算されたキーの認証を提供するために不可欠です。
Recipients of Finished messages MUST verify that the contents are correct and if incorrect MUST terminate the connection with a "decrypt_error" alert.
完了メッセージの受信者は、内容が正しいことを確認しなければならず、正しくない場合は「decrypt_error」アラートで接続を終了しなければなりません。
Once a side has sent its Finished message and has received and validated the Finished message from its peer, it may begin to send and receive Application Data over the connection. There are two settings in which it is permitted to send data prior to receiving the peer's Finished:
サイドがFinishedメッセージを送信し、ピアからFinishedメッセージを受信して検証すると、接続を介してアプリケーションデータの送受信を開始できます。 ピアのFinishedを受信する前にデータを送信することを許可される2つの設定があります。
1. Clients sending 0-RTT data as described in Section 4.2.10.
1. セクション4.2.10で説明されている0-RTTデータを送信するクライアント。
2. Servers MAY send data after sending their first flight, but because the handshake is not yet complete, they have no assurance of either the peer's identity or its liveness (i.e., the ClientHello might have been replayed).
2. サーバーは最初のフライトを送信した後にデータを送信できますが、ハンドシェイクがまだ完了していないため、ピアのIDまたはその活性（ClientHelloがリプレイされた可能性）の保証はありません。
The key used to compute the Finished message is computed from the Base Key defined in Section 4.4 using HKDF (see Section 7.1). Specifically:
Finishedメッセージの計算に使用されるキーは、HKDFを使用してセクション4.4で定義されたベースキーから計算されます（セクション7.1を参照）。 具体的には：
finished_key =
HKDF-Expand-Label(BaseKey, "finished", "", Hash.length)
Structure of this message:
このメッセージの構造：
struct {
opaque verify_data[Hash.length];
} Finished;
The verify_data value is computed as follows:
verify_data値は次のように計算されます。
verify_data =
HMAC(finished_key,
Transcript-Hash(Handshake Context,
Certificate*, CertificateVerify*))
* Only included if present.
*の要素は存在すれば含まれることを表しています。
HMAC [RFC2104] uses the Hash algorithm for the handshake. As noted above, the HMAC input can generally be implemented by a running hash, i.e., just the handshake hash at this point.
HMAC [RFC2104]は、ハンドシェイクにハッシュアルゴリズムを使用します。 上記のように、HMAC入力は通常、実行中のハッシュ、つまりこの時点でのハンドシェイクハッシュによって実装できます。
In previous versions of TLS, the verify_data was always 12 octets long. In TLS 1.3, it is the size of the HMAC output for the Hash used for the handshake.
TLSの以前のバージョンでは、verify_dataは常に12オクテット長でした。 TLS 1.3では、ハンドシェイクに使用されるハッシュのHMAC出力のサイズです。
Note: Alerts and any other non-handshake record types are not handshake messages and are not included in the hash computations.
注：アラートおよびその他の非ハンドシェイクレコードタイプはハンドシェイクメッセージではなく、ハッシュ計算には含まれません。
Any records following a Finished message MUST be encrypted under the appropriate application traffic key as described in Section 7.2. In particular, this includes any alerts sent by the server in response to client Certificate and CertificateVerify messages.
Finishedメッセージに続くレコードは、セクション7.2で説明されているように、適切なアプリケーショントラフィックキーの下で暗号化する必要があります。 特に、これには、クライアント証明書およびCertificateVerifyメッセージへの応答としてサーバーによって送信されるアラートが含まれます。
struct {} EndOfEarlyData;
If the server sent an "early_data" extension in EncryptedExtensions, the client MUST send an EndOfEarlyData message after receiving the server Finished. If the server does not send an "early_data" extension in EncryptedExtensions, then the client MUST NOT send an EndOfEarlyData message. This message indicates that all 0-RTT application_data messages, if any, have been transmitted and that the following records are protected under handshake traffic keys. Servers MUST NOT send this message, and clients receiving it MUST terminate the connection with an "unexpected_message" alert. This message is encrypted under keys derived from the client_early_traffic_secret.
サーバーがEncryptedExtensionsで「early_data」拡張機能を送信した場合、クライアントはサーバーFinishedを受信した後にEndOfEarlyDataメッセージを送信する必要があります。 サーバーがEncryptedExtensionsで「early_data」拡張を送信しない場合、クライアントはEndOfEarlyDataメッセージを送信してはなりません。 このメッセージは、すべての0-RTT application_dataメッセージがあれば送信されたこと、および後続のレコードがハンドシェイクトラフィックキーで保護されていることを示します。 サーバーはこのメッセージを送信してはならず、それを受信したクライアントは「unexpected_message」アラートで接続を終了しなければなりません。 このメッセージは、client_early_traffic_secretから派生したキーで暗号化されます。
TLS also allows other messages to be sent after the main handshake. These messages use a handshake content type and are encrypted under the appropriate application traffic key.
TLSでは、メインハンドシェイク後に他のメッセージを送信することもできます。 これらのメッセージはハンドシェイクコンテンツタイプを使用し、適切なアプリケーショントラフィックキーの下で暗号化されます。
At any time after the server has received the client Finished message, it MAY send a NewSessionTicket message. This message creates a unique association between the ticket value and a secret PSK derived from the resumption master secret (see Section 7).
サーバーがクライアントのFinishedメッセージを受信した後はいつでも、NewSessionTicketメッセージを送信できます。 このメッセージは、チケット値と再開マスターシークレットから派生したシークレットPSKの間に一意の関連付けを作成します（セクション7を参照）。
The client MAY use this PSK for future handshakes by including the ticket value in the "pre_shared_key" extension in its ClientHello (Section 4.2.11). Servers MAY send multiple tickets on a single connection, either immediately after each other or after specific events (see Appendix C.4). For instance, the server might send a new ticket after post-handshake authentication in order to encapsulate the additional client authentication state. Multiple tickets are useful for clients for a variety of purposes, including:
クライアントは、ClientHello（セクション4.2.11）の「pre_shared_key」拡張にチケット値を含めることにより、将来のハンドシェイクにこのPSKを使用する場合があります。 サーバーは、1つの接続で複数のチケットを送信する場合があります（それぞれの直後または特定のイベントの後）（付録C.4を参照）。 たとえば、サーバーは、追加のクライアント認証状態をカプセル化するために、ハンドシェイク後の認証後に新しいチケットを送信する場合があります。 複数のチケットは、クライアントにとって次のようなさまざまな目的に役立ちます。
- Opening multiple parallel HTTP connections.
- 複数の並列HTTP接続を開きます。
- Performing connection racing across interfaces and address families via (for example) Happy Eyeballs [RFC8305] or related techniques.
-（たとえば）Happy Eyeballs [RFC8305]または関連技術を介して、インターフェースおよびアドレスファミリ全体で接続レースを実行します。
Any ticket MUST only be resumed with a cipher suite that has the same KDF hash algorithm as that used to establish the original connection.
元の接続を確立するために使用したものと同じKDFハッシュアルゴリズムを持つ暗号スイートでのみ、チケットを再開する必要があります。
Clients MUST only resume if the new SNI value is valid for the server certificate presented in the original session and SHOULD only resume if the SNI value matches the one used in the original session. The latter is a performance optimization: normally, there is no reason to expect that different servers covered by a single certificate would be able to accept each other's tickets; hence, attempting resumption in that case would waste a single-use ticket. If such an indication is provided (externally or by any other means), clients MAY resume with a different SNI value.
クライアントは、新しいSNI値が元のセッションで提示されたサーバー証明書に対して有効である場合にのみ再開し、SNI値が元のセッションで使用された値と一致する場合にのみ再開する必要があります。 後者はパフォーマンスの最適化です。通常、単一の証明書でカバーされる異なるサーバーが互いのチケットを受け入れることができると期待する理由はありません。 したがって、その場合に再開を試みると、使い捨てチケットが無駄になります。 そのような指示が提供された場合（外部または他の手段）、クライアントは異なるSNI値で再開できます（MAY）。
On resumption, if reporting an SNI value to the calling application, implementations MUST use the value sent in the resumption ClientHello rather than the value sent in the previous session. Note that if a server implementation declines all PSK identities with different SNI values, these two values are always the same.
再開時に、呼び出し側アプリケーションにSNI値を報告する場合、実装は前のセッションで送信された値ではなく、再開ClientHelloで送信された値を使用する必要があります。 サーバー実装が異なるSNI値を持つすべてのPSK IDを拒否する場合、これら2つの値は常に同じであることに注意してください。
Note: Although the resumption master secret depends on the client's second flight, a server which does not request client authentication MAY compute the remainder of the transcript independently and then send a NewSessionTicket immediately upon sending its Finished rather than waiting for the client Finished. This might be appropriate in cases where the client is expected to open multiple TLS connections in parallel and would benefit from the reduced overhead of a resumption handshake, for example.
注：再開マスターシークレットはクライアントの2番目のフライトに依存しますが、クライアント認証を要求しないサーバーは、トランスクリプトの残りを個別に計算し、クライアントが終了するのを待つのではなく、Finishedを送信するとすぐにNewSessionTicketを送信する場合があります。 これは、クライアントが複数のTLS接続を並行して開くことが予想され、再開ハンドシェイクのオーバーヘッドの削減などの恩恵を受ける場合に適しています。
struct {
uint32 ticket_lifetime;
uint32 ticket_age_add;
opaque ticket_nonce<0..255>;
opaque ticket<1..2^16-1>;
Extension extensions<0..2^16-2>;
} NewSessionTicket;
ticket_lifetime: Indicates the lifetime in seconds as a 32-bit unsigned integer in network byte order from the time of ticket issuance. Servers MUST NOT use any value greater than 604800 seconds (7 days). The value of zero indicates that the ticket should be discarded immediately. Clients MUST NOT cache tickets for longer than 7 days, regardless of the ticket_lifetime, and MAY delete tickets earlier based on local policy. A server MAY treat a ticket as valid for a shorter period of time than what is stated in the ticket_lifetime.
ticket_lifetime：チケット発行時からのネットワークバイト順の32ビット符号なし整数として、ライフタイムを秒単位で示します。 サーバーは、604800秒（7日）を超える値を使用してはなりません。 値ゼロは、チケットをすぐに破棄する必要があることを示します。 クライアントは、ticket_lifetimeに関係なく、7日間以上チケットをキャッシュしてはならず、ローカルポリシーに基づいてチケットを早期に削除することができます。 サーバーは、ticket_lifetimeに記載されている期間よりも短い期間、チケットを有効として扱う場合があります。
ticket_age_add: A securely generated, random 32-bit value that is used to obscure the age of the ticket that the client includes in the "pre_shared_key" extension. The client-side ticket age is added to this value modulo 2^32 to obtain the value that is transmitted by the client. The server MUST generate a fresh value for each ticket it sends.
ticket_age_add：クライアントが「pre_shared_key」拡張に含めるチケットの有効期間をわかりにくくするために使用される、安全に生成されたランダムな32ビット値。 クライアント側のチケット経過時間は、この値に2 ^ 32を法として加算され、クライアントによって送信される値を取得します。 サーバーは、送信するチケットごとに新しい値を生成する必要があります。
ticket_nonce: A per-ticket value that is unique across all tickets issued on this connection.
ticket_nonce：この接続で発行されたすべてのチケットで一意のチケットごとの値。
ticket: The value of the ticket to be used as the PSK identity. The ticket itself is an opaque label. It MAY be either a database lookup key or a self-encrypted and self-authenticated value.
ticket：PSK IDとして使用されるチケットの値。 チケット自体は不透明なラベルです。 データベース検索キーまたは自己暗号化および自己認証値のいずれかです。
extensions: A set of extension values for the ticket. The "Extension" format is defined in Section 4.2. Clients MUST ignore unrecognized extensions.
extensions：チケットの拡張値のセット。 「拡張」形式はセクション4.2で定義されています。 クライアントは認識されない拡張子を無視しなければなりません。
The sole extension currently defined for NewSessionTicket is "early_data", indicating that the ticket may be used to send 0-RTT data (Section 4.2.10). It contains the following value:
NewSessionTicketに現在定義されている唯一の拡張子は「early_data」であり、0-RTTデータの送信にチケットを使用できることを示します（4.2.10項）。 次の値が含まれます。
max_early_data_size: The maximum amount of 0-RTT data that the client is allowed to send when using this ticket, in bytes. Only Application Data payload (i.e., plaintext but not padding or the inner content type byte) is counted. A server receiving more than max_early_data_size bytes of 0-RTT data SHOULD terminate the connection with an "unexpected_message" alert. Note that servers that reject early data due to lack of cryptographic material will be unable to differentiate padding from content, so clients SHOULD NOT depend on being able to send large quantities of padding in early data records.
max_early_data_size：このチケットの使用時にクライアントが送信できる0-RTTデータの最大量（バイト単位）。 アプリケーションデータペイロード（つまり、パディングまたは内部コンテンツタイプバイトではなく、プレーンテキスト）のみがカウントされます。 max-early_data_sizeバイトを超える0-RTTデータを受信するサーバーは、「unexpected_message」アラートで接続を終了する必要があります。 暗号化材料の不足により初期データを拒否するサーバーは、コンテンツとパディングを区別できないため、クライアントは初期データレコードで大量のパディングを送信できることに依存してはならないことに注意してください。
The PSK associated with the ticket is computed as:
チケットに関連付けられたPSKは、次のように計算されます。
HKDF-Expand-Label(resumption_master_secret,
"resumption", ticket_nonce, Hash.length)
Because the ticket_nonce value is distinct for each NewSessionTicket message, a different PSK will be derived for each ticket.
ticket_nonce値はNewSessionTicketメッセージごとに異なるため、チケットごとに異なるPSKが導出されます。
Note that in principle it is possible to continue issuing new tickets which indefinitely extend the lifetime of the keying material originally derived from an initial non-PSK handshake (which was most likely tied to the peer's certificate). It is RECOMMENDED that implementations place limits on the total lifetime of such keying material; these limits should take into account the lifetime of the peer's certificate, the likelihood of intervening revocation, and the time since the peer's online CertificateVerify signature.
原則として、最初に非PSKハンドシェイク（ピアの証明書に結び付けられている可能性が最も高い）から最初に導出されたキー情報の有効期間を無期限に延長する新しいチケットを発行し続けることができることに注意してください。 実装では、このような鍵素材の総寿命に制限を設けることが推奨されます。 これらの制限では、ピアの証明書の有効期間、取り消しの介入の可能性、およびピアのオンラインCertificateVerify署名からの時間を考慮する必要があります。
When the client has sent the "post_handshake_auth" extension (see Section 4.2.6), a server MAY request client authentication at any time after the handshake has completed by sending a CertificateRequest message. The client MUST respond with the appropriate Authentication messages (see Section 4.4). If the client chooses to authenticate, it MUST send Certificate, CertificateVerify, and Finished. If it declines, it MUST send a Certificate message containing no certificates followed by Finished. All of the client's messages for a given response MUST appear consecutively on the wire with no intervening messages of other types.
クライアントが「post_handshake_auth」拡張機能（セクション4.2.6を参照）を送信すると、サーバーはCertificateRequestメッセージを送信してハンドシェイクが完了した後、いつでもクライアント認証を要求できます。 クライアントは適切な認証メッセージで応答しなければなりません（セクション4.4を参照）。 クライアントが認証を選択した場合、証明書、CertificateVerify、およびFinishedを送信する必要があります。 拒否する場合、証明書を含まない証明書メッセージを送信し、その後に「完了」を送信する必要があります。 所定の応答に対するクライアントのメッセージはすべて、他のタイプのメッセージを介在させずに、連続してネットワーク上に表示される必要があります。
A client that receives a CertificateRequest message without having sent the "post_handshake_auth" extension MUST send an "unexpected_message" fatal alert.
「post_handshake_auth」拡張機能を送信せずにCertificateRequestメッセージを受信したクライアントは、「unexpected_message」致命的なアラートを送信する必要があります。
Note: Because client authentication could involve prompting the user, servers MUST be prepared for some delay, including receiving an arbitrary number of other messages between sending the CertificateRequest and receiving a response. In addition, clients which receive multiple CertificateRequests in close succession MAY respond to them in a different order than they were received (the certificate_request_context value allows the server to disambiguate the responses).
注：クライアント認証にはユーザーへのプロンプトが含まれる可能性があるため、サーバーはCertificateRequestの送信と応答の受信の間に任意の数の他のメッセージを受信することを含め、ある程度の遅延に備えなければなりません。 さらに、複数のCertificateRequestを連続して受信するクライアントは、受信した順序とは異なる順序で応答する場合があります（certificate_request_context値により、サーバーは応答を明確にすることができます）。
The KeyUpdate handshake message is used to indicate that the sender is updating its sending cryptographic keys. This message can be sent by either peer after it has sent a Finished message. Implementations that receive a KeyUpdate message prior to receiving a Finished message MUST terminate the connection with an "unexpected_message" alert. After sending a KeyUpdate message, the sender SHALL send all its traffic using the next generation of keys, computed as described in Section 7.2. Upon receiving a KeyUpdate, the receiver MUST update its receiving keys.
KeyUpdateハンドシェイクメッセージは、送信者が送信暗号キーを更新していることを示すために使用されます。 このメッセージは、Finishedメッセージを送信した後、どちらのピアからも送信できます。 Finishedメッセージを受信する前にKeyUpdateメッセージを受信する実装は、「unexpected_message」アラートで接続を終了する必要があります。 KeyUpdateメッセージを送信した後、送信者は、セクション7.2で説明されているように計算された次世代のキーを使用して、すべてのトラフィックを送信する必要があります。 KeyUpdateを受信すると、受信者は受信キーを更新する必要があります。
enum {
update_not_requested(0), update_requested(1), (255)
} KeyUpdateRequest;
struct {
KeyUpdateRequest request_update;
} KeyUpdate;
request_update: Indicates whether the recipient of the KeyUpdate should respond with its own KeyUpdate. If an implementation receives any other value, it MUST terminate the connection with an "illegal_parameter" alert.
request_update：KeyUpdateの受信者が独自のKeyUpdateで応答するかどうかを示します。 実装が他の値を受け取った場合、「illegal_parameter」アラートで接続を終了する必要があります。
If the request_update field is set to "update_requested", then the receiver MUST send a KeyUpdate of its own with request_update set to "update_not_requested" prior to sending its next Application Data record. This mechanism allows either side to force an update to the entire connection, but causes an implementation which receives multiple KeyUpdates while it is silent to respond with a single update. Note that implementations may receive an arbitrary number of messages between sending a KeyUpdate with request_update set to "update_requested" and receiving the peer's KeyUpdate, because those messages may already be in flight. However, because send and receive keys are derived from independent traffic secrets, retaining the receive traffic secret does not threaten the forward secrecy of data sent before the sender changed keys.
request_updateフィールドが「update_requested」に設定されている場合、受信者は、次のアプリケーションデータレコードを送信する前にrequest_updateを「update_not_requested」に設定して独自のKeyUpdateを送信する必要があります。 このメカニズムにより、どちらの側も接続全体を強制的に更新できますが、単一の更新で応答することをサイレントにしながら複数のKeyUpdateを受信する実装が発生します。 request_updateを "update_requested"に設定してKeyUpdateを送信してからピアのKeyUpdateを受信するまでの間に、実装は任意の数のメッセージを受信する可能性があることに注意してください。 ただし、送信キーと受信キーは独立したトラフィックシークレットから取得されるため、受信トラフィックシークレットを保持しても、送信者がキーを変更する前に送信されるデータの前方秘匿を脅かすことはありません。
If implementations independently send their own KeyUpdates with request_update set to "update_requested" and they cross in flight, then each side will also send a response, with the result that each side increments by two generations.
実装がrequest_updateを "update_requested"に設定して独自にKeyUpdatesを個別に送信し、それらが飛行中に交差する場合、各サイドは応答を送信し、その結果、各サイドは2世代ずつ増加します。
Both sender and receiver MUST encrypt their KeyUpdate messages with the old keys. Additionally, both sides MUST enforce that a KeyUpdate with the old key is received before accepting any messages encrypted with the new key. Failure to do so may allow message truncation attacks.
送信者と受信者の両方が古いキーでKeyUpdateメッセージを暗号化しなければなりません。 さらに、両方の側は、新しいキーで暗号化されたメッセージを受け入れる前に、古いキーでKeyUpdateを受信することを強制する必要があります。 そうしないと、メッセージの切り捨て攻撃が許可される場合があります。
The TLS record protocol takes messages to be transmitted, fragments the data into manageable blocks, protects the records, and transmits the result. Received data is verified, decrypted, reassembled, and then delivered to higher-level clients.
TLSレコードプロトコルは、送信されるメッセージを受け取り、データを管理可能なブロックに断片化し、レコードを保護し、結果を送信します。 受信したデータは、検証、復号化、再構築されてから、上位レベルのクライアントに配信されます。
TLS records are typed, which allows multiple higher-level protocols to be multiplexed over the same record layer. This document specifies four content types: handshake, application_data, alert, and change_cipher_spec. The change_cipher_spec record is used only for compatibility purposes (see Appendix D.4).
TLSレコードが入力されるため、複数の高レベルプロトコルを同じレコードレイヤー上で多重化できます。 このドキュメントでは、ハンドシェイク、application_data、alert、change_cipher_specの4つのコンテンツタイプを指定しています。 change_cipher_specレコードは、互換性のためにのみ使用されます（付録D.4を参照）。
An implementation may receive an unencrypted record of type change_cipher_spec consisting of the single byte value 0x01 at any time after the first ClientHello message has been sent or received and before the peer's Finished message has been received and MUST simply drop it without further processing. Note that this record may appear at a point at the handshake where the implementation is expecting protected records, and so it is necessary to detect this condition prior to attempting to deprotect the record. An implementation which receives any other change_cipher_spec value or which receives a protected change_cipher_spec record MUST abort the handshake with an "unexpected_message" alert. If an implementation detects a change_cipher_spec record received before the first ClientHello message or after the peer's Finished message, it MUST be treated as an unexpected record type (though stateless servers may not be able to distinguish these cases from allowed cases).
実装は、最初のClientHelloメッセージが送信または受信された後、ピアのFinishedメッセージが受信される前に、いつでもシングルバイト値0x01で構成されるchange_cipher_spec型の暗号化されていないレコードを受信し、それ以上処理せずに単にドロップしなければなりません。 このレコードは、実装が保護されたレコードを期待しているハンドシェイクの時点で表示される可能性があるため、レコードの保護を解除する前にこの状態を検出する必要があることに注意してください。 他のchange_cipher_spec値を受け取るか、保護されたchange_cipher_specレコードを受け取る実装は、「unexpected_message」アラートでハンドシェイクを中止しなければなりません。 実装が、最初のClientHelloメッセージの前、またはピアのFinishedメッセージの後に受信したchange_cipher_specレコードを検出した場合、予期しないレコードタイプとして扱わなければなりません（ステートレスサーバーはこれらのケースを許可されたケースと区別できない場合があります）。
Implementations MUST NOT send record types not defined in this document unless negotiated by some extension. If a TLS implementation receives an unexpected record type, it MUST terminate the connection with an "unexpected_message" alert. New record content type values are assigned by IANA in the TLS ContentType registry as described in Section 11.
実装は、何らかの拡張によってネゴシエートされない限り、このドキュメントで定義されていないレコードタイプを送信してはなりません。 TLS実装が予期しないレコードタイプを受信した場合、「unexpected_message」アラートで接続を終了する必要があります。 セクション11で説明されているように、新しいレコードコンテンツタイプ値は、TLS ContentTypeレジストリのIANAによって割り当てられます。
The record layer fragments information blocks into TLSPlaintext records carrying data in chunks of 2^14 bytes or less. Message boundaries are handled differently depending on the underlying ContentType. Any future content types MUST specify appropriate rules. Note that these rules are stricter than what was enforced in TLS 1.2.
レコード層は、情報ブロックを2 ^ 14バイト以下のチャンクでデータを運ぶTLSPlaintextレコードに断片化します。 メッセージ境界は、基礎となるContentTypeに応じて異なる方法で処理されます。 将来のコンテンツタイプでは、適切なルールを指定する必要があります。 これらの規則は、TLS 1.2で施行されたものよりも厳しいことに注意してください。
Handshake messages MAY be coalesced into a single TLSPlaintext record or fragmented across several records, provided that:
ハンドシェイクメッセージは、単一のTLSPlaintextレコードに結合されるか、複数のレコードに分割される場合があります。
- Handshake messages MUST NOT be interleaved with other record types. That is, if a handshake message is split over two or more records, there MUST NOT be any other records between them.
- ハンドシェイクメッセージは、他のレコードタイプとインターリーブしてはなりません。 つまり、ハンドシェイクメッセージが2つ以上のレコードに分割される場合、それらの間に他のレコードがあってはなりません。
- Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary.
- ハンドシェイクメッセージは、キーの変更にまたがってはなりません。 実装は、キー変更の直前のすべてのメッセージがレコード境界に沿っていることを確認する必要があります。 そうでない場合は、「unexpected_message」アラートで接続を終了する必要があります。 ClientHello、EndOfEarlyData、ServerHello、Finished、およびKeyUpdateメッセージはキー変更の直前に送信できるため、実装はこれらのメッセージをレコード境界に合わせて送信する必要があります。
Implementations MUST NOT send zero-length fragments of Handshake types, even if those fragments contain padding.
実装は、それらのフラグメントにパディングが含まれている場合でも、ハンドシェイクタイプの長さゼロのフラグメントを送信してはなりません。
Alert messages (Section 6) MUST NOT be fragmented across records, and multiple alert messages MUST NOT be coalesced into a single TLSPlaintext record. In other words, a record with an Alert type MUST contain exactly one message.
アラートメッセージ（セクション6）はレコード間で断片化してはならず、複数のアラートメッセージを単一のTLSPlaintextレコードに結合してはなりません。 言い換えると、Alertタイプのレコードには、メッセージを1つだけ含める必要があります。
Application Data messages contain data that is opaque to TLS. Application Data messages are always protected. Zero-length fragments of Application Data MAY be sent, as they are potentially useful as a traffic analysis countermeasure. Application Data fragments MAY be split across multiple records or coalesced into a single record.
アプリケーションデータメッセージには、TLSに対して不透明なデータが含まれています。 アプリケーションデータメッセージは常に保護されます。 アプリケーションデータの長さゼロのフラグメントは、トラフィック分析対策として潜在的に有用であるため、送信できます。 アプリケーションデータフラグメントは、複数のレコードに分割するか、単一のレコードに合体させることができます。
enum {
invalid(0),
change_cipher_spec(20),
alert(21),
handshake(22),
application_data(23),
(255)
} ContentType;
struct {
ContentType type;
ProtocolVersion legacy_record_version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
type: The higher-level protocol used to process the enclosed fragment.
type：囲まれたフラグメントの処理に使用される高レベルのプロトコル。
legacy_record_version: MUST be set to 0x0303 for all records generated by a TLS 1.3 implementation other than an initial ClientHello (i.e., one not generated after a HelloRetryRequest), where it MAY also be 0x0301 for compatibility purposes. This field is deprecated and MUST be ignored for all purposes. Previous versions of TLS would use other values in this field under some circumstances.
legacy_record_version：初期ClientHello（つまり、HelloRetryRequestの後に生成されないもの）以外のTLS 1.3実装によって生成されたすべてのレコードの0x0303に設定する必要があります。互換性のために0x0301にすることもできます。 このフィールドは非推奨であり、すべての目的で無視する必要があります。 TLSの以前のバージョンでは、状況によってはこのフィールドに他の値を使用していました。
length: The length (in bytes) of the following TLSPlaintext.fragment. The length MUST NOT exceed 2^14 bytes. An endpoint that receives a record that exceeds this length MUST terminate the connection with a "record_overflow" alert.
length：次のTLSPlaintext.fragmentの長さ（バイト単位）。 長さは2 ^ 14バイトを超えてはなりません。 この長さを超えるレコードを受信するエンドポイントは、「record_overflow」アラートで接続を終了する必要があります。
fragment: The data being transmitted. This value is transparent and is treated as an independent block to be dealt with by the higher-level protocol specified by the type field.
fragment：送信されるデータ。 この値は透過的であり、typeフィールドで指定された上位プロトコルで処理される独立したブロックとして扱われます。
This document describes TLS 1.3, which uses the version 0x0304. This version value is historical, deriving from the use of 0x0301 for TLS 1.0 and 0x0300 for SSL 3.0. In order to maximize backward compatibility, a record containing an initial ClientHello SHOULD have version 0x0301 (reflecting TLS 1.0) and a record containing a second ClientHello or a ServerHello MUST have version 0x0303 (reflecting TLS 1.2). When negotiating prior versions of TLS, endpoints follow the procedure and requirements provided in Appendix D.
このドキュメントでは、バージョン0x0304を使用するTLS 1.3について説明します。 このバージョン値は歴史的であり、TLS 1.0では0x0301、SSL 3.0では0x0300を使用しています。 後方互換性を最大化するために、初期ClientHelloを含むレコードはバージョン0x0301（TLS 1.0を反映）を持ち、2番目のClientHelloまたはServerHelloを含むレコードはバージョン0x0303（TLS 1.2を反映）を持たなければなりません。 TLSの以前のバージョンをネゴシエートする場合、エンドポイントは付録Dで提供される手順と要件に従います。
When record protection has not yet been engaged, TLSPlaintext structures are written directly onto the wire. Once record protection has started, TLSPlaintext records are protected and sent as described in the following section. Note that Application Data records MUST NOT be written to the wire unprotected (see Section 2 for details).
レコード保護がまだ有効になっていない場合、TLSPlaintext構造は直接ワイヤに書き込まれます。 レコード保護が開始されると、TLSPlaintextレコードは保護され、次のセクションで説明するように送信されます。 アプリケーションデータレコードは、保護されていないワイヤに書き込まれてはならないことに注意してください（詳細については、セクション2を参照）。
The record protection functions translate a TLSPlaintext structure into a TLSCiphertext structure. The deprotection functions reverse the process. In TLS 1.3, as opposed to previous versions of TLS, all ciphers are modeled as "Authenticated Encryption with Associated Data" (AEAD) [RFC5116]. AEAD functions provide a unified encryption and authentication operation which turns plaintext into authenticated ciphertext and back again. Each encrypted record consists of a plaintext header followed by an encrypted body, which itself contains a type and optional padding.
レコード保護機能は、TLSPlaintext構造をTLSCiphertext構造に変換します。 脱保護機能はプロセスを逆にします。 TLS 1.3では、以前のバージョンのTLSとは異なり、すべての暗号は「関連データによる認証済み暗号化」（AEAD）[RFC5116]としてモデル化されています。 AEAD機能は、平文を認証済み暗号文に変換し、再び元に戻す、統一された暗号化および認証操作を提供します。 暗号化された各レコードは、プレーンテキストヘッダーとそれに続く暗号化された本文で構成されます。暗号化された本文には、タイプとオプションのパディングが含まれます。
struct {
opaque content[TLSPlaintext.length];
ContentType type;
uint8 zeros[length_of_padding];
} TLSInnerPlaintext;
struct {
ContentType opaque_type = application_data; /* 23 */
ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */
uint16 length;
opaque encrypted_record[TLSCiphertext.length];
} TLSCiphertext;
content: The TLSPlaintext.fragment value, containing the byte encoding of a handshake or an alert message, or the raw bytes of the application's data to send.
content：TLSPlaintext.fragment値。ハンドシェイクまたはアラートメッセージのバイトエンコード、または送信するアプリケーションデータの生バイトを含みます。
type: The TLSPlaintext.type value containing the content type of the record.
type：レコードのコンテンツタイプを含むTLSPlaintext.type値。
zeros: An arbitrary-length run of zero-valued bytes may appear in the cleartext after the type field. This provides an opportunity for senders to pad any TLS record by a chosen amount as long as the total stays within record size limits. See Section 5.4 for more details.
zeros：ゼロ値のバイトの任意の長さの実行が、タイプフィールドの後にクリアテキストに表示される場合があります。 これにより、送信者は、合計がレコードサイズの制限内にある限り、選択した量だけTLSレコードをパディングできます。 詳細については、セクション5.4を参照してください。
opaque_type: The outer opaque_type field of a TLSCiphertext record is always set to the value 23 (application_data) for outward compatibility with middleboxes accustomed to parsing previous versions of TLS. The actual content type of the record is found in TLSInnerPlaintext.type after decryption.
opaque_type：TLSCiphertextレコードの外側のopaque_typeフィールドは、以前のバージョンのTLSの解析に慣れているミドルボックスとの外部互換性のために、常に値23（application_data）に設定されます。 レコードの実際のコンテンツタイプは、復号化後にTLSInnerPlaintext.typeで見つかります。
legacy_record_version: The legacy_record_version field is always 0x0303. TLS 1.3 TLSCiphertexts are not generated until after TLS 1.3 has been negotiated, so there are no historical compatibility concerns where other values might be received. Note that the handshake protocol, including the ClientHello and ServerHello messages, authenticates the protocol version, so this value is redundant.
legacy_record_version：legacy_record_versionフィールドは常に0x0303です。 TLS 1.3 TLSCiphertextは、TLS 1.3がネゴシエートされるまで生成されないため、他の値が受信される可能性のある歴史的な互換性の問題はありません。 ClientHelloおよびServerHelloメッセージを含むハンドシェイクプロトコルはプロトコルバージョンを認証するため、この値は冗長であることに注意してください。
length: The length (in bytes) of the following TLSCiphertext.encrypted_record, which is the sum of the lengths of the content and the padding, plus one for the inner content type, plus any expansion added by the AEAD algorithm. The length MUST NOT exceed 2^14 + 256 bytes. An endpoint that receives a record that exceeds this length MUST terminate the connection with a "record_overflow" alert.
length：次のTLSCiphertext.encrypted_recordの長さ（バイト単位）。これは、コンテンツとパディングの長さの合計に、内部コンテンツタイプに1つを加え、AEADアルゴリズムによって追加された拡張を加えたものです。 長さは2 ^ 14 + 256バイトを超えてはなりません。 この長さを超えるレコードを受信するエンドポイントは、「record_overflow」アラートで接続を終了する必要があります。
encrypted_record: The AEAD-encrypted form of the serialized TLSInnerPlaintext structure.
encrypted_record：シリアル化されたTLSInnerPlaintext構造のAEAD暗号化形式。
AEAD algorithms take as input a single key, a nonce, a plaintext, and "additional data" to be included in the authentication check, as described in Section 2.1 of [RFC5116]. The key is either the client_write_key or the server_write_key, the nonce is derived from the sequence number and the client_write_iv or server_write_iv (see Section 5.3), and the additional data input is the record header.
[RFC5116]のセクション2.1で説明されているように、AEADアルゴリズムは、入力として単一のキー、ナンス、プレーンテキスト、および認証チェックに含まれる「追加データ」を受け取ります。 キーはclient_write_keyまたはserver_write_keyのいずれかであり、ノンスはシーケンス番号とclient_write_ivまたはserver_write_iv（セクション5.3を参照）から派生し、追加のデータ入力はレコードヘッダーです。
I.e.,
つまり、
additional_data = TLSCiphertext.opaque_type ||
TLSCiphertext.legacy_record_version ||
TLSCiphertext.length
The plaintext input to the AEAD algorithm is the encoded TLSInnerPlaintext structure. Derivation of traffic keys is defined in Section 7.3.
AEADアルゴリズムへのプレーンテキスト入力は、エンコードされたTLSInnerPlaintext構造です。 トラフィックキーの派生は、セクション7.3で定義されています。
The AEAD output consists of the ciphertext output from the AEAD encryption operation. The length of the plaintext is greater than the corresponding TLSPlaintext.length due to the inclusion of TLSInnerPlaintext.type and any padding supplied by the sender. The length of the AEAD output will generally be larger than the plaintext, but by an amount that varies with the AEAD algorithm.
AEAD出力は、AEAD暗号化操作からの暗号文出力で構成されます。 平文の長さは、TLSInnerPlaintext.typeと送信者が提供するパディングが含まれているため、対応するTLSPlaintext.lengthよりも長くなっています。 AEAD出力の長さは通常、平文よりも長くなりますが、AEADアルゴリズムによって異なります。
Since the ciphers might incorporate padding, the amount of overhead could vary with different lengths of plaintext. Symbolically,
暗号にはパディングが組み込まれている場合があるため、オーバーヘッドの量はプレーンテキストの長さによって異なる場合があります。 記号的に、
AEADEncrypted =
AEAD-Encrypt(write_key, nonce, additional_data, plaintext)
The encrypted_record field of TLSCiphertext is set to AEADEncrypted.
TLSCiphertextのencrypted_recordフィールドは、AEADEncryptedに設定されます。
In order to decrypt and verify, the cipher takes as input the key, nonce, additional data, and the AEADEncrypted value. The output is either the plaintext or an error indicating that the decryption failed. There is no separate integrity check. Symbolically,
暗号化を解除して検証するために、暗号は入力としてキー、ノンス、追加データ、およびAEADEncrypted値を受け取ります。 出力は、平文または復号化が失敗したことを示すエラーです。 個別の整合性チェックはありません。 象徴的に、
plaintext of encrypted_record =
AEAD-Decrypt(peer_write_key, nonce,
additional_data, AEADEncrypted)
If the decryption fails, the receiver MUST terminate the connection with a "bad_record_mac" alert.
復号化に失敗した場合、受信者は「bad_record_mac」アラートで接続を終了する必要があります。
An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion greater than 255 octets. An endpoint that receives a record from its peer with TLSCiphertext.length larger than 2^14 + 256 octets MUST terminate the connection with a "record_overflow" alert. This limit is derived from the maximum TLSInnerPlaintext length of 2^14 octets + 1 octet for ContentType + the maximum AEAD expansion of 255 octets.
TLS 1.3で使用されるAEADアルゴリズムは、255オクテットを超える拡張を生成してはなりません。 TLSCiphertext.lengthが2 ^ 14 + 256オクテットより大きいピアからレコードを受信するエンドポイントは、「record_overflow」アラートで接続を終了する必要があります。 この制限は、TLSInnerPlaintextの最大長2 ^ 14オクテット+ ContentTypeの1オクテット+最大AEAD拡張255オクテットから導出されます。
A 64-bit sequence number is maintained separately for reading and writing records. The appropriate sequence number is incremented by one after reading or writing each record. Each sequence number is set to zero at the beginning of a connection and whenever the key is changed; the first record transmitted under a particular traffic key MUST use sequence number 0.
64ビットのシーケンス番号は、レコードの読み取りと書き込みのために個別に維持されます。 適切なシーケンス番号は、各レコードの読み取りまたは書き込み後に1ずつ増加します。 各シーケンス番号は、接続の開始時およびキーが変更されるたびにゼロに設定されます。 特定のトラフィックキーの下で送信される最初のレコードは、シーケンス番号0を使用する必要があります。
Because the size of sequence numbers is 64-bit, they should not wrap. If a TLS implementation would need to wrap a sequence number, it MUST either rekey (Section 4.6.3) or terminate the connection.
シーケンス番号のサイズは64ビットであるため、折り返さないでください。 TLS実装がシーケンス番号をラップする必要がある場合、キーを再生成（セクション4.6.3）するか、接続を終了する必要があります。
Each AEAD algorithm will specify a range of possible lengths for the per-record nonce, from N_MIN bytes to N_MAX bytes of input [RFC5116]. The length of the TLS per-record nonce (iv_length) is set to the larger of 8 bytes and N_MIN for the AEAD algorithm (see [RFC5116], Section 4). An AEAD algorithm where N_MAX is less than 8 bytes MUST NOT be used with TLS. The per-record nonce for the AEAD construction is formed as follows:
各AEADアルゴリズムは、入力ごとのN_MINバイトからN_MAXバイトまでのレコードごとのノンスの可能な長さの範囲を指定します[RFC5116]。 TLSレコードごとのノンスの長さ（iv_length）は、AEADアルゴリズムの8バイトとN_MINの大きい方に設定されます（[RFC5116]、セクション] 4を参照）。 N_MAXが8バイト未満のAEADアルゴリズムは、TLSと共に使用してはなりません（MUST NOT）。 AEAD構造のレコードごとのナンスは、次のように形成されます。
1. The 64-bit record sequence number is encoded in network byte order and padded to the left with zeros to iv_length.
1. 64ビットのレコードシーケンス番号は、ネットワークバイト順でエンコードされ、iv_lengthまでゼロが左側に埋め込まれます。
2. The padded sequence number is XORed with either the static client_write_iv or server_write_iv (depending on the role).
2.埋め込まれたシーケンス番号は、静的なclient_write_ivまたはserver_write_iv（役割に応じて）とXORされます。
The resulting quantity (of length iv_length) is used as the per-record nonce.
結果の量（長さiv_length）は、レコードごとのノンスとして使用されます。
Note: This is a different construction from that in TLS 1.2, which specified a partially explicit nonce.
注：これは、部分的に明示的なナンスを指定したTLS 1.2の構成とは異なります。
All encrypted TLS records can be padded to inflate the size of the TLSCiphertext. This allows the sender to hide the size of the traffic from an observer.
暗号化されたすべてのTLSレコードをパディングして、TLSCiphertextのサイズを拡張できます。 これにより、送信者はオブザーバーからトラフィックのサイズを隠すことができます。
When generating a TLSCiphertext record, implementations MAY choose to pad. An unpadded record is just a record with a padding length of zero. Padding is a string of zero-valued bytes appended to the ContentType field before encryption. Implementations MUST set the padding octets to all zeros before encrypting.
TLSCiphertextレコードを生成するとき、実装は埋め込みを選択できます。 パディングなしのレコードは、パディングの長さがゼロの単なるレコードです。 パディングは、暗号化の前にContentTypeフィールドに追加されるゼロ値バイトの文字列です。 実装は、暗号化の前にパディングオクテットをすべてゼロに設定する必要があります。
Application Data records may contain a zero-length TLSInnerPlaintext.content if the sender desires. This permits generation of plausibly sized cover traffic in contexts where the presence or absence of activity may be sensitive. Implementations MUST NOT send Handshake and Alert records that have a zero-length TLSInnerPlaintext.content; if such a message is received, the receiving implementation MUST terminate the connection with an "unexpected_message" alert.
送信者が希望する場合、アプリケーションデータレコードには長さゼロのTLSInnerPlaintext.contentが含まれる場合があります。 これにより、アクティビティの有無が重要な状況で、妥当なサイズのカバートラフィックを生成できます。 実装は、長さがゼロのTLSInnerPlaintext.contentを持つHandshakeおよびAlertレコードを送信してはなりません。 そのようなメッセージが受信された場合、受信実装は「unexpected_message」アラートで接続を終了しなければなりません。
The padding sent is automatically verified by the record protection mechanism; upon successful decryption of a TLSCiphertext.encrypted_record, the receiving implementation scans the field from the end toward the beginning until it finds a non-zero octet. This non-zero octet is the content type of the message. This padding scheme was selected because it allows padding of any encrypted TLS record by an arbitrary size (from zero up to TLS record size limits) without introducing new content types. The design also enforces all-zero padding octets, which allows for quick detection of padding errors.
送信されたパディングは、レコード保護メカニズムによって自動的に検証されます。 TLSCiphertext.encrypted_recordの復号化に成功すると、受信実装は、ゼロ以外のオクテットが見つかるまで、フィールドを最後から最初に向かってスキャンします。 このゼロ以外のオクテットは、メッセージのコンテンツタイプです。 このパディング方式が選択されたのは、新しいコンテンツタイプを導入することなく、任意のサイズ（ゼロからTLSレコードサイズ制限まで）で暗号化されたTLSレコードをパディングできるためです。 この設計では、すべてゼロのパディングオクテットも適用されます。これにより、パディングエラーをすばやく検出できます。
Implementations MUST limit their scanning to the cleartext returned from the AEAD decryption. If a receiving implementation does not find a non-zero octet in the cleartext, it MUST terminate the connection with an "unexpected_message" alert.
実装は、スキャンをAEAD復号化から返されたクリアテキストに制限する必要があります。 受信側の実装がクリアテキストでゼロ以外のオクテットを見つけられない場合、「unexpected_message」アラートで接続を終了する必要があります。
The presence of padding does not change the overall record size limitations: the full encoded TLSInnerPlaintext MUST NOT exceed 2^14 + 1 octets. If the maximum fragment length is reduced -- as, for example, by the record_size_limit extension from [RFC8449] -- then the reduced limit applies to the full plaintext, including the content type and padding.
パディングの存在は、全体的なレコードサイズの制限を変更しません。完全にエンコードされたTLSInnerPlaintextは、2 ^ 14 + 1オクテットを超えてはなりません。 [RFC8449]のrecord_size_limit拡張などにより、最大フラグメント長が短縮される場合、短縮された制限は、コンテンツタイプとパディングを含む完全なプレーンテキストに適用されます。
Selecting a padding policy that suggests when and how much to pad is a complex topic and is beyond the scope of this specification. If the application-layer protocol on top of TLS has its own padding, it may be preferable to pad Application Data TLS records within the application layer. Padding for encrypted Handshake or Alert records must still be handled at the TLS layer, though. Later documents may define padding selection algorithms or define a padding policy request mechanism through TLS extensions or some other means.
パディングする時期と量を提案するパディングポリシーを選択することは複雑なトピックであり、この仕様の範囲外です。 TLS上のアプリケーション層プロトコルに独自のパディングがある場合、アプリケーション層内のアプリケーションデータTLSレコードをパディングすることが望ましい場合があります。 ただし、暗号化されたハンドシェイクまたはアラートレコードのパディングは、TLSレイヤーで処理する必要があります。 後の文書では、パディング選択アルゴリズムを定義するか、TLS拡張機能またはその他の手段を介してパディングポリシー要求メカニズムを定義します。
There are cryptographic limits on the amount of plaintext which can be safely encrypted under a given set of keys. [AEAD-LIMITS] provides an analysis of these limits under the assumption that the underlying primitive (AES or ChaCha20) has no weaknesses. Implementations SHOULD do a key update as described in Section 4.6.3 prior to reaching these limits.
特定のキーセットで安全に暗号化できるプレーンテキストの量には暗号化の制限があります。 [AEAD-LIMITS]は、基礎となるプリミティブ（AESまたはChaCha20）に弱点がないという仮定の下で、これらの制限の分析を提供します。 実装は、これらの制限に達する前に、セクション4.6.3で説明されているように、主要な更新を行う必要があります。
For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encrypted on a given connection while keeping a safety margin of approximately 2^-57 for Authenticated Encryption (AE) security. For ChaCha20/Poly1305, the record sequence number would wrap before the safety limit is reached.
AES-GCMの場合、認証済み暗号化（AE）セキュリティのために約2 ^ -57の安全マージンを維持しながら、最大2 ^ 24.5のフルサイズレコード（約2,400万）を特定の接続で暗号化できます。 ChaCha20 / Poly1305の場合、安全制限に達する前にレコードシーケンス番号がラップします。
TLS provides an Alert content type to indicate closure information and errors. Like other messages, alert messages are encrypted as specified by the current connection state.
TLSは、閉鎖情報とエラーを示すAlertコンテンツタイプを提供します。 他のメッセージと同様に、アラートメッセージは現在の接続状態の指定に従って暗号化されます。
Alert messages convey a description of the alert and a legacy field that conveyed the severity level of the message in previous versions of TLS. Alerts are divided into two classes: closure alerts and error alerts. In TLS 1.3, the severity is implicit in the type of alert being sent, and the "level" field can safely be ignored. The "close_notify" alert is used to indicate orderly closure of one direction of the connection. Upon receiving such an alert, the TLS implementation SHOULD indicate end-of-data to the application.
アラートメッセージは、アラートの説明と、以前のバージョンのTLSのメッセージの重大度レベルを伝達したレガシーフィールドを伝達します。 アラートは、閉鎖アラートとエラーアラートの2つのクラスに分類されます。 TLS 1.3では、送信されるアラートのタイプに重大度が暗黙的に含まれており、「レベル」フィールドは無視しても問題ありません。 「close_notify」アラートは、接続の一方向の秩序ある閉鎖を示すために使用されます。 そのようなアラートを受信すると、TLS実装はデータの終わりをアプリケーションに示す必要があります。
Error alerts indicate abortive closure of the connection (see Section 6.2). Upon receiving an error alert, the TLS implementation SHOULD indicate an error to the application and MUST NOT allow any further data to be sent or received on the connection. Servers and clients MUST forget the secret values and keys established in failed connections, with the exception of the PSKs associated with session tickets, which SHOULD be discarded if possible.
エラーアラートは、接続の強制終了を示します（セクション6.2を参照）。 エラーアラートを受信すると、TLS実装はアプリケーションにエラーを通知する必要があり（SHOULD）、接続上でデータの送受信を許可してはなりません（MUST NOT）。 サーバーとクライアントは、セッションチケットに関連付けられているPSKを除き、失敗した接続で確立された秘密の値とキーを忘れなければなりません。
All the alerts listed in Section 6.2 MUST be sent with AlertLevel=fatal and MUST be treated as error alerts when received regardless of the AlertLevel in the message. Unknown Alert types MUST be treated as error alerts.
セクション6.2にリストされているすべてのアラートは、AlertLevel = fatalで送信する必要があり、メッセージ内のAlertLevelに関係なく受信した場合、エラーアラートとして扱わなければなりません。 不明なアラートタイプはエラーアラートとして扱わなければなりません。
Note: TLS defines two generic alerts (see Section 6) to use upon failure to parse a message. Peers which receive a message which cannot be parsed according to the syntax (e.g., have a length extending beyond the message boundary or contain an out-of-range length) MUST terminate the connection with a "decode_error" alert. Peers which receive a message which is syntactically correct but semantically invalid (e.g., a DHE share of p - 1, or an invalid enum) MUST terminate the connection with an "illegal_parameter" alert.
注：TLSは、メッセージの解析に失敗したときに使用する2つの汎用アラート（セクション6を参照）を定義します。 構文に従って解析できないメッセージを受信するピア（たとえば、メッセージの境界を超える長さまたは範囲外の長さを含む）は、「decode_error」アラートで接続を終了する必要があります。 構文的には正しいが意味的に無効なメッセージ（たとえば、p-1のDHE共有、または無効な列挙）を受信するピアは、「illegal_parameter」アラートで接続を終了しなければなりません。
enum { warning(1), fatal(2), (255) } AlertLevel;
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
record_overflow(22),
handshake_failure(40),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
protocol_version(70),
insufficient_security(71),
internal_error(80),
inappropriate_fallback(86),
user_canceled(90),
missing_extension(109),
unsupported_extension(110),
unrecognized_name(112),
bad_certificate_status_response(113),
unknown_psk_identity(115),
certificate_required(116),
no_application_protocol(120),
(255)
} AlertDescription;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
The client and the server must share knowledge that the connection is ending in order to avoid a truncation attack.
クライアントとサーバーは、切断攻撃を回避するために、接続が終了するという知識を共有する必要があります。
close_notify: This alert notifies the recipient that the sender will not send any more messages on this connection. Any data received after a closure alert has been received MUST be ignored.
close_notify：このアラートは、送信者がこの接続でこれ以上メッセージを送信しないことを受信者に通知します。 閉鎖アラートを受信した後に受信したデータは無視する必要があります。
user_canceled: This alert notifies the recipient that the sender is canceling the handshake for some reason unrelated to a protocol failure. If a user cancels an operation after the handshake is complete, just closing the connection by sending a "close_notify" is more appropriate. This alert SHOULD be followed by a "close_notify". This alert generally has AlertLevel=warning.
user_canceled：このアラートは、送信者がプロトコル障害とは無関係の何らかの理由でハンドシェイクをキャンセルしていることを受信者に通知します。 ハンドシェイクの完了後にユーザーが操作をキャンセルした場合、「close_notify」を送信して接続を閉じるだけの方が適切です。 このアラートには、「close_notify」が続く必要があります。 通常、このアラートにはAlertLevel = warningがあります。
Either party MAY initiate a close of its write side of the connection by sending a "close_notify" alert. Any data received after a closure alert has been received MUST be ignored. If a transport-level close is received prior to a "close_notify", the receiver cannot know that all the data that was sent has been received.
どちらの当事者も、「close_notify」アラートを送信することにより、接続の書き込み側の終了を開始できます。 閉鎖アラートを受信した後に受信したデータは無視する必要があります。 「close_notify」の前にトランスポートレベルのクローズが受信された場合、受信者は送信されたすべてのデータが受信されたことを知ることができません。
Each party MUST send a "close_notify" alert before closing its write side of the connection, unless it has already sent some error alert. This does not have any effect on its read side of the connection. Note that this is a change from versions of TLS prior to TLS 1.3 in which implementations were required to react to a "close_notify" by discarding pending writes and sending an immediate "close_notify" alert of their own. That previous requirement could cause truncation in the read side. Both parties need not wait to receive a "close_notify" alert before closing their read side of the connection, though doing so would introduce the possibility of truncation.
エラーアラートを既に送信していない限り、各パーティは接続の書き込み側を閉じる前に「close_notify」アラートを送信する必要があります。 これは、接続の読み取り側には影響しません。 これは、保留中の書き込みを破棄し、独自の即時の「close_notify」アラートを送信することにより、実装が「close_notify」に対応する必要があるTLS 1.3より前のTLSのバージョンからの変更であることに注意してください。 その以前の要件は、読み取り側で切り捨てを引き起こす可能性がありました。 両者は、接続の読み取り側を閉じる前に「close_notify」アラートを受信するのを待つ必要はありませんが、そうすると切り捨ての可能性が生じます。
If the application protocol using TLS provides that any data may be carried over the underlying transport after the TLS connection is closed, the TLS implementation MUST receive a "close_notify" alert before indicating end-of-data to the application layer. No part of this standard should be taken to dictate the manner in which a usage profile for TLS manages its data transport, including when connections are opened or closed.
TLS接続が閉じられた後、TLSを使用するアプリケーションプロトコルが基礎となるトランスポートを介してデータを運ぶことができる場合、TLS実装はアプリケーション層にデータの終わりを示す前に「close_notify」アラートを受信する必要があります。 接続のオープン時やクローズ時など、TLSの使用プロファイルがデータ転送を管理する方法を規定するために、この規格の一部をとるべきではありません。
Note: It is assumed that closing the write side of a connection reliably delivers pending data before destroying the transport.
注：接続の書き込み側を閉じると、トランスポートを破棄する前に保留中のデータが確実に配信されると想定されています。
Error handling in TLS is very simple. When an error is detected, the detecting party sends a message to its peer. Upon transmission or receipt of a fatal alert message, both parties MUST immediately close the connection.
TLSでのエラー処理は非常に簡単です。 エラーが検出されると、検出側はピアにメッセージを送信します。 致命的な警告メッセージを送信または受信すると、両方の当事者はすぐに接続を閉じなければなりません。
Whenever an implementation encounters a fatal error condition, it SHOULD send an appropriate fatal alert and MUST close the connection without sending or receiving any additional data. In the rest of this specification, when the phrases "terminate the connection" and "abort the handshake" are used without a specific alert it means that the implementation SHOULD send the alert indicated by the descriptions below. The phrases "terminate the connection with an X alert" and "abort the handshake with an X alert" mean that the implementation MUST send alert X if it sends any alert. All alerts defined below in this section, as well as all unknown alerts, are universally considered fatal as of TLS 1.3 (see Section 6). The implementation SHOULD provide a way to facilitate logging the sending and receiving of alerts.
実装が致命的なエラー状態に遭遇するたびに、適切な致命的なアラートを送信する必要があり（SHOULD）、追加のデータを送受信しないで接続を閉じなければなりません。 この仕様の残りの部分で、「接続を終了する」および「ハンドシェイクを中止する」というフレーズが特定のアラートなしで使用される場合、実装は以下の説明で示されるアラートを送信する必要があります。 「Xアラートで接続を終了する」および「Xアラートでハンドシェイクを中止する」というフレーズは、実装がアラートを送信する場合、アラートXを送信する必要があることを意味します。 このセクションで以下で定義されるすべてのアラート、およびすべての未知のアラートは、TLS 1.3の時点で一般的に致命的と見なされます（セクション6を参照）。 実装は、アラートの送信と受信のログ記録を容易にする方法を提供する必要があります。
The following error alerts are defined:
次のエラーアラートが定義されています。
unexpected_message: An inappropriate message (e.g., the wrong handshake message, premature Application Data, etc.) was received. This alert should never be observed in communication between proper implementations.
unexpected_message：不適切なメッセージ（間違ったハンドシェイクメッセージ、時期尚早なアプリケーションデータなど）を受信しました。 このアラートは、適切な実装間の通信では決して観察されるべきではありません。
bad_record_mac: This alert is returned if a record is received which cannot be deprotected. Because AEAD algorithms combine decryption and verification, and also to avoid side-channel attacks, this alert is used for all deprotection failures. This alert should never be observed in communication between proper implementations, except when messages were corrupted in the network.
bad_record_mac：このアラートは、保護を解除できないレコードを受信した場合に返されます。 AEADアルゴリズムは復号化と検証を組み合わせており、サイドチャネル攻撃を回避するため、このアラートはすべての保護解除エラーに使用されます。 このアラートは、ネットワーク内でメッセージが破損した場合を除き、適切な実装間の通信では決して観察されるべきではありません。
record_overflow: A TLSCiphertext record was received that had a length more than 2^14 + 256 bytes, or a record decrypted to a TLSPlaintext record with more than 2^14 bytes (or some other negotiated limit). This alert should never be observed in communication between proper implementations, except when messages were corrupted in the network.
record_overflow：長さが2 ^ 14 + 256バイトを超えるTLSCiphertextレコード、または2 ^ 14バイトを超えるTLSPlaintextレコードに暗号化解除されたレコード（またはその他のネゴシエートされた制限）が受信されました。 このアラートは、ネットワーク内でメッセージが破損した場合を除き、適切な実装間の通信では決して観察されるべきではありません。
handshake_failure: Receipt of a "handshake_failure" alert message indicates that the sender was unable to negotiate an acceptable set of security parameters given the options available.
handshake_failure： "handshake_failure"アラートメッセージの受信は、送信者が利用可能なオプションが与えられたセキュリティパラメーターの許容セットをネゴシエートできなかったことを示します。
bad_certificate: A certificate was corrupt, contained signatures that did not verify correctly, etc.
bad_certificate：証明書が破損しているか、正しく検証されていない署名が含まれているなど。
unsupported_certificate: A certificate was of an unsupported type.
unsupported_certificate：証明書はサポートされていないタイプでした。
certificate_revoked: A certificate was revoked by its signer.
certificate_revoked：署名者によって証明書が取り消されました。
certificate_expired: A certificate has expired or is not currently valid.
certificate_expired：証明書の有効期限が切れているか、現在有効ではありません。
certificate_unknown: Some other (unspecified) issue arose in processing the certificate, rendering it unacceptable.
certificate_unknown：証明書の処理中に他の（不特定の）問題が発生し、受け入れられなくなりました。
illegal_parameter: A field in the handshake was incorrect or inconsistent with other fields. This alert is used for errors which conform to the formal protocol syntax but are otherwise incorrect.
illegal_parameter：ハンドシェイクのフィールドが正しくないか、他のフィールドと矛盾しています。 このアラートは、正式なプロトコル構文に準拠しているが、それ以外は誤りであるエラーに使用されます。
unknown_ca: A valid certificate chain or partial chain was received, but the certificate was not accepted because the CA certificate could not be located or could not be matched with a known trust anchor.
unknown_ca：有効な証明書チェーンまたは部分チェーンが受信されましたが、CA証明書が見つからないか、既知のトラストアンカーと一致しないため、証明書は受け入れられませんでした。
access_denied: A valid certificate or PSK was received, but when access control was applied, the sender decided not to proceed with negotiation.
access_denied：有効な証明書またはPSKを受信しましたが、アクセス制御が適用されたときに、送信者はネゴシエーションを続行しないことを決定しました。
decode_error: A message could not be decoded because some field was out of the specified range or the length of the message was incorrect. This alert is used for errors where the message does not conform to the formal protocol syntax. This alert should never be observed in communication between proper implementations, except when messages were corrupted in the network.
decode_error：一部のフィールドが指定された範囲外であるか、メッセージの長さが間違っていたため、メッセージをデコードできませんでした。 このアラートは、メッセージが正式なプロトコル構文に準拠していないエラーに使用されます。 このアラートは、ネットワーク内でメッセージが破損した場合を除き、適切な実装間の通信では決して観察されるべきではありません。
decrypt_error: A handshake (not record layer) cryptographic operation failed, including being unable to correctly verify a signature or validate a Finished message or a PSK binder.
decrypt_error：ハンドシェイク（レコード層ではない）暗号化操作が失敗しました。これには、署名を正しく検証できないか、FinishedメッセージまたはPSKバインダーを検証できないことが含まれます。
protocol_version: The protocol version the peer has attempted to negotiate is recognized but not supported (see Appendix D).
protocol_version：ピアがネゴシエートしようとしたプロトコルバージョンは認識されますが、サポートされていません（付録Dを参照）。
insufficient_security: Returned instead of "handshake_failure" when a negotiation has failed specifically because the server requires parameters more secure than those supported by the client.
不十分なセキュリティ：サーバーがクライアントでサポートされているパラメータよりも安全なパラメータを必要とするため、ネゴシエーションが失敗した場合に「handshake_failure」の代わりに返されます。
internal_error: An internal error unrelated to the peer or the correctness of the protocol (such as a memory allocation failure) makes it impossible to continue.
internal_error：ピアまたはプロトコルの正確性とは関係のない内部エラー（メモリ割り当ての失敗など）により、続行できなくなります。
inappropriate_fallback: Sent by a server in response to an invalid connection retry attempt from a client (see [RFC7507]).
不適切なフォールバック：クライアントからの無効な接続再試行に応答してサーバーによって送信されます（[RFC7507]を参照）。
missing_extension: Sent by endpoints that receive a handshake message not containing an extension that is mandatory to send for the offered TLS version or other negotiated parameters.
missing_extension：提供されたTLSバージョンまたはその他のネゴシエートされたパラメータの送信に必須である拡張機能を含まないハンドシェイクメッセージを受信するエンドポイントによって送信されます。
unsupported_extension: Sent by endpoints receiving any handshake message containing an extension known to be prohibited for inclusion in the given handshake message, or including any extensions in a ServerHello or Certificate not first offered in the corresponding ClientHello or CertificateRequest.
unsupported_extension：指定されたハンドシェイクメッセージに含めることが禁止されている拡張機能を含む、または対応するClientHelloまたはCertificateRequestで最初に提供されないServerHelloまたはCertificateの拡張機能を含むハンドシェイクメッセージを受信するエンドポイントによって送信されます。
unrecognized_name: Sent by servers when no server exists identified by the name provided by the client via the "server_name" extension (see [RFC6066]).
unrecognized_name：「server_name」拡張子を介してクライアントから提供された名前で識別されるサーバーが存在しない場合にサーバーによって送信されます（[RFC6066]を参照）。
bad_certificate_status_response: Sent by clients when an invalid or unacceptable OCSP response is provided by the server via the "status_request" extension (see [RFC6066]).
bad_certificate_status_response：無効または受け入れられないOCSP応答が「status_request」拡張機能を介してサーバーから提供されたときにクライアントによって送信されます（[RFC6066]を参照）。
unknown_psk_identity: Sent by servers when PSK key establishment is desired but no acceptable PSK identity is provided by the client. Sending this alert is OPTIONAL; servers MAY instead choose to send a "decrypt_error" alert to merely indicate an invalid PSK identity.
unknown_psk_identity：PSKキーの確立が必要であるが、クライアントによって受け入れ可能なPSK IDが提供されない場合にサーバーによって送信されます。 このアラートの送信はオプションです。 サーバーは、代わりに「decrypt_error」アラートを送信して、単に無効なPSK IDを示すことを選択できます。
certificate_required: Sent by servers when a client certificate is desired but none was provided by the client.
certificate_required：クライアント証明書が必要であるが、クライアントから何も提供されなかったときにサーバーによって送信されます。
no_application_protocol: Sent by servers when a client "application_layer_protocol_negotiation" extension advertises only protocols that the server does not support (see [RFC7301]).
no_application_protocol：クライアントの「application_layer_protocol_negotiation」拡張機能が、サーバーがサポートしていないプロトコルのみをアドバタイズするときにサーバーによって送信されます（[RFC7301]を参照）。
New Alert values are assigned by IANA as described in Section 11.
セクション11で説明されているように、新しいアラート値はIANAによって割り当てられます。
The TLS handshake establishes one or more input secrets which are combined to create the actual working keying material, as detailed below. The key derivation process incorporates both the input secrets and the handshake transcript. Note that because the handshake transcript includes the random values from the Hello messages, any given handshake will have different traffic secrets, even if the same input secrets are used, as is the case when the same PSK is used for multiple connections.
TLSハンドシェイクは、1つ以上の入力シークレットを確立します。これらのシークレットを組み合わせて、実際の作業キーイングマテリアルを作成します。これについては、以下で詳しく説明します。 キー派生プロセスには、入力シークレットとハンドシェイクのトランスクリプトの両方が組み込まれています。 ハンドシェイクのトランスクリプトにはHelloメッセージからのランダムな値が含まれているため、同じPSKが複数の接続に使用される場合のように、同じ入力シークレットが使用されていても、特定のハンドシェイクには異なるトラフィックシークレットがあります。
The key derivation process makes use of the HKDF-Extract and HKDF-Expand functions as defined for HKDF [RFC5869], as well as the functions defined below:
鍵導出プロセスでは、HKDF [RFC5869]で定義されているHKDF-ExtractおよびHKDF-Expand関数、および以下で定義されている関数を使用します。
HKDF-Expand-Label(Secret, Label, Context, Length) =
HKDF-Expand(Secret, HkdfLabel, Length)
Where HkdfLabel is specified as:
HkdfLabelは次のように指定されます。
struct {
uint16 length = Length;
opaque label<7..255> = "tls13 " + Label;
opaque context<0..255> = Context;
} HkdfLabel;
Derive-Secret(Secret, Label, Messages) =
HKDF-Expand-Label(Secret, Label,
Transcript-Hash(Messages), Hash.length)
The Hash function used by Transcript-Hash and HKDF is the cipher suite hash algorithm. Hash.length is its output length in bytes. Messages is the concatenation of the indicated handshake messages, including the handshake message type and length fields, but not including record layer headers. Note that in some cases a zero-length Context (indicated by "") is passed to HKDF-Expand-Label. The labels specified in this document are all ASCII strings and do not include a trailing NUL byte.
Transcript-HashおよびHKDFで使用されるハッシュ関数は、暗号スイートハッシュアルゴリズムです。 Hash.lengthは、バイト単位の出力長です。 メッセージは、示されたハンドシェイクメッセージの連結であり、ハンドシェイクメッセージタイプと長さフィールドを含みますが、レコードレイヤヘッダーは含まれません。 場合によっては、ゼロ長のコンテキスト（ ""で示される）がHKDF-Expand-Labelに渡されることに注意してください。 このドキュメントで指定されているラベルはすべてASCII文字列であり、末尾のNULバイトは含まれていません。
Note: With common hash functions, any label longer than 12 characters requires an additional iteration of the hash function to compute. The labels in this specification have all been chosen to fit within this limit.
注：一般的なハッシュ関数では、12文字を超えるラベルを計算するには、ハッシュ関数の追加の反復が必要です。 この仕様のラベルはすべて、この制限内に収まるように選択されています。
Keys are derived from two input secrets using the HKDF-Extract and Derive-Secret functions. The general pattern for adding a new secret is to use HKDF-Extract with the Salt being the current secret state and the Input Keying Material (IKM) being the new secret to be added. In this version of TLS 1.3, the two input secrets are:
鍵は、HKDF-ExtractおよびDerive-Secret関数を使用して2つの入力シークレットから派生します。 新しいシークレットを追加する一般的なパターンは、HKDF-Extractを使用することです。ソルトは現在のシークレット状態で、入力キーイングマテリアル（IKM）は追加する新しいシークレットです。 このバージョンのTLS 1.3では、2つの入力シークレットは次のとおりです。
- PSK (a pre-shared key established externally or derived from the resumption_master_secret value from a previous connection)
- PSK（外部で確立された、または以前の接続のresumption_master_secret値から派生した事前共有キー）
- (EC)DHE shared secret (Section 7.4)
-（EC）DHE共有シークレット（セクション7.4）
This produces a full key derivation schedule shown in the diagram below. In this diagram, the following formatting conventions apply:
これにより、次の図に示す完全なキー導出スケジュールが作成されます。 この図では、次のフォーマット規則が適用されます。
- HKDF-Extract is drawn as taking the Salt argument from the top and the IKM argument from the left, with its output to the bottom and the name of the output on the right.
- HKDF-Extractは、上部からSalt引数を、左側からIKM引数を取り、その出力を下部に、出力の名前を右側に取るように描画されます。
- Derive-Secret's Secret argument is indicated by the incoming arrow. For instance, the Early Secret is the Secret for generating the client_early_traffic_secret.
- Derive-SecretのSecret引数は、入ってくる矢印で示されます。 たとえば、アーリーシークレットはclient_early_traffic_secretを生成するためのシークレットです。
- "0" indicates a string of Hash.length bytes set to zero.
-「0」は、ゼロに設定されたHash.lengthバイトの文字列を示します。
0
|
v
PSK -> HKDF-Extract = Early Secret
|
+-----> Derive-Secret(., "ext binder" | "res binder", "")
| = binder_key
|
+-----> Derive-Secret(., "c e traffic", ClientHello)
| = client_early_traffic_secret
|
+-----> Derive-Secret(., "e exp master", ClientHello)
| = early_exporter_master_secret
v
Derive-Secret(., "derived", "")
|
v
(EC)DHE -> HKDF-Extract = Handshake Secret
|
+-----> Derive-Secret(., "c hs traffic",
| ClientHello...ServerHello)
| = client_handshake_traffic_secret
|
+-----> Derive-Secret(., "s hs traffic",
| ClientHello...ServerHello)
| = server_handshake_traffic_secret
v
Derive-Secret(., "derived", "")
|
v
0 -> HKDF-Extract = Master Secret
|
+-----> Derive-Secret(., "c ap traffic",
| ClientHello...server Finished)
| = client_application_traffic_secret_0
|
+-----> Derive-Secret(., "s ap traffic",
| ClientHello...server Finished)
| = server_application_traffic_secret_0
|
+-----> Derive-Secret(., "exp master",
| ClientHello...server Finished)
| = exporter_master_secret
|
+-----> Derive-Secret(., "res master",
ClientHello...client Finished)
= resumption_master_secret
The general pattern here is that the secrets shown down the left side of the diagram are just raw entropy without context, whereas the secrets down the right side include Handshake Context and therefore can be used to derive working keys without additional context. Note that the different calls to Derive-Secret may take different Messages arguments, even with the same secret. In a 0-RTT exchange, Derive-Secret is called with four distinct transcripts; in a 1-RTT-only exchange, it is called with three distinct transcripts.
ここでの一般的なパターンは、図の左側に表示されるシークレットはコンテキストのない生エントロピーであり、右側のシークレットにはハンドシェイクコンテキストが含まれるため、追加のコンテキストなしで作業キーを導出するために使用できるということです。 Derive-Secretの異なる呼び出しは、同じ秘密であっても異なるメッセージ引数を取る場合があることに注意してください。 0-RTT交換では、Derive-Secretが4つの異なるトランスクリプトで呼び出されます。 1-RTTのみの交換では、3つの異なるトランスクリプトで呼び出されます。
If a given secret is not available, then the 0-value consisting of a string of Hash.length bytes set to zeros is used. Note that this does not mean skipping rounds, so if PSK is not in use, Early Secret will still be HKDF-Extract(0, 0). For the computation of the binder_key, the label is "ext binder" for external PSKs (those provisioned outside of TLS) and "res binder" for resumption PSKs (those provisioned as the resumption master secret of a previous handshake). The different labels prevent the substitution of one type of PSK for the other.
指定されたシークレットが利用できない場合、ゼロに設定されたHash.lengthバイトの文字列で構成される0値が使用されます。 これはラウンドをスキップすることを意味しないことに注意してください。したがって、PSKが使用されていない場合でも、アーリーシークレットはHKDF-Extract（0、0）のままです。 バインダキーの計算では、ラベルは外部PSK（TLSの外部でプロビジョニングされたもの）の「extバインダ」および再開PSK（以前のハンドシェイクの再開マスターシークレットとしてプロビジョニングされたもの）の「resバインダ」です。 ラベルが異なると、あるタイプのPSKが別のタイプのPSKに置き換えられなくなります。
There are multiple potential Early Secret values, depending on which PSK the server ultimately selects. The client will need to compute one for each potential PSK; if no PSK is selected, it will then need to compute the Early Secret corresponding to the zero PSK.
サーバーが最終的に選択するPSKに応じて、複数の潜在的なアーリーシークレット値があります。 クライアントは、潜在的なPSKごとに1つを計算する必要があります。 PSKが選択されていない場合、ゼロPSKに対応するアーリーシークレットを計算する必要があります。
Once all the values which are to be derived from a given secret have been computed, that secret SHOULD be erased.
特定のシークレットから導出される値がすべて計算されたら、そのシークレットを消去する必要があります。
Once the handshake is complete, it is possible for either side to update its sending traffic keys using the KeyUpdate handshake message defined in Section 4.6.3. The next generation of traffic keys is computed by generating client_/server_application_traffic_secret_N+1 from client_/server_application_traffic_secret_N as described in this section and then re-deriving the traffic keys as described in Section 7.3.
ハンドシェイクが完了すると、セクション4.6.3で定義されているKeyUpdateハンドシェイクメッセージを使用して、どちらの側でも送信トラフィックキーを更新できます。 次世代のトラフィックキーは、このセクションで説明されているようにclient_ / server_application_traffic_secret_Nからclient_ / server_application_traffic_secret_N + 1を生成し、セクション7.3で説明されているようにトラフィックキーを再導出することによって計算されます。
The next-generation application_traffic_secret is computed as:
次世代のapplication_traffic_secretは次のように計算されます：
application_traffic_secret_N+1 =
HKDF-Expand-Label(application_traffic_secret_N,
"traffic upd", "", Hash.length)
Once client_/server_application_traffic_secret_N+1 and its associated traffic keys have been computed, implementations SHOULD delete client_/server_application_traffic_secret_N and its associated traffic keys.
client_ / server_application_traffic_secret_N + 1とその関連トラフィックキーが計算されると、実装はclient_ / server_application_traffic_secret_Nとその関連トラフィックキーを削除する必要があります。
The traffic keying material is generated from the following input values:
トラフィックキーイングマテリアルは、次の入力値から生成されます。
- A secret value
- 秘密の値
- A purpose value indicating the specific value being generated
- 生成される特定の値を示す目的値
- The length of the key being generated
- 生成されるキーの長さ
The traffic keying material is generated from an input traffic secret value using:
トラフィックキーイングマテリアルは、次を使用して入力トラフィックシークレット値から生成されます。
[sender]_write_key = HKDF-Expand-Label(Secret, "key", "", key_length)
[sender]_write_iv = HKDF-Expand-Label(Secret, "iv", "", iv_length)
[sender] denotes the sending side. The value of Secret for each record type is shown in the table below.
[送信者]は送信側を示します。 各レコードタイプのSecretの値を次の表に示します。
+-------------------+---------------------------------------+
| Record Type | Secret |
+-------------------+---------------------------------------+
| 0-RTT Application | client_early_traffic_secret |
| | |
| Handshake | [sender]_handshake_traffic_secret |
| | |
| Application Data | [sender]_application_traffic_secret_N |
+-------------------+---------------------------------------+
All the traffic keying material is recomputed whenever the underlying Secret changes (e.g., when changing from the handshake to Application Data keys or upon a key update).
基礎となるシークレットが変更されるたびに（たとえば、ハンドシェイクからアプリケーションデータキーへの変更時、またはキーの更新時に）、すべてのトラフィックキーイングマテリアルが再計算されます。
For finite field groups, a conventional Diffie-Hellman [DH76] computation is performed. The negotiated key (Z) is converted to a byte string by encoding in big-endian form and left-padded with zeros up to the size of the prime. This byte string is used as the shared secret in the key schedule as specified above.
有限フィールドグループの場合、従来のDiffie-Hellman [DH76]計算が実行されます。 ネゴシエートされたキー（Z）は、ビッグエンディアン形式でエンコードすることによりバイト文字列に変換され、プライムのサイズまでゼロが左詰めされます。 このバイト文字列は、上記で指定されたキースケジュールで共有シークレットとして使用されます。
Note that this construction differs from previous versions of TLS which removed leading zeros.
この構造は、先行ゼロを削除した以前のバージョンのTLSとは異なることに注意してください。
For secp256r1, secp384r1, and secp521r1, ECDH calculations (including parameter and key generation as well as the shared secret calculation) are performed according to [IEEE1363] using the ECKAS-DH1 scheme with the identity map as the key derivation function (KDF), so that the shared secret is the x-coordinate of the ECDH shared secret elliptic curve point represented as an octet string. Note that this octet string ("Z" in IEEE 1363 terminology) as output by FE2OSP (the Field Element to Octet String Conversion Primitive) has constant length for any given field; leading zeros found in this octet string MUST NOT be truncated.
secp256r1、secp384r1、およびsecp521r1の場合、ECDH計算（パラメーターとキーの生成、および共有秘密計算を含む）は、キー派生関数（KDF）としてIDマップを使用したECKAS-DH1スキームを使用して、[IEEE1363]に従って実行されます。 共有秘密は、オクテット文字列として表されるECDH共有秘密楕円曲線点のx座標です。 FE2OSP（フィールド要素からオクテット文字列への変換プリミティブ）による出力としてのこのオクテット文字列（IEEE 1363用語では「Z」）には、任意のフィールドの長さが一定であることに注意してください。 このオクテット文字列で見つかった先行ゼロは切り捨ててはいけません。
(Note that this use of the identity KDF is a technicality. The complete picture is that ECDH is employed with a non-trivial KDF because TLS does not directly use this secret for anything other than for computing other secrets.)
（ID KDFのこの使用は技術的であることに注意してください。TLSは他のシークレットの計算以外にこのシークレットを直接使用しないため、ECDHは重要なKDFで使用されます。）
For X25519 and X448, the ECDH calculations are as follows:
X25519およびX448の場合、ECDH計算は次のとおりです。
- The public key to put into the KeyShareEntry.key_exchange structure is the result of applying the ECDH scalar multiplication function to the secret key of appropriate length (into scalar input) and the standard public basepoint (into u-coordinate point input).
- KeyShareEntry.key_exchange構造体に配置する公開キーは、ECDHスカラー乗算関数を適切な長さの秘密キー（スカラー入力へ）および標準公開ベースポイント（u座標ポイント入力へ）に適用した結果です。
- The ECDH shared secret is the result of applying the ECDH scalar multiplication function to the secret key (into scalar input) and the peer's public key (into u-coordinate point input). The output is used raw, with no processing.
- ECDH共有秘密は、ECDHスカラー乗算関数を秘密キー（スカラー入力へ）およびピアの公開キー（u座標点入力へ）に適用した結果です。 出力は処理せずにそのまま使用されます。
For these curves, implementations SHOULD use the approach specified in [RFC7748] to calculate the Diffie-Hellman shared secret. Implementations MUST check whether the computed Diffie-Hellman shared secret is the all-zero value and abort if so, as described in Section 6 of [RFC7748]. If implementors use an alternative implementation of these elliptic curves, they SHOULD perform the additional checks specified in Section 7 of [RFC7748].
これらの曲線について、実装は[RFC7748]で指定されたアプローチを使用して、Diffie-Hellman共有シークレットを計算する必要があります。 実装は、[RFC7748]のセクション6で説明されているように、計算されたDiffie-Hellman共有シークレットがすべてゼロの値であるかどうかを確認し、そうであれば中止する必要があります。 実装者がこれらの楕円曲線の代替実装を使用する場合、[RFC7748]のセクション7で指定された追加チェックを実行する必要があります。
[RFC5705] defines keying material exporters for TLS in terms of the TLS pseudorandom function (PRF). This document replaces the PRF with HKDF, thus requiring a new construction. The exporter interface remains the same.
[RFC5705]は、TLS擬似ランダム関数（PRF）の観点からTLSのキーイングマテリアルエクスポータを定義しています。 このドキュメントでは、PRFをHKDFに置き換えているため、新しい構造が必要です。 エクスポーターのインターフェースは同じままです。
The exporter value is computed as:
エクスポーター値は次のように計算されます。
TLS-Exporter(label, context_value, key_length) =
HKDF-Expand-Label(Derive-Secret(Secret, label, ""),
"exporter", Hash(context_value), key_length)
Where Secret is either the early_exporter_master_secret or the exporter_master_secret. Implementations MUST use the exporter_master_secret unless explicitly specified by the application. The early_exporter_master_secret is defined for use in settings where an exporter is needed for 0-RTT data. A separate interface for the early exporter is RECOMMENDED; this avoids the exporter user accidentally using an early exporter when a regular one is desired or vice versa.
Secretは、early_exporter_master_secretまたはexporter_master_secretのいずれかです。 実装は、アプリケーションによって明示的に指定されない限り、exporter_master_secretを使用する必要があります。 early_exporter_master_secretは、0-RTTデータにエクスポーターが必要な設定で使用するために定義されます。 初期エクスポーター用の別のインターフェイスが推奨されます。 これにより、通常のエクスポーターが必要なときにエクスポーターユーザーが誤ってアーリーエクスポーターを使用することを回避できます。
If no context is provided, the context_value is zero length. Consequently, providing no context computes the same value as providing an empty context. This is a change from previous versions of TLS where an empty context produced a different output than an absent context. As of this document's publication, no allocated exporter label is used both with and without a context. Future specifications MUST NOT define a use of exporters that permit both an empty context and no context with the same label. New uses of exporters SHOULD provide a context in all exporter computations, though the value could be empty.
コンテキストが提供されない場合、context_valueの長さはゼロになります。 したがって、コンテキストを提供しない場合、空のコンテキストを提供する場合と同じ値が計算されます。 これは、空のコンテキストが存在しないコンテキストとは異なる出力を生成するTLSの以前のバージョンからの変更です。 このドキュメントの公開時点では、コンテキストの有無にかかわらず、割り当てられたエクスポーターラベルは使用されていません。 将来の仕様では、空のコンテキストと同じラベルを持つコンテキストを許可しないエクスポーターの使用を定義してはなりません。 エクスポーターの新しい使用方法は、値が空であっても、すべてのエクスポーターの計算にコンテキストを提供する必要があります。
Requirements for the format of exporter labels are defined in Section 4 of [RFC5705].
エクスポーターラベルの形式の要件は、[RFC5705]のセクション4で定義されています。
As noted in Section 2.3 and Appendix E.5, TLS does not provide inherent replay protections for 0-RTT data. There are two potential threats to be concerned with:
セクション2.3および付録E.5で述べたように、TLSは0-RTTデータに固有のリプレイ保護を提供しません。 懸念される可能性のある脅威は2つあります。
- Network attackers who mount a replay attack by simply duplicating a flight of 0-RTT data.
- 一連の0-RTTデータを複製するだけでリプレイ攻撃を仕掛けるネットワーク攻撃者。
- Network attackers who take advantage of client retry behavior to arrange for the server to receive multiple copies of an application message. This threat already exists to some extent because clients that value robustness respond to network errors by attempting to retry requests. However, 0-RTT adds an additional dimension for any server system which does not maintain globally consistent server state. Specifically, if a server system has multiple zones where tickets from zone A will not be accepted in zone B, then an attacker can duplicate a ClientHello and early data intended for A to both A and B. At A, the data will be accepted in 0-RTT, but at B the server will reject 0-RTT data and instead force a full handshake. If the attacker blocks the ServerHello from A, then the client will complete the handshake with B and probably retry the request, leading to duplication on the server system as a whole.
- クライアントの再試行動作を利用して、サーバーがアプリケーションメッセージの複数のコピーを受信するように調整するネットワーク攻撃者。 堅牢性を重視するクライアントは、要求を再試行することでネットワークエラーに応答するため、この脅威はすでにある程度存在しています。 ただし、0-RTTは、グローバルに一貫したサーバー状態を維持しないサーバーシステムに追加のディメンションを追加します。 具体的には、サーバーシステムに複数のゾーンがあり、ゾーンAからのチケットがゾーンBで受け入れられない場合、攻撃者はClientHelloとA向けの初期データをAとBの両方に複製できます。Aでは、データが受け入れられます 0-RTT。ただし、Bでは、サーバーは0-RTTデータを拒否し、代わりに完全なハンドシェイクを強制します。 攻撃者がAからServerHelloをブロックすると、クライアントはBとのハンドシェイクを完了し、おそらくリクエストを再試行し、サーバーシステム全体での複製につながります。
The first class of attack can be prevented by sharing state to guarantee that the 0-RTT data is accepted at most once. Servers SHOULD provide that level of replay safety by implementing one of the methods described in this section or by equivalent means. It is understood, however, that due to operational concerns not all deployments will maintain state at that level. Therefore, in normal operation, clients will not know which, if any, of these mechanisms servers actually implement and hence MUST only send early data which they deem safe to be replayed.
最初のクラスの攻撃は、状態を共有して0-RTTデータが最大1回しか受け入れられないようにすることで防止できます。 サーバーは、このセクションで説明する方法の1つまたは同等の手段を実装することにより、そのレベルのリプレイの安全性を提供する必要があります。 ただし、運用上の懸念により、すべての展開がそのレベルで状態を維持するとは限らないことが理解されます。 したがって、通常の運用では、クライアントはこれらのメカニズムのどれがサーバーに実際に実装されているかを知らないため、リプレイが安全であると思われる初期データのみを送信する必要があります。
In addition to the direct effects of replays, there is a class of attacks where even operations normally considered idempotent could be exploited by a large number of replays (timing attacks, resource limit exhaustion and others, as described in Appendix E.5). Those can be mitigated by ensuring that every 0-RTT payload can be replayed only a limited number of times. The server MUST ensure that any instance of it (be it a machine, a thread, or any other entity within the relevant serving infrastructure) would accept 0-RTT for the same 0-RTT handshake at most once; this limits the number of replays to the number of server instances in the deployment. Such a guarantee can be accomplished by locally recording data from recently received ClientHellos and rejecting repeats, or by any other method that provides the same or a stronger guarantee. The "at most once per server instance" guarantee is a minimum requirement; servers SHOULD limit 0-RTT replays further when feasible.
リプレイの直接的な効果に加えて、通常はべき等と見なされる操作でも多数のリプレイによって悪用される可能性のある攻撃のクラスがあります（付録E.5で説明するタイミング攻撃、リソース制限の枯渇など）。 これらは、すべての0-RTTペイロードを限られた回数だけ再生できるようにすることで軽減できます。 サーバーは、そのインスタンス（マシン、スレッド、または関連するサービングインフラストラクチャ内のその他のエンティティ）が、同じ0-RTTハンドシェイクに対して最大で一度だけ0-RTTを受け入れるようにする必要があります。 これにより、リプレイの数がデプロイメント内のサーバーインスタンスの数に制限されます。 このような保証は、最近受信したClientHelloからデータをローカルに記録して繰り返しを拒否するか、同じまたはより強力な保証を提供する他の方法によって実現できます。 「サーバーインスタンスごとに最大1回」の保証は最小要件です。 サーバーは、可能であれば0-RTTリプレイをさらに制限する必要があります。
The second class of attack cannot be prevented at the TLS layer and MUST be dealt with by any application. Note that any application whose clients implement any kind of retry behavior already needs to implement some sort of anti-replay defense.
2番目のクラスの攻撃はTLSレイヤーで防ぐことができず、どのアプリケーションでも対処する必要があります。 クライアントがあらゆる種類の再試行動作を実装しているアプリケーションは、すでに何らかのアンチリプレイ防御を実装する必要があることに注意してください。
The simplest form of anti-replay defense is for the server to only allow each session ticket to be used once. For instance, the server can maintain a database of all outstanding valid tickets, deleting each ticket from the database as it is used. If an unknown ticket is provided, the server would then fall back to a full handshake.
アンチリプレイ防御の最も単純な形式は、サーバーが各セッションチケットを1回しか使用できないようにすることです。 たとえば、サーバーはすべての未処理の有効なチケットのデータベースを維持し、使用中のデータベースから各チケットを削除できます。 不明なチケットが提供された場合、サーバーは完全なハンドシェイクにフォールバックします。
If the tickets are not self-contained but rather are database keys, and the corresponding PSKs are deleted upon use, then connections established using PSKs enjoy forward secrecy. This improves security for all 0-RTT data and PSK usage when PSK is used without (EC)DHE.
チケットが自己完結型ではなくデータベースキーであり、対応するPSKが使用時に削除される場合、PSKを使用して確立された接続は前方秘匿性を享受します。 これにより、PSKが（EC）DHEなしで使用される場合に、すべての0-RTTデータとPSK使用のセキュリティが向上します。
Because this mechanism requires sharing the session database between server nodes in environments with multiple distributed servers, it may be hard to achieve high rates of successful PSK 0-RTT connections when compared to self-encrypted tickets. Unlike session databases, session tickets can successfully do PSK-based session establishment even without consistent storage, though when 0-RTT is allowed they still require consistent storage for anti-replay of 0-RTT data, as detailed in the following section.
このメカニズムでは、複数の分散サーバーが存在する環境のサーバーノード間でセッションデータベースを共有する必要があるため、自己暗号化チケットと比較して高い成功率のPSK 0-RTT接続を達成するのは困難です。 セッションデータベースとは異なり、セッションチケットは、一貫したストレージがなくてもPSKベースのセッション確立を正常に実行できますが、次のセクションで説明するように、0-RTTが許可されている場合、0-RTTデータのリプレイ防止のために一貫したストレージが必要です。
An alternative form of anti-replay is to record a unique value derived from the ClientHello (generally either the random value or the PSK binder) and reject duplicates. Recording all ClientHellos causes state to grow without bound, but a server can instead record ClientHellos within a given time window and use the "obfuscated_ticket_age" to ensure that tickets aren't reused outside that window.
アンチリプレイの代替形式は、ClientHelloから派生した一意の値（通常はランダム値またはPSKバインダー）を記録し、重複を拒否することです。 すべてのClientHelloを記録すると状態は際限なく拡大しますが、サーバーは代わりに特定の時間枠内でClientHelloを記録し、「obfuscated_ticket_age」を使用してその枠外でチケットが再利用されないようにします。
In order to implement this, when a ClientHello is received, the server first verifies the PSK binder as described in Section 4.2.11. It then computes the expected_arrival_time as described in the next section and rejects 0-RTT if it is outside the recording window, falling back to the 1-RTT handshake.
これを実装するために、ClientHelloが受信されると、サーバーはセクション4.2.11で説明されているようにPSKバインダーを最初に検証します。 次に、次のセクションで説明するとおりexpected_arrival_timeを計算し、記録ウィンドウの外側にある場合は0-RTTを拒否し、1-RTTハンドシェイクにフォールバックします。
If the expected_arrival_time is in the window, then the server checks to see if it has recorded a matching ClientHello. If one is found, it either aborts the handshake with an "illegal_parameter" alert or accepts the PSK but rejects 0-RTT. If no matching ClientHello is found, then it accepts 0-RTT and then stores the ClientHello for as long as the expected_arrival_time is inside the window. Servers MAY also implement data stores with false positives, such as Bloom filters, in which case they MUST respond to apparent replay by rejecting 0-RTT but MUST NOT abort the handshake.
expected_arrival_timeがウィンドウ内にある場合、サーバーは一致するClientHelloを記録したかどうかを確認します。 見つかった場合、「illegal_parameter」アラートでハンドシェイクを中止するか、PSKを受け入れますが、0-RTTは拒否します。 一致するClientHelloが見つからない場合、0-RTTを受け入れ、expected_arrival_timeがウィンドウ内にある限りClientHelloを保存します。 サーバーは、ブルームフィルターなどの誤検知のあるデータストアを実装することもできます。この場合、0-RTTを拒否することで明らかなリプレイに応答する必要がありますが、ハンドシェイクを中止してはなりません。
The server MUST derive the storage key only from validated sections of the ClientHello. If the ClientHello contains multiple PSK identities, then an attacker can create multiple ClientHellos with different binder values for the less-preferred identity on the assumption that the server will not verify it (as recommended by Section 4.2.11). I.e., if the client sends PSKs A and B but the server prefers A, then the attacker can change the binder for B without affecting the binder for A. If the binder for B is part of the storage key, then this ClientHello will not appear as a duplicate, which will cause the ClientHello to be accepted, and may cause side effects such as replay cache pollution, although any 0-RTT data will not be decryptable because it will use different keys. If the validated binder or the ClientHello.random is used as the storage key, then this attack is not possible.
サーバーは、ClientHelloの検証済みセクションからのみストレージキーを取得する必要があります。 ClientHelloに複数のPSK IDが含まれている場合、攻撃者は、サーバーがそれを検証しないという前提で（4.2.11項で推奨されているように）、優先度の低いIDに対して異なるバインダー値を持つ複数のClientHelloを作成できます。 つまり、クライアントがPSK AおよびBを送信し、サーバーがAを好む場合、攻撃者はAのバインダーに影響を与えることなくBのバインダーを変更できます。Bのバインダーがストレージキーの一部である場合、このClientHelloは表示されません 重複として、ClientHelloが受け入れられ、リプレイキャッシュ汚染などの副作用が発生する可能性がありますが、0-RTTデータは異なるキーを使用するため解読できません。 検証済みのバインダーまたはClientHello.randomがストレージキーとして使用されている場合、この攻撃は不可能です。
Because this mechanism does not require storing all outstanding tickets, it may be easier to implement in distributed systems with high rates of resumption and 0-RTT, at the cost of potentially weaker anti-replay defense because of the difficulty of reliably storing and retrieving the received ClientHello messages. In many such systems, it is impractical to have globally consistent storage of all the received ClientHellos. In this case, the best anti-replay protection is provided by having a single storage zone be authoritative for a given ticket and refusing 0-RTT for that ticket in any other zone. This approach prevents simple replay by the attacker because only one zone will accept 0-RTT data. A weaker design is to implement separate storage for each zone but allow 0-RTT in any zone. This approach limits the number of replays to once per zone. Application message duplication of course remains possible with either design.
このメカニズムはすべての未処理のチケットを保存する必要がないため、高いレートの再開と0-RTTを備えた分散システムに実装する方が簡単かもしれません。ただし、 ClientHelloメッセージを受信しました。 このようなシステムの多くでは、受信したすべてのClientHelloをグローバルに一貫したストレージにすることは実用的ではありません。 この場合、単一のストレージゾーンを特定のチケットに対して権限を持たせ、他のゾーンではそのチケットの0-RTTを拒否することにより、最適なアンチリプレイ保護が提供されます。 このアプローチは、1つのゾーンのみが0-RTTデータを受け入れるため、攻撃者による単純なリプレイを防ぎます。 弱い設計では、ゾーンごとに個別のストレージを実装しますが、どのゾーンでも0-RTTを許可します。 このアプローチでは、リプレイの回数がゾーンごとに1回に制限されます。 もちろん、どちらの設計でもアプリケーションメッセージの複製は可能です。
When implementations are freshly started, they SHOULD reject 0-RTT as long as any portion of their recording window overlaps the startup time. Otherwise, they run the risk of accepting replays which were originally sent during that period.
実装が新たに開始されると、記録ウィンドウの一部が起動時間と重複する限り、0-RTTを拒否する必要があります。 そうしないと、元々その期間に送信されたリプレイを受け入れるリスクがあります。
Note: If the client's clock is running much faster than the server's, then a ClientHello may be received that is outside the window in the future, in which case it might be accepted for 1-RTT, causing a client retry, and then acceptable later for 0-RTT. This is another variant of the second form of attack described in Section 8.
注：クライアントのクロックがサーバーのクロックよりもはるかに高速で実行されている場合、将来ウィンドウの外にあるClientHelloが受信される可能性があります。 0-RTTの場合。 これは、セクション8で説明した攻撃の2番目の形式の別の変形です。
Because the ClientHello indicates the time at which the client sent it, it is possible to efficiently determine whether a ClientHello was likely sent reasonably recently and only accept 0-RTT for such a ClientHello, otherwise falling back to a 1-RTT handshake. This is necessary for the ClientHello storage mechanism described in Section 8.2 because otherwise the server needs to store an unlimited number of ClientHellos, and is a useful optimization for self-contained single-use tickets because it allows efficient rejection of ClientHellos which cannot be used for 0-RTT.
ClientHelloはクライアントが送信した時刻を示すため、ClientHelloが最近合理的に送信された可能性があるかどうかを効率的に判断し、そのようなClientHelloに対して0-RTTのみを受け入れるか、そうでなければ1-RTTハンドシェイクにフォールバックできます。 これは、サーバーが無制限の数のClientHelloを格納する必要があるため、セクション8.2で説明されているClientHelloストレージメカニズムに必要であり、0-RTTに使用できないClientHelloを効率的に拒否できるため、自己完結型の使い捨てチケットの便利な最適化です。
In order to implement this mechanism, a server needs to store the time that the server generated the session ticket, offset by an estimate of the round-trip time between client and server. I.e.,
このメカニズムを実装するために、サーバーは、サーバーがセッションチケットを生成した時間を、クライアントとサーバー間の往復時間の推定値で相殺して保存する必要があります。 つまり、
adjusted_creation_time = creation_time + estimated_RTT
This value can be encoded in the ticket, thus avoiding the need to keep state for each outstanding ticket. The server can determine the client's view of the age of the ticket by subtracting the ticket's "ticket_age_add" value from the "obfuscated_ticket_age" parameter in the client's "pre_shared_key" extension. The server can determine the expected_arrival_time of the ClientHello as:
この値はチケットにエンコードできるため、未処理の各チケットの状態を維持する必要がなくなります。 サーバーは、クライアントの「pre_shared_key」拡張機能の「obfuscated_ticket_age」パラメーターからチケットの「ticket_age_add」値を減算することにより、クライアントのチケットの経過時間のビューを判別できます。 サーバーは、ClientHelloのexpected_arrival_timeを次のように決定できます。
expected_arrival_time = adjusted_creation_time + clients_ticket_age
When a new ClientHello is received, the expected_arrival_time is then compared against the current server wall clock time and if they differ by more than a certain amount, 0-RTT is rejected, though the 1-RTT handshake can be allowed to complete.
新しいClientHelloが受信されると、expected_arrival_timeが現在のサーバーのウォールクロック時間と比較され、一定以上の差がある場合は、1-RTTハンドシェイクを完了できますが、0-RTTは拒否されます。
There are several potential sources of error that might cause mismatches between the expected_arrival_time and the measured time. Variations in client and server clock rates are likely to be minimal, though potentially the absolute times may be off by large values. Network propagation delays are the most likely causes of a mismatch in legitimate values for elapsed time. Both the NewSessionTicket and ClientHello messages might be retransmitted and therefore delayed, which might be hidden by TCP. For clients on the Internet, this implies windows on the order of ten seconds to account for errors in clocks and variations in measurements; other deployment scenarios may have different needs. Clock skew distributions are not symmetric, so the optimal tradeoff may involve an asymmetric range of permissible mismatch values.
expected_arrival_timeと測定された時間との不一致を引き起こす可能性のあるエラーの原因はいくつかあります。 クライアントとサーバーのクロックレートの変動は最小になる可能性がありますが、大きな値によって絶対時間はずれている可能性があります。 ネットワーク伝播遅延は、経過時間の正当な値の不一致の最も可能性の高い原因です。 NewSessionTicketメッセージとClientHelloメッセージの両方が再送信される可能性があるため、TCPによって隠される可能性があります。 インターネット上のクライアントの場合、これは、クロックの誤差と測定値の変動を考慮して、10秒程度のウィンドウを意味します。 他の展開シナリオには異なるニーズがあります。 クロックスキューの分布は対称ではないため、最適なトレードオフには、許容される不一致値の非対称範囲が含まれる場合があります。
Note that freshness checking alone is not sufficient to prevent replays because it does not detect them during the error window, which -- depending on bandwidth and system capacity -- could include billions of replays in real-world settings. In addition, this freshness checking is only done at the time the ClientHello is received and not when subsequent early Application Data records are received. After early data is accepted, records may continue to be streamed to the server over a longer time period.
フレッシュネスチェックだけでは、エラーウィンドウ中にそれらを検出しないため、リプレイを防ぐのに十分ではないことに注意してください。 さらに、この鮮度チェックはClientHelloが受信されたときにのみ実行され、後続の初期アプリケーションデータレコードが受信されたときは実行されません。 初期のデータが受け入れられた後、レコードはより長い期間にわたってサーバーにストリーミングされ続ける可能性があります。
In the absence of an application profile standard specifying otherwise:
別の方法で指定するアプリケーションプロファイル標準がない場合：
A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 [GCM] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites (see Appendix B.4).
TLS準拠のアプリケーションは、TLS_AES_128_GCM_SHA256 [GCM]暗号スイートを実装しなければならず、TLS_AES_256_GCM_SHA384 [GCM]およびTLS_CHACHA20_POLY1305_SHA256 [RFC8439]暗号スイートを実装する必要があります（付録B.4を参照）。
A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A TLS-compliant application MUST support key exchange with secp256r1 (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748].
TLS準拠のアプリケーションは、rsa_pkcs1_sha256（証明書用）、rsa_pss_rsae_sha256（CertificateVerifyおよび証明書用）、およびecdsa_secp256r1_sha256によるデジタル署名をサポートする必要があります。 TLS準拠のアプリケーションは、secp256r1（NIST P-256）との鍵交換をサポートしなければならず（MUST）、X25519 [RFC7748]との鍵交換をサポートする必要があります。
In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the following TLS extensions:
別の方法で指定するアプリケーションプロファイル標準がない場合、TLS準拠のアプリケーションは次のTLS拡張を実装する必要があります。
- Supported Versions ("supported_versions"; Section 4.2.1)
- サポートされているバージョン（ "supported_versions";セクション4.2.1）
- Cookie ("cookie"; Section 4.2.2)
- クッキー（"cookie";セクション4.2.2）
- Signature Algorithms ("signature_algorithms"; Section 4.2.3)
- 署名アルゴリズム（ "signature_algorithms";セクション4.2.3）
- Signature Algorithms Certificate ("signature_algorithms_cert"; Section 4.2.3)
- 署名アルゴリズム証明書（ "signature_algorithms_cert";セクション4.2.3）
- Negotiated Groups ("supported_groups"; Section 4.2.7)
- 交渉済みグループ（ "supported_groups";セクション4.2.7）
- Key Share ("key_share"; Section 4.2.8)
- 鍵共有（ "key_share";セクション4.2.8）
- Server Name Indication ("server_name"; Section 3 of [RFC6066])
- サーバー名表示（ "server_name"; [RFC6066]のセクション3）
All implementations MUST send and use these extensions when offering applicable features:
適用可能な機能を提供する場合、すべての実装はこれらの拡張機能を送信して使用する必要があります。
- "supported_versions" is REQUIRED for all ClientHello, ServerHello, and HelloRetryRequest messages.
-「supported_versions」は、ClientHello、ServerHello、およびHelloRetryRequestのすべてのメッセージに必要です。
- "signature_algorithms" is REQUIRED for certificate authentication.
- 証明書認証には「signature_algorithms」が必要です。
- "supported_groups" is REQUIRED for ClientHello messages using DHE or ECDHE key exchange.
- DHEまたはECDHEキー交換を使用するClientHelloメッセージには、「supported_groups」が必要です。
- "key_share" is REQUIRED for DHE or ECDHE key exchange.
-「key_share」は、DHEまたはECDHEキー交換に必要です。
- "pre_shared_key" is REQUIRED for PSK key agreement.
-「pre_shared_key」はPSK鍵合意に必要です。
- "psk_key_exchange_modes" is REQUIRED for PSK key agreement.
-「psk_key_exchange_modes」は、PSKキーの合意に必要です。
A client is considered to be attempting to negotiate using this specification if the ClientHello contains a "supported_versions" extension with 0x0304 contained in its body. Such a ClientHello message MUST meet the following requirements:
ClientHelloの本文に0x0304の「supported_versions」拡張が含まれている場合、クライアントはこの仕様を使用してネゴシエートしようとしていると見なされます。 このようなClientHelloメッセージは、次の要件を満たしている必要があります。
- If not containing a "pre_shared_key" extension, it MUST contain both a "signature_algorithms" extension and a "supported_groups" extension.
-「pre_shared_key」拡張子を含まない場合、「signature_algorithms」拡張子と「supported_groups」拡張子の両方を含める必要があります。
- If containing a "supported_groups" extension, it MUST also contain a "key_share" extension, and vice versa. An empty KeyShare.client_shares vector is permitted.
-「supported_groups」拡張子を含む場合、「key_share」拡張子も含める必要があります（逆も同様）。 空のKeyShare.client_sharesベクトルは許可されます。
Servers receiving a ClientHello which does not conform to these requirements MUST abort the handshake with a "missing_extension" alert.
これらの要件に適合しないClientHelloを受信するサーバーは、「missing_extension」アラートでハンドシェイクを中止する必要があります。
Additionally, all implementations MUST support the use of the "server_name" extension with applications capable of using it. Servers MAY require clients to send a valid "server_name" extension. Servers requiring this extension SHOULD respond to a ClientHello lacking a "server_name" extension by terminating the connection with a "missing_extension" alert.
さらに、すべての実装は、それを使用できるアプリケーションで「server_name」拡張機能の使用をサポートする必要があります。 サーバーは、クライアントに有効な「server_name」拡張子を送信するよう要求する場合があります。 この拡張機能を必要とするサーバーは、「missing_extension」アラートで接続を終了することにより、「server_name」拡張機能がないClientHelloに応答する必要があります。
This section describes invariants that TLS endpoints and middleboxes MUST follow. It also applies to earlier versions of TLS.
このセクションでは、TLSエンドポイントとミドルボックスが従わなければならない不変条件について説明します。 TLSの以前のバージョンにも適用されます。
TLS is designed to be securely and compatibly extensible. Newer clients or servers, when communicating with newer peers, should negotiate the most preferred common parameters. The TLS handshake provides downgrade protection: Middleboxes passing traffic between a newer client and newer server without terminating TLS should be unable to influence the handshake (see Appendix E.1). At the same time, deployments update at different rates, so a newer client or server MAY continue to support older parameters, which would allow it to interoperate with older endpoints.
TLSは、安全かつ互換性のある拡張が可能なように設計されています。 新しいクライアントまたはサーバーは、新しいピアと通信するときに、最も優先される共通パラメーターをネゴシエートする必要があります。 TLSハンドシェイクは、ダウングレード保護を提供します。TLSを終了せずに新しいクライアントと新しいサーバー間でトラフィックを渡すミドルボックスは、ハンドシェイクに影響を与えることができません（付録E.1を参照）。 同時に、展開は異なるレートで更新されるため、新しいクライアントまたはサーバーは古いパラメーターを引き続きサポートすることができます。これにより、古いエンドポイントとの相互運用が可能になります。
For this to work, implementations MUST correctly handle extensible fields:
これが機能するためには、実装は拡張可能なフィールドを正しく処理しなければなりません：
- A client sending a ClientHello MUST support all parameters advertised in it. Otherwise, the server may fail to interoperate by selecting one of those parameters.
- ClientHelloを送信するクライアントは、その中でアドバタイズされるすべてのパラメーターをサポートする必要があります。 そうしないと、サーバーはこれらのパラメーターのいずれかを選択して相互運用できなくなる可能性があります。
- A server receiving a ClientHello MUST correctly ignore all unrecognized cipher suites, extensions, and other parameters. Otherwise, it may fail to interoperate with newer clients. In TLS 1.3, a client receiving a CertificateRequest or NewSessionTicket MUST also ignore all unrecognized extensions.
- ClientHelloを受信するサーバーは、認識されないすべての暗号スイート、拡張、およびその他のパラメーターを正しく無視する必要があります。 そうしないと、新しいクライアントとの相互運用に失敗する場合があります。 TLS 1.3では、CertificateRequestまたはNewSessionTicketを受信するクライアントは、認識されないすべての拡張機能も無視する必要があります。
- A middlebox which terminates a TLS connection MUST behave as a compliant TLS server (to the original client), including having a certificate which the client is willing to accept, and also as a compliant TLS client (to the original server), including verifying the original server's certificate. In particular, it MUST generate its own ClientHello containing only parameters it understands, and it MUST generate a fresh ServerHello random value, rather than forwarding the endpoint's value.
- TLS接続を終了するミドルボックスは、（元のクライアントへの）準拠TLSサーバーとして動作する必要があります。 元のサーバーの証明書。 特に、理解できるパラメータのみを含む独自のClientHelloを生成する必要があり、エンドポイントの値を転送するのではなく、新しいServerHelloランダム値を生成する必要があります。
Note that TLS's protocol requirements and security analysis only apply to the two connections separately. Safely deploying a TLS terminator requires additional security considerations which are beyond the scope of this document.
TLSのプロトコル要件とセキュリティ分析は、2つの接続に個別にのみ適用されることに注意してください。 TLSターミネータを安全に展開するには、このドキュメントの範囲を超えた追加のセキュリティ上の考慮事項が必要です。
- A middlebox which forwards ClientHello parameters it does not understand MUST NOT process any messages beyond that ClientHello. It MUST forward all subsequent traffic unmodified. Otherwise, it may fail to interoperate with newer clients and servers.
- 理解できないClientHelloパラメーターを転送するミドルボックスは、そのClientHelloを超えるメッセージを処理してはなりません。 後続のすべてのトラフィックを変更せずに転送する必要があります。 そうしないと、新しいクライアントやサーバーとの相互運用に失敗する可能性があります。
Forwarded ClientHellos may contain advertisements for features not supported by the middlebox, so the response may include future TLS additions the middlebox does not recognize. These additions MAY change any message beyond the ClientHello arbitrarily. In particular, the values sent in the ServerHello might change, the ServerHello format might change, and the TLSCiphertext format might change.
転送されたClientHellosには、middleboxでサポートされていない機能の広告が含まれている可能性があるため、応答には、middleboxが認識しない将来のTLS追加が含まれる場合があります。 これらの追加により、ClientHelloを超えるメッセージを任意に変更できます。 特に、ServerHelloで送信される値が変更される場合があり、ServerHello形式が変更される場合があり、TLSCiphertext形式が変更される場合があります。
The design of TLS 1.3 was constrained by widely deployed non-compliant TLS middleboxes (see Appendix D.4); however, it does not relax the invariants. Those middleboxes continue to be non-compliant.
TLS 1.3の設計は、広く展開されている非準拠TLSミドルボックスによって制約されていました（付録D.4を参照）。 ただし、不変式は緩和されません。 これらのミドルボックスは引き続き非準拠です。
Security issues are discussed throughout this memo, especially in Appendices C, D, and E.
このメモ全体、特に付録C、D、およびEでセキュリティの問題について説明します。
This document uses several registries that were originally created in [RFC4346] and updated in [RFC8447]. IANA has updated these to reference this document. The registries and their allocation policies are below:
このドキュメントは、[RFC4346]で最初に作成され、[RFC8447]で更新されたいくつかのレジストリを使用します。 IANAは、このドキュメントを参照するためにこれらを更新しました。 レジストリとその割り当てポリシーは次のとおりです。
- TLS Cipher Suites registry: values with the first byte in the range 0-254 (decimal) are assigned via Specification Required [RFC8126]. Values with the first byte 255 (decimal) are reserved for Private Use [RFC8126].
- TLS Cipher Suitesレジストリ：0〜254（10進数）の範囲の最初のバイトを持つ値は、仕様が必要[RFC8126]によって割り当てられます。 最初のバイトが255（10進数）の値は、プライベート使用のために予約されています[RFC8126]。
IANA has added the cipher suites listed in Appendix B.4 to the registry. The "Value" and "Description" columns are taken from the table. The "DTLS-OK" and "Recommended" columns are both marked as "Y" for each new cipher suite.
IANAは、付録B.4にリストされている暗号スイートをレジストリに追加しました。 「値」列と「説明」列は表から取得されます。 「DTLS-OK」および「推奨」列は、新しい暗号スイートごとに「Y」としてマークされます。
- TLS ContentType registry: Future values are allocated via Standards Action [RFC8126].
- TLS ContentTypeレジストリ：将来の値は、標準アクション[RFC8126]を介して割り当てられます。
- TLS Alerts registry: Future values are allocated via Standards Action [RFC8126]. IANA has populated this registry with the values from Appendix B.2. The "DTLS-OK" column is marked as "Y" for all such values. Values marked as "_RESERVED" have comments describing their previous usage.
- TLS Alertsレジストリ：将来の値は、Standards Action [RFC8126]を介して割り当てられます。 IANAはこのレジストリに付録B.2の値を設定しました。 「DTLS-OK」列は、そのようなすべての値に対して「Y」としてマークされます。 「_RESERVED」とマークされた値には、以前の使用法を説明するコメントがあります。
- TLS HandshakeType registry: Future values are allocated via Standards Action [RFC8126]. IANA has updated this registry to rename item 4 from "NewSessionTicket" to "new_session_ticket" and populated this registry with the values from Appendix B.3. The "DTLS-OK" column is marked as "Y" for all such values. Values marked "_RESERVED" have comments describing their previous or temporary usage.
- TLS HandshakeTypeレジストリ：将来の値は、標準アクション[RFC8126]を介して割り当てられます。 IANAはこのレジストリを更新して、アイテム4の名前を「NewSessionTicket」から「new_session_ticket」に変更し、このレジストリに付録B.3の値を追加しました。 「DTLS-OK」列は、そのようなすべての値に対して「Y」としてマークされます。 「_RESERVED」とマークされた値には、以前の使用または一時的な使用を説明するコメントがあります。
This document also uses the TLS ExtensionType Values registry originally created in [RFC4366]. IANA has updated it to reference this document. Changes to the registry follow:
このドキュメントは、[RFC4366]で最初に作成されたTLS ExtensionType Valuesレジストリも使用します。 IANAはこのドキュメントを参照するように更新しました。 レジストリの変更は次のとおりです。
- IANA has updated the registration policy as follows:
- IANAは登録ポリシーを次のように更新しました。
Values with the first byte in the range 0-254 (decimal) are assigned via Specification Required [RFC8126]. Values with the first byte 255 (decimal) are reserved for Private Use [RFC8126].
0〜254（10進数）の範囲の最初のバイトを持つ値は、仕様が必要[RFC8126]によって割り当てられます。 最初のバイトが255（10進数）の値は、プライベート使用のために予約されています[RFC8126]。
- IANA has updated this registry to include the "key_share", "pre_shared_key", "psk_key_exchange_modes", "early_data", "cookie", "supported_versions", "certificate_authorities", "oid_filters", "post_handshake_auth", and "signature_algorithms_cert" extensions with the values defined in this document and the "Recommended" value of "Y".
- IANAは、このレジストリを更新して、「key_share」、「pre_shared_key」、「psk_key_exchange_modes」、「early_data」、「cookie」、「supported_versions」、「certificate_authorities」、「oid_filters」、「post_handshake_auth」、および「signature_algorithms_cert」拡張機能を追加しました このドキュメントで定義されている値と「推奨」値の「Y」を使用します。
- IANA has updated this registry to include a "TLS 1.3" column which lists the messages in which the extension may appear. This column has been initially populated from the table in Section 4.2, with any extension not listed there marked as "-" to indicate that it is not used by TLS 1.3.
- IANAは、このレジストリを更新して、拡張子が表示される可能性のあるメッセージをリストする「TLS 1.3」列を追加しました。 この列は最初にセクション4.2の表から読み込まれ、TLS 1.3で使用されていないことを示すために、そこにリストされていない拡張子は「-」としてマークされています。
This document updates an entry in the TLS Certificate Types registry originally created in [RFC6091] and updated in [RFC8447]. IANA has updated the entry for value 1 to have the name "OpenPGP_RESERVED", "Recommended" value "N", and comment "Used in TLS versions prior to 1.3."
このドキュメントは、[RFC6091]で最初に作成され、[RFC8447]で更新されたTLS証明書タイプレジストリのエントリを更新します。 IANAは、値1のエントリの名前を「OpenPGP_RESERVED」、「推奨」値「N」、およびコメント「1.3より前のTLSバージョンで使用」に更新しました。
This document updates an entry in the TLS Certificate Status Types registry originally created in [RFC6961]. IANA has updated the entry for value 2 to have the name "ocsp_multi_RESERVED" and comment "Used in TLS versions prior to 1.3".
このドキュメントは、[RFC6961]で最初に作成されたTLS証明書ステータスタイプレジストリのエントリを更新します。 IANAは、値2のエントリを「ocsp_multi_RESERVED」という名前に変更し、「1.3より前のTLSバージョンで使用」というコメントを追加しました。
This document updates two entries in the TLS Supported Groups registry (created under a different name by [RFC4492]; now maintained by [RFC8422]) and updated by [RFC7919] and [RFC8447]. The entries for values 29 and 30 (x25519 and x448) have been updated to also refer to this document.
このドキュメントは、TLS Supported Groupsレジストリの2つのエントリを更新し（[RFC4492]によって異なる名前で作成され、現在[RFC8422]によって管理されています）、[RFC7919]および[RFC8447]によって更新されます。 値29および30（x25519およびx448）のエントリは、このドキュメントも参照するように更新されました。
In addition, this document defines two new registries that are maintained by IANA:
さらに、このドキュメントでは、IANAが管理する2つの新しいレジストリを定義しています。
- TLS SignatureScheme registry: Values with the first byte in the range 0-253 (decimal) are assigned via Specification Required [RFC8126]. Values with the first byte 254 or 255 (decimal) are reserved for Private Use [RFC8126]. Values with the first byte in the range 0-6 or with the second byte in the range 0-3 that are not currently allocated are reserved for backward compatibility. This registry has a "Recommended" column. The registry has been initially populated with the values described in Section 4.2.3. The following values are marked as "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, and ed25519. The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action [RFC8126]. IESG Approval is REQUIRED for a Y->N transition.
- TLS SignatureSchemeレジストリ：範囲0〜253（10進数）の最初のバイトを持つ値は、仕様要求[RFC8126]を介して割り当てられます。 最初のバイトが254または255（10進数）の値は、プライベート使用のために予約されています[RFC8126]。 現在割り当てられていない0〜6の範囲の最初のバイトまたは0〜3の範囲の2番目のバイトを持つ値は、下位互換性のために予約されています。 このレジストリには「推奨」列があります。 レジストリには、最初にセクション4.2.3で説明されている値が設定されています。 次の値は「推奨」としてマークされています。ecdsa_secp256r1_sha256、ecdsa_secp384r1_sha384、rsa_pss_rsae_sha256、rsa_pss_rsae_sha384、rsa_pss_rsae_sha512、rsa_pss_pss_pss_pss_pss_pss_pss_shas、psa、psa、pssa、pssa、pssa、pssa、pssa、pssa、pssa、pssa、pssa 「推奨」列には、明示的に要求されない限り「N」の値が割り当てられます。「推奨」の値が「Y」の値を追加するには、標準アクション[RFC8126]が必要です。 IESG承認は、YからNへの移行に必要です。
- TLS PskKeyExchangeMode registry: Values in the range 0-253 (decimal) are assigned via Specification Required [RFC8126]. The values 254 and 255 (decimal) are reserved for Private Use [RFC8126]. This registry has a "Recommended" column. The registry has been initially populated with psk_ke (0) and psk_dhe_ke (1). Both are marked as "Recommended". The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action [RFC8126]. IESG Approval is REQUIRED for a Y->N transition.
- TLS PskKeyExchangeModeレジストリ：0〜253（10進数）の範囲の値は、仕様が必要[RFC8126]を介して割り当てられます。 値254および255（10進数）は、プライベート使用のために予約されています[RFC8126]。 このレジストリには「推奨」列があります。 レジストリには、最初にpsk_ke（0）およびpsk_dhe_ke（1）が入力されています。 両方とも「推奨」としてマークされています。 「推奨」列には、明示的に要求されない限り「N」の値が割り当てられます。「推奨」の値が「Y」の値を追加するには、標準アクション[RFC8126]が必要です。 IESG承認は、YからNへの移行に必要です。
[DH76] Diffie, W. and M. Hellman, "New directions in cryptography", IEEE Transactions on Information Theory, Vol. 22 No. 6, pp. 644-654, DOI 10.1109/TIT.1976.1055638, November 1976.
[DH76] Diffie、W.およびM. Hellman、「暗号化の新しい方向」、IEEE情報理論のトランザクション、Vol。 22 No. 6、pp。644-654、DOI 10.1109 / TIT.1976.1055638、1976年11月。
[ECDSA] American National Standards Institute, "Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI ANS X9.62-2005, November 2005.
[ECDSA]米国規格協会、「金融サービス業界向け公開鍵暗号：楕円曲線デジタル署名アルゴリズム（ECDSA）」、ANSI ANS X9.62-2005、2005年11月。
[GCM] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D, November 2007.
[GCM] Dworkin、M。、「ブロック暗号操作モードの推奨：ガロア/カウンターモード（GCM）およびGMAC」、NIST特別出版800-38D、DOI 10.6028 / NIST.SP.800-38D、2007年11月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：メッセージ認証のキー付きハッシュ」、RFC 2104、DOI 10.17487 / RFC2104、1997年2月、<https：//www.rfc-editor .org / info / rfc2104>。
[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>。
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <https://www.rfc-editor.org/info/rfc5116>.
[RFC5116] McGrew、D。、「認証された暗号化のためのインターフェースとアルゴリズム」、RFC 5116、DOI 10.17487 / RFC5116、2008年1月、<https://www.rfc-editor.org/info/rfc5116>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC5705] Rescorla、E。、「Transport Layer Security（TLS）のキーイングマテリアルエクスポーター」、RFC 5705、DOI 10.17487 / RFC5705、2010年3月、<https://www.rfc-editor.org/info/rfc5705>。
[RFC5756] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters", RFC 5756, DOI 10.17487/RFC5756, January 2010, <https://www.rfc-editor.org/info/rfc5756>.
[RFC5756] Turner、S.、Brown、D.、Yiu、K.、Housley、R。、およびT. Polk、「RSAES-OAEPおよびRSASSA-PSSアルゴリズムパラメーターの更新」、RFC 5756、DOI 10.17487 / RFC5756、 2010年1月、<https://www.rfc-editor.org/info/rfc5756>。
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/info/rfc5869>.
[RFC5869] Krawczyk、H。およびP. Eronen、「HMACベースの抽出および拡張キー派生関数（HKDF）」、RFC 5869、DOI 10.17487 / RFC5869、2010年5月、<https：//www.rfc-editor .org / info / rfc5869>。
[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] Eastlake 3rd、D。、「Transport Layer Security（TLS）Extensions：Extension Definitions」、RFC 6066、DOI 10.17487 / RFC6066、2011年1月、<https://www.rfc-editor.org/info/rfc6066> 。
[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", RFC 6655, DOI 10.17487/RFC6655, July 2012, <https://www.rfc-editor.org/info/rfc6655>.
[RFC6655] McGrew、D。およびD. Bailey、「トランスポート層セキュリティ（TLS）のためのAES-CCM暗号スイート」、RFC 6655、DOI 10.17487 / RFC6655、2012年7月、<https://www.rfc-editor.org / info / rfc6655>。
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/info/rfc6960>.
[RFC6960] Santesson、S.、Myers、M.、Ankney、R.、Malpani、A.、Galperin、S。、およびC. Adams、「X.509インターネット公開鍵インフラストラクチャオンライン証明書ステータスプロトコル-OCSP」、RFC 6960、DOI 10.17487 / RFC6960、2013年6月、<https://www.rfc-editor.org/info/rfc6960>。
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension", RFC 6961, DOI 10.17487/RFC6961, June 2013, <https://www.rfc-editor.org/info/rfc6961>.
[RFC6961] Pettersen、Y。、「トランスポート層セキュリティ（TLS）複数証明書ステータス要求拡張」、RFC 6961、DOI 10.17487 / RFC6961、2013年6月、<https://www.rfc-editor.org/info/rfc6961 >。
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, <https://www.rfc-editor.org/info/rfc6962>.
[RFC6962]ローリー、B。、ラングレー、A。、およびE.カスパー、「証明書の透明性」、RFC 6962、DOI 10.17487 / RFC6962、2013年6月、<https://www.rfc-editor.org/info/rfc6962 >。
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2013, <https://www.rfc-editor.org/info/rfc6979>.
[RFC6979] Pornin、T.、「デジタル署名アルゴリズム（DSA）および楕円曲線デジタル署名アルゴリズム（ECDSA）の決定論的使用法」、RFC 6979、DOI 10.17487 / RFC6979、2013年8月、<https：//www.rfc- editor.org/info/rfc6979>。
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7301]フリーデル、S。、ポポフ、A。、ラングレー、A。、およびE.ステファン、「トランスポート層セキュリティ（TLS）アプリケーション層プロトコルネゴシエーション拡張機能」、RFC 7301、DOI 10.17487 / RFC7301、2014年7月、< https://www.rfc-editor.org/info/rfc7301>。
[RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, <https://www.rfc-editor.org/info/rfc7507>.
[RFC7507] Moeller、B。、およびA. Langley、「プロトコルダウングレード攻撃を防ぐためのTLSフォールバックシグナリング暗号スイート値（SCSV）」、RFC 7507、DOI 10.17487 / RFC7507、2015年4月、<https：//www.rfc-editor .org / info / rfc7507>。
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC7748] Langley、A.、Hamburg、M。、およびS. Turner、「セキュリティのための楕円曲線」、RFC 7748、DOI 10.17487 / RFC7748、2016年1月、<https://www.rfc-editor.org/info / rfc7748>。
[RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)", RFC 7919, DOI 10.17487/RFC7919, August 2016, <https://www.rfc-editor.org/info/rfc7919>.
[RFC7919] Gillmor、D。、「トランスポート層セキュリティ（TLS）のネゴシエートされた有限フィールドDiffie-Hellman一時パラメータ」、RFC 7919、DOI 10.17487 / RFC7919、2016年8月、<https://www.rfc-editor.org/ info / rfc7919>。
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <https://www.rfc-editor.org/info/rfc8017>.
[RFC8017] Moriarty、K.、Ed。、Kaliski、B.、Jonsson、J.、and A. Rusch、 "PKCS＃1：RSA Cryptography Specifications Version 2.2"、RFC 8017、DOI 10.17487 / RFC8017、November 2016、< https://www.rfc-editor.org/info/rfc8017>。
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/info/rfc8032>.
[RFC8032] Josefsson、S.およびI. Liusvaara、「Edwards-Curve Digital Signature Algorithm（EdDSA）」、RFC 8032、DOI 10.17487 / RFC8032、2017年1月、<https://www.rfc-editor.org/info/ rfc8032>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126] Cotton、M.、Leiba、B。、およびT. Narten、「RFCでIANA考慮事項セクションを記述するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[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>。
[RFC8439] 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>.
[RFC8439] Nir、Y。、およびA. Langley、「ChaCha20およびIETFプロトコル用のPoly1305」、RFC 8439、DOI 10.17487 / RFC8439、2018年6月、<https://www.rfc-editor.org/info/rfc8439>。
[SHS] Dang, Q., "Secure Hash Standard (SHS)", National Institute of Standards and Technology report, DOI 10.6028/NIST.FIPS.180-4, August 2015.
[SHS] Dang、Q。、「Secure Hash Standard（SHS）」、米国国立標準技術研究所レポート、DOI 10.6028 / NIST.FIPS.180-4、2015年8月。
[X690] ITU-T, "Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ISO/IEC 8825-1:2015, November 2015.
[X690] ITU-T、「情報技術-ASN.1エンコードルール：基本エンコードルール（BER）、標準エンコードルール（CER）および識別エンコードルール（DER）の仕様」、ISO / IEC 8825-1：2015 、2015年11月。
[AEAD-LIMITS] Luykx, A. and K. Paterson, "Limits on Authenticated Encryption Use in TLS", August 2017, <http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.
[AEAD-LIMITS] Luykx、A.、K。Paterson、「TLSでの認証済み暗号化使用の制限」、2017年8月、<http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf >。
[BBFGKZ16] Bhargavan, K., Brzuska, C., Fournet, C., Green, M., Kohlweiss, M., and S. Zanella-Beguelin, "Downgrade Resilience in Key-Exchange Protocols", Proceedings of IEEE Symposium on Security and Privacy (San Jose), DOI 10.1109/SP.2016.37, May 2016.
[BBFGKZ16]バルガヴァン、K。、ブルズカ、C。、フォーネット、C。、グリーン、M。、コールワイス、M。、およびS.ザネラ-ベグリン、「キー交換プロトコルの回復力のダウングレード」、IEEEシンポジウムの議事録 セキュリティとプライバシー（サンノゼ）、DOI 10.1109 / SP.2016.37、2016年5月。
[BBK17] Bhargavan, K., Blanchet, B., and N. Kobeissi, "Verified Models and Reference Implementations for the TLS 1.3 Standard Candidate", Proceedings of IEEE Symposium on Security and Privacy (San Jose), DOI 10.1109/SP.2017.26, May 2017.
[BBK17] Bhargavan、K.、Blanchet、B。、およびN. Kobeissi、「TLS 1.3標準候補の検証済みモデルおよび参照実装」、IEEE Symposium on Security and Privacy（San Jose）、DOI 10.1109 / SP。 2017.26、2017年5月。
[BDFKPPRSZZ16] Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Kohlweiss, M., Pan, J., Protzenko, J., Rastogi, A., Swamy, N., Zanella-Beguelin, S., and J. Zinzindohoue, "Implementing and Proving the TLS 1.3 Record Layer", Proceedings of IEEE Symposium on Security and Privacy (San Jose), May 2017, <https://eprint.iacr.org/2016/1178>.
[BDFKPPRSZZ16] Bhargavan、K.、Delignat-Lavaud、A.、Fournet、C.、Kohlweiss、M.、Pan、J.、Protzenko、J.、Rastogi、A.、Swamy、N.、Zanella-Beguelin、S 。、およびJ. Zinzindohoue、「TLS 1.3レコード層の実装と証明」、セキュリティとプライバシーに関するIEEEシンポジウムの議事録（サンノゼ）、2017年5月、<https://eprint.iacr.org/2016/1178>。
[Ben17a] Benjamin, D., "Presentation before the TLS WG at IETF 100", November 2017, <https://datatracker.ietf.org/meeting/100/materials/ slides-100-tls-sessa-tls13/>.
[Ben17a] Benjamin、D。、「IETF 100でのTLS WGの前のプレゼンテーション」、2017年11月、<https://datatracker.ietf.org/meeting/100/materials/ slides-100-tls-sessa-tls13 /> 。
[Ben17b] Benjamin, D., "Additional TLS 1.3 results from Chrome", message to the TLS mailing list, 18 December 2017, <https://www.ietf.org/mail-archive/web/tls/current/ msg25168.html>.
[Ben17b] Benjamin、D。、「Chromeからの追加TLS 1.3結果」、TLSメーリングリストへのメッセージ、2017年12月18日、<https://www.ietf.org/mail-archive/web/tls/current/ msg25168 .html>。
[Blei98] Bleichenbacher, D., "Chosen Ciphertext Attacks against Protocols Based on RSA Encryption Standard PKCS #1", Proceedings of CRYPTO '98, 1998.
[Blei98] Bleichenbacher、D。、「RSA暗号化標準PKCS＃1に基づくプロトコルに対する選択された暗号文攻撃」、Proceedings of CRYPTO '98、1998年。
[BMMRT15] Badertscher, C., Matt, C., Maurer, U., Rogaway, P., and B. Tackmann, "Augmented Secure Channels and the Goal of the TLS 1.3 Record Layer", ProvSec 2015, September 2015, <https://eprint.iacr.org/2015/394>.
[BMMRT15] Badertscher、C.、Matt、C.、Maurer、U.、Rogaway、P.、およびB. Tackmann、 "Augmented Secure Channels and the Goal of the TLS 1.3 Record Layer"、ProvSec 2015、September 2015、< https://eprint.iacr.org/2015/394>。
[BT16] Bellare, M. and B. Tackmann, "The Multi-User Security of Authenticated Encryption: AES-GCM in TLS 1.3", Proceedings of CRYPTO 2016, July 2016, <https://eprint.iacr.org/2016/564>.
[BT16] Bellare、M.、B。Tackmann、「認証済み暗号化のマルチユーザーセキュリティ：AES-GCM in TLS 1.3」、Proceedings of CRYPTO 2016、2016年7月、<https://eprint.iacr.org/2016 / 564>。
[CCG16] Cohn-Gordon, K., Cremers, C., and L. Garratt, "On Post-compromise Security", IEEE Computer Security Foundations Symposium, DOI 10.1109/CSF.2016.19, July 2015.
[CCG16] Cohn-Gordon、K.、Cremers、C。、およびL. Garratt、「事後のセキュリティについて」、IEEE Computer Security Foundations Symposium、DOI 10.1109 / CSF.2016.19、2015年7月。
[CHECKOWAY] Checkoway, S., Maskiewicz, J., Garman, C., Fried, J., Cohney, S., Green, M., Heninger, N., Weinmann, R., Rescorla, E., and H. Shacham, "A Systematic Analysis of the Juniper Dual EC Incident", Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security - CCS '16, DOI 10.1145/2976749.2978395, October 2016.
[CHECKOWAY] Checkoway、S.、Maskiewicz、J.、Garman、C.、Fried、J.、Cohney、S.、Green、M.、Heninger、N.、Weinmann、R.、Rescorla、E.、およびH 。Shacham、「ジュニパーデュアルECインシデントの体系的分析」、コンピューターおよび通信セキュリティに関する2016 ACM SIGSAC会議の議事録-CCS '16、DOI 10.1145 / 2976749.2978395、2016年10月。
[CHHSV17] Cremers, C., Horvat, M., Hoyland, J., Scott, S., and T. van der Merwe, "Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18", message to the TLS mailing list, 10 February 2017, <https://www.ietf.org/ mail-archive/web/tls/current/msg22382.html>.
[CHHSV17] Cremers、C.、Horvat、M.、Hoyland、J.、Scott、S.、およびT. van der Merwe、 "厄介なハンドシェイク：でのクライアント認証のクライアント/サーバービューの不一致の可能性 改訂18 "、TLSメーリングリストへのメッセージ、2017年2月10日、<https://www.ietf.org/ mail-archive / web / tls / current / msg22382.html>。
[CHSV16] Cremers, C., Horvat, M., Scott, S., and T. van der Merwe, "Automated Analysis and Verification of TLS 1.3: 0-RTT, Resumption and Delayed Authentication", Proceedings of IEEE Symposium on Security and Privacy (San Jose), DOI 10.1109/SP.2016.35, May 2016, <https://ieeexplore.ieee.org/document/7546518/>.
[CHSV16] Cremers、C.、Horvat、M.、Scott、S。、およびT. van der Merwe、「TLS 1.3の自動化された分析と検証：0-RTT、再開および遅延認証」、IEEE Symposium on Securityの議事録 and Privacy（San Jose）、DOI 10.1109 / SP.2016.35、2016年5月、<https://ieeexplore.ieee.org/document/7546518/>。
[CK01] Canetti, R. and H. Krawczyk, "Analysis of Key-Exchange Protocols and Their Use for Building Secure Channels", Proceedings of Eurocrypt 2001, DOI 10.1007/3-540-44987-6_28, April 2001.
[CK01] Canetti、R.およびH. Krawczyk、「鍵交換プロトコルの分析と安全なチャネルの構築のための使用」、Eurocrypt 2001の議事録、DOI 10.1007 / 3-540-44987-6_28、2001年4月。
[CLINIC] Miller, B., Huang, L., Joseph, A., and J. Tygar, "I Know Why You Went to the Clinic: Risks and Realization of HTTPS Traffic Analysis", Privacy Enhancing Technologies, pp. 143-163, DOI 10.1007/978-3-319-08506-7_8, 2014.
[CLINIC] Miller、B.、Huang、L.、Joseph、A。、およびJ. Tygar、「あなたがクリニックに行った理由を知っています：HTTPSトラフィック分析のリスクと実現」、プライバシー強化技術、pp。143- 163、DOI 10.1007 / 978-3-319-08506-7_8、2014。
[DFGS15] Dowling, B., Fischlin, M., Guenther, F., and D. Stebila, "A Cryptographic Analysis of the TLS 1.3 Handshake Protocol Candidates", Proceedings of ACM CCS 2015, October 2015, <https://eprint.iacr.org/2015/914>.
[DFGS15] Dowling、B.、Fischlin、M.、Guenther、F。、およびD. Stebila、「TLS 1.3ハンドシェイクプロトコル候補の暗号分析」、Proceedings of ACM CCS 2015、2015年10月、<https：// eprint.iacr.org/2015/914>。
[DFGS16] Dowling, B., Fischlin, M., Guenther, F., and D. Stebila, "A Cryptographic Analysis of the TLS 1.3 Full and Pre-shared Key Handshake Protocol", TRON 2016, February 2016, <https://eprint.iacr.org/2016/081>.
[DFGS16] Dowling、B.、Fischlin、M.、Guenther、F。、およびD. Stebila、「TLS 1.3完全および事前共有キーハンドシェイクプロトコルの暗号分析」、TRON 2016、2016年2月、<https： //eprint.iacr.org/2016/081>。
[DOW92] Diffie, W., van Oorschot, P., and M. Wiener, "Authentication and authenticated key exchanges", Designs, Codes and Cryptography, DOI 10.1007/BF00124891, June 1992.
[DOW92] Diffie、W.、van Oorschot、P。、およびM. Wiener、「Authentication and authentication key exchanges」、Designs、Codes and Cryptography、DOI 10.1007 / BF00124891、1992年6月。
[DSS] National Institute of Standards and Technology, U.S. Department of Commerce, "Digital Signature Standard (DSS)", NIST FIPS PUB 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013.
[DSS]米国国立標準技術研究所、米国商務省、「デジタル署名標準（DSS）」、NIST FIPS PUB 186-4、DOI 10.6028 / NIST.FIPS.186-4、2013年7月。
[FG17] Fischlin, M. and F. Guenther, "Replay Attacks on Zero Round-Trip Time: The Case of the TLS 1.3 Handshake Candidates", Proceedings of EuroS&P 2017, April 2017, <https://eprint.iacr.org/2017/082>.
[FG17] Fischlin、M.、F。Guenther、「ラウンドトリップ時間ゼロでのリプレイ攻撃：TLS 1.3ハンドシェイク候補のケース」、EuroS＆P 2017年版、2017年4月、<https://eprint.iacr.org / 2017/082>。
[FGSW16] Fischlin, M., Guenther, F., Schmidt, B., and B. Warinschi, "Key Confirmation in Key Exchange: A Formal Treatment and Implications for TLS 1.3", Proceedings of IEEE Symposium on Security and Privacy (San Jose), DOI 10.1109/SP.2016.34, May 2016, <https://ieeexplore.ieee.org/document/7546517/>.
[FGSW16] Fischlin、M.、Guenther、F.、Schmidt、B.、およびB. Warinschi、 "鍵交換における鍵の確認：TLS 1.3の形式的な扱いと意味"、セキュリティとプライバシーに関するIEEEシンポジウムの議事録（サン Jose）、DOI 10.1109 / SP.2016.34、2016年5月、<https://ieeexplore.ieee.org/document/7546517/>。
[FW15] Weimer, F., "Factoring RSA Keys With TLS Perfect Forward Secrecy", September 2015.
[FW15] Weimer、F。、「TLS Perfect Forward SecrecyによるRSAキーのファクタリング」、2015年9月。
[HCJC16] Husak, M., Cermak, M., Jirsik, T., and P. Celeda, "HTTPS traffic analysis and client identification using passive SSL/TLS fingerprinting", EURASIP Journal on Information Security, Vol. 2016, DOI 10.1186/s13635-016-0030-7, February 2016.
[HCJC16] Husak、M.、Cermak、M.、Jirsik、T。、およびP. Celeda、「パッシブSSL / TLSフィンガープリンティングを使用したHTTPSトラフィック分析およびクライアント識別」、EURASIP Journal on Information Security、Vol。 2016年、DOI 10.1186 / s13635-016-0030-7、2016年2月。
[HGFS15] Hlauschek, C., Gruber, M., Fankhauser, F., and C. Schanes, "Prying Open Pandora's Box: KCI Attacks against TLS", Proceedings of USENIX Workshop on Offensive Technologies, August 2015.
[HGFS15] Hlauschek、C.、Gruber、M.、Fankhauser、F.、and C. Schanes、 "Prying Open Pandora's Box：KCI Attacks against TLS"、Proceedings of USENIX Workshop on Offensive Technologies、August 2015。
[IEEE1363] IEEE, "IEEE Standard Specifications for Public Key Cryptography", IEEE Std. 1363-2000, DOI 10.1109/IEEESTD.2000.92292.
[IEEE1363] IEEE、「公開鍵暗号のIEEE標準仕様」、IEEE Std。 1363-2000、DOI 10.1109 / IEEESTD.2000.92292。
[JSS15] Jager, T., Schwenk, J., and J. Somorovsky, "On the Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 v1.5 Encryption", Proceedings of ACM CCS 2015, DOI 10.1145/2810103.2813657, October 2015, <https://www.nds.rub.de/media/nds/ veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf>.
[JSS15] Jager、T.、Schwenk、J。、およびJ. Somorovsky、「TLS 1.3およびPKCS＃1 v1.5暗号化の弱点に対するQUICのセキュリティについて」、Proceedings of ACM CCS 2015、DOI 10.1145 / 2810103.2813657、2015年10月、<https://www.nds.rub.de/media/nds/ veroeffentlichungen/2015/8月21日/ Tls13QuicAttacks.pdf>。
[KEYAGREEMENT] Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. Davis, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", National Institute of Standards and Technology, DOI 10.6028/NIST.SP.800-56Ar3, April 2018.
[KEYAGREEMENT] Barker、E.、Chen、L.、Roginsky、A.、Vassilev、A.、and R. Davis、 "Recommendation for Pair-Wise Key Establishment Schemes Using Using Discrete Logarithm Cryptography"、National Institute of Standard and Technology、 DOI 10.6028 / NIST.SP.800-56Ar3、2018年4月。
[Kraw10] Krawczyk, H., "Cryptographic Extraction and Key Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010, August 2010, <https://eprint.iacr.org/2010/264>.
[Kraw10] Krawczyk、H。、「暗号の抽出とキーの導出：HKDFスキーム」、Proceedings of CRYPTO 2010、2010年8月、<https://eprint.iacr.org/2010/264>。
[Kraw16] Krawczyk, H., "A Unilateral-to-Mutual Authentication Compiler for Key Exchange (with Applications to Client Authentication in TLS 1.3", Proceedings of ACM CCS 2016, October 2016, <https://eprint.iacr.org/2016/711>.
[Kraw16] Krawczyk、H.、「鍵交換のための片側から相互への認証コンパイラー（TLS 1.3でのクライアント認証へのアプリケーションを使用）」、ACM CCS 2016年版、2016年10月、<https://eprint.iacr.org / 2016/711>。
[KW16] Krawczyk, H. and H. Wee, "The OPTLS Protocol and TLS 1.3", Proceedings of EuroS&P 2016, March 2016, <https://eprint.iacr.org/2015/978>.
[KW16] Krawczyk、H. and H. Wee、 "The OPTLS Protocol and TLS 1.3"、Proceedings of EuroS＆P 2016、March 2016、<https://eprint.iacr.org/2015/978>。
[LXZFH16] Li, X., Xu, J., Zhang, Z., Feng, D., and H. Hu, "Multiple Handshakes Security of TLS 1.3 Candidates", Proceedings of IEEE Symposium on Security and Privacy (San Jose), DOI 10.1109/SP.2016.36, May 2016, <https://ieeexplore.ieee.org/document/7546519/>.
[LXZFH16] Li、X.、Xu、J.、Zhang、Z.、Feng、D。、およびH. Hu、「TLS 1.3候補の複数のハンドシェイクセキュリティ」、セキュリティとプライバシーに関するIEEEシンポジウムの議事録（サンノゼ） 、DOI 10.1109 / SP.2016.36、2016年5月、<https://ieeexplore.ieee.org/document/7546519/>。
[Mac17] MacCarthaigh, C., "Security Review of TLS1.3 0-RTT", March 2017, <https://github.com/tlswg/tls13-spec/ issues/1001>.
[Mac17] MacCarthaigh、C。、「TLS1.3 0-RTTのセキュリティレビュー」、2017年3月、<https://github.com/tlswg/tls13-spec/ issues / 1001>。
[PS18] Patton, C. and T. Shrimpton, "Partially specified channels: The TLS 1.3 record layer without elision", 2018, <https://eprint.iacr.org/2018/634>.
[PS18] Patton、C.およびT. Shrimpton、「部分的に指定されたチャネル：省略のないTLS 1.3レコード層」、2018年、<https://eprint.iacr.org/2018/634>。
[PSK-FINISHED] Scott, S., Cremers, C., Horvat, M., and T. van der Merwe, "Revision 10: possible attack if client authentication is allowed during PSK", message to the TLS mailing list, 31 October 2015, <https://www.ietf.org/ mail-archive/web/tls/current/msg18215.html>.
[PSK-FINISHED] Scott、S.、Cremers、C.、Horvat、M。、およびT. van der Merwe、「Revision 10：PSK中にクライアント認証が許可された場合の攻撃の可能性」、TLSメーリングリストへのメッセージ、31 2015年10月、<https://www.ietf.org/ mail-archive / web / tls / current / msg18215.html>。
[REKEY] Abdalla, M. and M. Bellare, "Increasing the Lifetime of a Key: A Comparative Analysis of the Security of Re-keying Techniques", ASIACRYPT 2000, DOI 10.1007/3-540-44448-3_42, October 2000.
[REKEY] Abdalla、M.、M。Bellare、「鍵の寿命を延ばす：再鍵技術のセキュリティの比較分析」、ASIACRYPT 2000、DOI 10.1007 / 3-540-44448-3_42、2000年10月。
[Res17a] Rescorla, E., "Preliminary data on Firefox TLS 1.3 Middlebox experiment", message to the TLS mailing list, 5 December 2017, <https://www.ietf.org/ mail-archive/web/tls/current/msg25091.html>.
[Res17a] Rescorla、E。、「Firefox TLS 1.3 Middlebox実験の予備データ」、TLSメーリングリストへのメッセージ、2017年12月5日、<https://www.ietf.org/ mail-archive / web / tls / current /msg25091.html>。
[Res17b] Rescorla, E., "More compatibility measurement results", message to the TLS mailing list, 22 December 2017, <https://www.ietf.org/mail-archive/web/tls/current/ msg25179.html>.
[Res17b] Rescorla、E。、「その他の互換性測定結果」、TLSメーリングリストへのメッセージ、2017年12月22日、<https://www.ietf.org/mail-archive/web/tls/current/ msg25179.html >。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.
[RFC3552] Rescorla、E。、およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストの作成ガイドライン」、BCP 72、RFC 3552、DOI 10.17487 / RFC3552、2003年7月、<https://www.rfc-editor.org/ info / rfc3552>。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.
[RFC4086] Eastlake 3rd、D.、Schiller、J。、およびS. Crocker、「Randomness Requirements for Security」、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、2005年6月、<https：//www.rfc-editor .org / info / rfc4086>。
[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、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.1」、RFC 4346、DOI 10.17487 / RFC4346、2006年4月、<https://www.rfc-editor.org/info / rfc4346>。
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, <https://www.rfc-editor.org/info/rfc4366>.
[RFC4366] Blake-Wilson、S.、Nystrom、M.、Hopwood、D.、Mikkelsen、J。、およびT. Wright、「Transport Layer Security（TLS）Extensions」、RFC 4366、DOI 10.17487 / RFC4366、2006年4月 、<https://www.rfc-editor.org/info/rfc4366>。
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006, <https://www.rfc-editor.org/info/rfc4492>.
[RFC4492] Blake-Wilson、S.、Bolyard、N.、Gupta、V.、Hawk、C。、およびB. Moeller、「Elliptic Curve Cryptography（ECC）Cipher Suites for Transport Layer Security（TLS）」、RFC 4492 、DOI 10.17487 / RFC4492、2006年5月、<https://www.rfc-editor.org/info/rfc4492>。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC5077] Salowey、J.、Zhou、H.、Eronen、P。、およびH. Tschofenig、「サーバー側の状態なしのトランスポート層セキュリティ（TLS）セッション再開」、RFC 5077、DOI 10.17487 / RFC5077、2008年1月、 <https://www.rfc-editor.org/info/rfc5077>。
[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>。
[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）のキーを確立するためのデータグラムトランスポートレイヤーセキュリティ（DTLS）拡張」、RFC 5764、DOI 10.17487 / RFC5764、2010年5月、<https ：//www.rfc-editor.org/info/rfc5764>。
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, <https://www.rfc-editor.org/info/rfc5929>.
[RFC5929] Altman、J.、Williams、N。、およびL. Zhu、「TLSのチャネルバインディング」、RFC 5929、DOI 10.17487 / RFC5929、2010年7月、<https://www.rfc-editor.org/info / rfc5929>。
[RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", RFC 6091, DOI 10.17487/RFC6091, February 2011, <https://www.rfc-editor.org/info/rfc6091>.
[RFC6091] Mavrogiannopoulos、N。およびD. Gillmor、「トランスポート層セキュリティ（TLS）認証のためのOpenPGPキーの使用」、RFC 6091、DOI 10.17487 / RFC6091、2011年2月、<https://www.rfc-editor.org/ info / rfc6091>。
[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, DOI 10.17487/RFC6101, August 2011, <https://www.rfc-editor.org/info/rfc6101>.
[RFC6101] Freier、A.、Karlton、P。、およびP. Kocher、「Secure Sockets Layer（SSL）Protocol Version 3.0」、RFC 6101、DOI 10.17487 / RFC6101、2011年8月、<https：//www.rfc -editor.org/info/rfc6101>。
[RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March 2011, <https://www.rfc-editor.org/info/rfc6176>.
[RFC6176]ターナー、S。およびT.ポーク、「Prohibiting Secure Sockets Layer（SSL）Version 2.0」、RFC 6176、DOI 10.17487 / RFC6176、2011年3月、<https://www.rfc-editor.org/info/ rfc6176>。
[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>。
[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, DOI 10.17487/RFC6520, February 2012, <https://www.rfc-editor.org/info/rfc6520>.
[RFC6520] Seggelmann、R.、Tuexen、M。、およびM. Williams、「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）ハートビート拡張」、RFC 6520、DOI 10.17487 / RFC6520、2012年2月、<https ：//www.rfc-editor.org/info/rfc6520>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールディング、R。、エド。 およびJ. Reschke、Ed。、「ハイパーテキスト転送プロトコル（HTTP / 1.1）：メッセージの構文とルーティング」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<https://www.rfc-editor.org/info/ rfc7230>。
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[RFC7250] Wouters、P.、Ed。、Tschofenig、H.、Ed。、Gilmore、J.、Weiler、S。、およびT. Kivinen、「Transport Layer Security（TLS）およびDatagram Transport LayerでのRaw公開鍵の使用」 セキュリティ（DTLS）」、RFC 7250、DOI 10.17487 / RFC7250、2014年6月、<https://www.rfc-editor.org/info/rfc7250>。
[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, DOI 10.17487/RFC7465, February 2015, <https://www.rfc-editor.org/info/rfc7465>.
[RFC7465] Popov、A。、「RC4暗号スイートの禁止」、RFC 7465、DOI 10.17487 / RFC7465、2015年2月、<https://www.rfc-editor.org/info/rfc7465>。
[RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley, "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, DOI 10.17487/RFC7568, June 2015, <https://www.rfc-editor.org/info/rfc7568>.
[RFC7568]バーンズ、R。、トムソン、M。、ピロンティ、A。、およびA.ラングレー、「非推奨のSecure Sockets Layerバージョン3.0」、RFC 7568、DOI 10.17487 / RFC7568、2015年6月、<https：// www。 rfc-editor.org/info/rfc7568>。
[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., Langley, A., and M. Ray, "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", RFC 7627, DOI 10.17487/RFC7627, September 2015, <https://www.rfc-editor.org/info/rfc7627>.
[RFC7627] Bhargavan、K.、Ed。、Delignat-Lavaud、A.、Pironti、A.、Langley、A。、およびM. Ray、「Transport Layer Security（TLS）Session Hash and Extended Master Secret Extension」、RFC 7627、DOI 10.17487 / RFC7627、2015年9月、<https://www.rfc-editor.org/info/rfc7627>。
[RFC7685] Langley, A., "A Transport Layer Security (TLS) ClientHello Padding Extension", RFC 7685, DOI 10.17487/RFC7685, October 2015, <https://www.rfc-editor.org/info/rfc7685>.
[RFC7685] Langley、A。、「A Transport Layer Security（TLS）ClientHello Padding Extension」、RFC 7685、DOI 10.17487 / RFC7685、2015年10月、<https://www.rfc-editor.org/info/rfc7685>。
[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>。
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, <https://www.rfc-editor.org/info/rfc8305>.
[RFC8305] Schinazi、D. and T. Pauly、 "Happy Eyeballs Version 2：Better Connectivity Using Concurrency"、RFC 8305、DOI 10.17487 / RFC8305、2017年12月、<https://www.rfc-editor.org/info/ rfc8305>。
[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier", RFC 8422, DOI 10.17487/RFC8422, August 2018, <https://www.rfc-editor.org/info/rfc8422>.
[RFC8422] Nir、Y.、Josefsson、S。、およびM. Pegourie-Gonnard、「トランスポート層セキュリティ（TLS）バージョン1.2以前の楕円曲線暗号（ECC）暗号スイート」、RFC 8422、DOI 10.17487 / RFC8422 2018年8月、<https://www.rfc-editor.org/info/rfc8422>。
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, <https://www.rfc-editor.org/info/rfc8447>.
[RFC8447] Salowey、J。およびS. Turner、「TLSおよびDTLSのIANAレジストリ更新」、RFC 8447、DOI 10.17487 / RFC8447、2018年8月、<https://www.rfc-editor.org/info/rfc8447> 。
[RFC8449] Thomson, M., "Record Size Limit Extension for TLS", RFC 8449, DOI 10.17487/RFC8449, August 2018, <https://www.rfc-editor.org/info/rfc8449>.
[RFC8449] Thomson、M。、「TLSのレコードサイズ制限拡張」、RFC 8449、DOI 10.17487 / RFC8449、2018年8月、<https://www.rfc-editor.org/info/rfc8449>。
[RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the ACM, Vol. 21 No. 2, pp. 120-126, DOI 10.1145/359340.359342, February 1978.
[RSA] Rivest、R.、Shamir、A。、およびL. Adleman、「デジタル署名および公開鍵暗号システムを取得する方法」、ACMの通信、Vol。 21 No. 2、pp。120-126、DOI 10.1145 / 359340.359342、1978年2月。
[SIGMA] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols", Proceedings of CRYPTO 2003, DOI 10.1007/978-3-540-45146-4_24, August 2003.
[SIGMA] Krawczyk、H。、「SIGMA：認証されたDiffie-Hellmanへの「SIGn-and-MAc」アプローチとIKEプロトコルでの使用」、Proceedings of CRYPTO 2003、DOI 10.1007 / 978-3-540-45146- 4_24、2003年8月。
[SLOTH] Bhargavan, K. and G. Leurent, "Transcript Collision Attacks: Breaking Authentication in TLS, IKE, and SSH", Network and Distributed System Security Symposium (NDSS 2016), DOI 10.14722/ndss.2016.23418, February 2016.
[SLOTH] Bhargavan、K.、G。Leurent、「トランスクリプト衝突攻撃：TLS、IKE、およびSSHでの認証の破壊」、ネットワークおよび分散システムセキュリティシンポジウム（NDSS 2016）、DOI 10.14722 / ndss.2016.23418、2016年2月。
[SSL2] Hickman, K., "The SSL Protocol", February 1995.
[SSL2] Hickman、K。、「SSLプロトコル」、1995年2月。
[TIMING] Boneh, D. and D. Brumley, "Remote Timing Attacks Are Practical", USENIX Security Symposium, August 2003.
[タイミング] Boneh、D.、D。Brumley、「リモートタイミング攻撃は実用的」、USENIXセキュリティシンポジウム、2003年8月。
[TLS13-TRACES] Thomson, M., "Example Handshake Traces for TLS 1.3", Work in Progress, draft-ietf-tls-tls13-vectors-06, July 2018.
[TLS13-TRACES] Thomson、M。、「TLS 1.3のハンドシェイクトレースの例」、Work in Progress、draft-ietf-tls-tls13-vectors-06、2018年7月。
[X501] ITU-T, "Information Technology - Open Systems Interconnection - The Directory: Models", ITU-T X.501, October 2016, <https://www.itu.int/rec/T-REC-X.501/en>.
[X501] ITU-T、「情報技術-オープンシステム相互接続-ディレクトリ：モデル」、ITU-T X.501、2016年10月、<https://www.itu.int/rec/T-REC-X。 501 / en>。
This appendix provides a summary of the legal state transitions for the client and server handshakes. State names (in all capitals, e.g., START) have no formal meaning but are provided for ease of comprehension. Actions which are taken only in certain circumstances are indicated in []. The notation "K_{send,recv} = foo" means "set the send/recv key to the given key".
この付録では、クライアントとサーバーのハンドシェイクの正当な状態遷移の概要を示します。 州名（すべての大文字、例えばSTART）には正式な意味はありませんが、理解を容易にするために提供されています。 特定の状況でのみ実行されるアクションは[]に示されています。 「K_{send,recv} = foo」という表記は、「send または recvキーを指定のキーに設定する」ことを意味します。
START <----+
Send ClientHello | | Recv HelloRetryRequest
[K_send = early data] | |
v |
/ WAIT_SH ----+
| | Recv ServerHello
| | K_recv = handshake
Can | V
send | WAIT_EE
early | | Recv EncryptedExtensions
data | +--------+--------+
| Using | | Using certificate
| PSK | v
| | WAIT_CERT_CR
| | Recv | | Recv CertificateRequest
| | Certificate | v
| | | WAIT_CERT
| | | | Recv Certificate
| | v v
| | WAIT_CV
| | | Recv CertificateVerify
| +> WAIT_FINISHED <+
| | Recv Finished
\ | [Send EndOfEarlyData]
| K_send = handshake
| [Send Certificate [+ CertificateVerify]]
Can send | Send Finished
app data --> | K_send = K_recv = application
after here v
CONNECTED
Note that with the transitions as shown above, clients may send alerts that derive from post-ServerHello messages in the clear or with the early data keys. If clients need to send such alerts, they SHOULD first rekey to the handshake keys if possible.
上記の遷移では、クライアントは平文または初期データキーでpost-ServerHelloメッセージから派生したアラートを送信する場合があることに注意してください。 クライアントがそのようなアラートを送信する必要がある場合、可能であれば最初にハンドシェイクキーのキーを再生成する必要があります。
START <-----+
Recv ClientHello | | Send HelloRetryRequest
v |
RECVD_CH ----+
| Select parameters
v
NEGOTIATED
| Send ServerHello
| K_send = handshake
| Send EncryptedExtensions
| [Send CertificateRequest]
Can send | [Send Certificate + CertificateVerify]
app data | Send Finished
after --> | K_send = application
here +--------+--------+
No 0-RTT | | 0-RTT
| |
K_recv = handshake | | K_recv = early data
[Skip decrypt errors] | +------> WAIT_EOED -+
| | Recv | | Recv EndOfEarlyData
| | early data | | K_recv = handshake
| +------------+ |
| |
+> WAIT_FLIGHT2 <--------+
|
+--------+--------+
No auth | | Client auth
| |
| v
| WAIT_CERT
| Recv | | Recv Certificate
| empty | v
| Certificate | WAIT_CV
| | | Recv
| v | CertificateVerify
+-> WAIT_FINISHED <---+
| Recv Finished
| K_recv = application
v
CONNECTED
This appendix provides the normative protocol types and the definitions for constants. Values listed as "_RESERVED" were used in previous versions of TLS and are listed here for completeness. TLS 1.3 implementations MUST NOT send them but might receive them from older TLS implementations.
この付録では、標準のプロトコルタイプと定数の定義を示します。 「_RESERVED」としてリストされている値は、TLSの以前のバージョンで使用されていたもので、完全を期すためにここにリストされています。 TLS 1.3実装はそれらを送信してはなりませんが、古いTLS実装から受信する場合があります。
enum {
invalid(0),
change_cipher_spec(20),
alert(21),
handshake(22),
application_data(23),
heartbeat(24), /* RFC 6520 */
(255)
} ContentType;
struct {
ContentType type;
ProtocolVersion legacy_record_version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
struct {
opaque content[TLSPlaintext.length];
ContentType type;
uint8 zeros[length_of_padding];
} TLSInnerPlaintext;
struct {
ContentType opaque_type = application_data; /* 23 */
ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */
uint16 length;
opaque encrypted_record[TLSCiphertext.length];
} TLSCiphertext;
enum { warning(1), fatal(2), (255) } AlertLevel;
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed_RESERVED(21),
record_overflow(22),
decompression_failure_RESERVED(30),
handshake_failure(40),
no_certificate_RESERVED(41),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
export_restriction_RESERVED(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
inappropriate_fallback(86),
user_canceled(90),
no_renegotiation_RESERVED(100),
missing_extension(109),
unsupported_extension(110),
certificate_unobtainable_RESERVED(111),
unrecognized_name(112),
bad_certificate_status_response(113),
bad_certificate_hash_value_RESERVED(114),
unknown_psk_identity(115),
certificate_required(116),
no_application_protocol(120),
(255)
} AlertDescription;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
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),
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 */
select (Handshake.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;
};
} Handshake;
uint16 ProtocolVersion;
opaque Random[32];
uint8 CipherSuite[2]; /* Cryptographic suite selector */
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id<0..32>;
CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>;
} ClientHello;
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id_echo<0..32>;
CipherSuite cipher_suite;
uint8 legacy_compression_method = 0;
Extension extensions<6..2^16-1>;
} ServerHello; struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
enum {
server_name(0), /* RFC 6066 */
max_fragment_length(1), /* RFC 6066 */
status_request(5), /* RFC 6066 */
supported_groups(10), /* RFC 8422, 7919 */
signature_algorithms(13), /* RFC 8446 */
use_srtp(14), /* RFC 5764 */
heartbeat(15), /* RFC 6520 */
application_layer_protocol_negotiation(16), /* RFC 7301 */
signed_certificate_timestamp(18), /* RFC 6962 */
client_certificate_type(19), /* RFC 7250 */
server_certificate_type(20), /* RFC 7250 */
padding(21), /* RFC 7685 */
RESERVED(40), /* Used but never
assigned */
pre_shared_key(41), /* RFC 8446 */
early_data(42), /* RFC 8446 */
supported_versions(43), /* RFC 8446 */
cookie(44), /* RFC 8446 */
psk_key_exchange_modes(45), /* RFC 8446 */
RESERVED(46), /* Used but never
assigned */
certificate_authorities(47), /* RFC 8446 */
oid_filters(48), /* RFC 8446 */
post_handshake_auth(49), /* RFC 8446 */
signature_algorithms_cert(50), /* RFC 8446 */
key_share(51), /* RFC 8446 */
(65535)
} ExtensionType;
struct {
NamedGroup group;
opaque key_exchange<1..2^16-1>;
} KeyShareEntry;
struct {
KeyShareEntry client_shares<0..2^16-1>;
} KeyShareClientHello;
struct {
NamedGroup selected_group;
} KeyShareHelloRetryRequest; struct {
KeyShareEntry server_share;
} KeyShareServerHello;
struct {
uint8 legacy_form = 4;
opaque X[coordinate_length];
opaque Y[coordinate_length];
} UncompressedPointRepresentation;
enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode;
struct {
PskKeyExchangeMode ke_modes<1..255>;
} PskKeyExchangeModes;
struct {} Empty;
struct {
select (Handshake.msg_type) {
case new_session_ticket: uint32 max_early_data_size;
case client_hello: Empty;
case encrypted_extensions: Empty;
};
} EarlyDataIndication;
struct {
opaque identity<1..2^16-1>;
uint32 obfuscated_ticket_age;
} PskIdentity;
opaque PskBinderEntry<32..255>;
struct {
PskIdentity identities<7..2^16-1>;
PskBinderEntry binders<33..2^16-1>;
} OfferedPsks;
struct {
select (Handshake.msg_type) {
case client_hello: OfferedPsks;
case server_hello: uint16 selected_identity;
};
} PreSharedKeyExtension;
struct {
select (Handshake.msg_type) {
case client_hello:
ProtocolVersion versions<2..254>;
case server_hello: /* and HelloRetryRequest */
ProtocolVersion selected_version;
};
} SupportedVersions;
struct {
opaque cookie<1..2^16-1>;
} Cookie;
enum {
/* RSASSA-PKCS1-v1_5 algorithms */
rsa_pkcs1_sha256(0x0401),
rsa_pkcs1_sha384(0x0501),
rsa_pkcs1_sha512(0x0601),
/* ECDSA algorithms */
ecdsa_secp256r1_sha256(0x0403),
ecdsa_secp384r1_sha384(0x0503),
ecdsa_secp521r1_sha512(0x0603),
/* RSASSA-PSS algorithms with public key OID rsaEncryption */
rsa_pss_rsae_sha256(0x0804),
rsa_pss_rsae_sha384(0x0805),
rsa_pss_rsae_sha512(0x0806),
/* EdDSA algorithms */
ed25519(0x0807),
ed448(0x0808),
/* RSASSA-PSS algorithms with public key OID RSASSA-PSS */
rsa_pss_pss_sha256(0x0809),
rsa_pss_pss_sha384(0x080a),
rsa_pss_pss_sha512(0x080b),
/* Legacy algorithms */
rsa_pkcs1_sha1(0x0201),
ecdsa_sha1(0x0203),
/* Reserved Code Points */
obsolete_RESERVED(0x0000..0x0200),
dsa_sha1_RESERVED(0x0202),
obsolete_RESERVED(0x0204..0x0400),
dsa_sha256_RESERVED(0x0402),
obsolete_RESERVED(0x0404..0x0500),
dsa_sha384_RESERVED(0x0502),
obsolete_RESERVED(0x0504..0x0600),
dsa_sha512_RESERVED(0x0602),
obsolete_RESERVED(0x0604..0x06FF),
private_use(0xFE00..0xFFFF),
(0xFFFF)
} SignatureScheme;
struct {
SignatureScheme supported_signature_algorithms<2..2^16-2>;
} SignatureSchemeList;
enum {
unallocated_RESERVED(0x0000),
/* Elliptic Curve Groups (ECDHE) */
obsolete_RESERVED(0x0001..0x0016),
secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019),
obsolete_RESERVED(0x001A..0x001C),
x25519(0x001D), x448(0x001E),
/* Finite Field Groups (DHE) */
ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102),
ffdhe6144(0x0103), ffdhe8192(0x0104),
/* Reserved Code Points */
ffdhe_private_use(0x01FC..0x01FF),
ecdhe_private_use(0xFE00..0xFEFF),
obsolete_RESERVED(0xFF01..0xFF02),
(0xFFFF)
} NamedGroup;
struct {
NamedGroup named_group_list<2..2^16-1>;
} NamedGroupList;
Values within "obsolete_RESERVED" ranges are used in previous versions of TLS and MUST NOT be offered or negotiated by TLS 1.3 implementations. The obsolete curves have various known/theoretical weaknesses or have had very little usage, in some cases only due to unintentional server configuration issues. They are no longer considered appropriate for general use and should be assumed to be potentially unsafe. The set of curves specified here is sufficient for interoperability with all currently deployed and properly configured TLS implementations.
「obsolete_RESERVED」範囲内の値は、TLSの以前のバージョンで使用され、TLS 1.3実装によって提供またはネゴシエートされてはなりません。 廃止された曲線には、さまざまな既知の/理論的な弱点があるか、意図しないサーバー構成の問題が原因で使用されることがほとんどありません。 それらはもはや一般的な使用に適しているとは考えられておらず、潜在的に安全でないと想定されるべきです。 ここで指定された一連の曲線は、現在展開され、適切に構成されたすべてのTLS実装との相互運用性に十分です。
opaque DistinguishedName<1..2^16-1>;
struct {
DistinguishedName authorities<3..2^16-1>;
} CertificateAuthoritiesExtension;
struct {
opaque certificate_extension_oid<1..2^8-1>;
opaque certificate_extension_values<0..2^16-1>;
} OIDFilter;
struct {
OIDFilter filters<0..2^16-1>;
} OIDFilterExtension;
struct {} PostHandshakeAuth;
struct {
Extension extensions<0..2^16-1>;
} EncryptedExtensions;
struct {
opaque certificate_request_context<0..2^8-1>;
Extension extensions<2..2^16-1>;
} CertificateRequest;
enum {
X509(0),
OpenPGP_RESERVED(1),
RawPublicKey(2),
(255)
} CertificateType;
struct {
select (certificate_type) {
case RawPublicKey:
/* From RFC 7250 ASN.1_subjectPublicKeyInfo */
opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
case X509:
opaque cert_data<1..2^24-1>;
};
Extension extensions<0..2^16-1>;
} CertificateEntry;
struct {
opaque certificate_request_context<0..2^8-1>;
CertificateEntry certificate_list<0..2^24-1>;
} Certificate;
struct {
SignatureScheme algorithm;
opaque signature<0..2^16-1>;
} CertificateVerify;
struct {
opaque verify_data[Hash.length];
} Finished;
struct {
uint32 ticket_lifetime;
uint32 ticket_age_add;
opaque ticket_nonce<0..255>;
opaque ticket<1..2^16-1>;
Extension extensions<0..2^16-2>;
} NewSessionTicket;
struct {} EndOfEarlyData;
enum {
update_not_requested(0), update_requested(1), (255)
} KeyUpdateRequest;
struct {
KeyUpdateRequest request_update;
} KeyUpdate;
A symmetric cipher suite defines the pair of the AEAD algorithm and hash algorithm to be used with HKDF. Cipher suite names follow the naming convention:
対称暗号スイートは、HKDFで使用されるAEADアルゴリズムとハッシュアルゴリズムのペアを定義します。 暗号スイート名は命名規則に従います。
CipherSuite TLS_AEAD_HASH = VALUE;
CipherSuite TLS_AEAD_HASH = VALUE;
+-----------+------------------------------------------------+
| Component | Contents |
+-----------+------------------------------------------------+
| TLS | The string "TLS" |
| | |
| AEAD | The AEAD algorithm used for record protection |
| | |
| HASH | The hash algorithm used with HKDF |
| | |
| VALUE | The two-byte ID assigned for this cipher suite |
+-----------+------------------------------------------------+
This specification defines the following cipher suites for use with TLS 1.3.
この仕様では、TLS 1.3で使用する次の暗号スイートを定義しています。
+------------------------------+-------------+
| Description | Value |
+------------------------------+-------------+
| TLS_AES_128_GCM_SHA256 | {0x13,0x01} |
| | |
| TLS_AES_256_GCM_SHA384 | {0x13,0x02} |
| | |
| TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
| | |
| TLS_AES_128_CCM_SHA256 | {0x13,0x04} |
| | |
| TLS_AES_128_CCM_8_SHA256 | {0x13,0x05} |
+------------------------------+-------------+
The corresponding AEAD algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_AES_128_CCM are defined in [RFC5116]. AEAD_CHACHA20_POLY1305 is defined in [RFC8439]. AEAD_AES_128_CCM_8 is defined in [RFC6655]. The corresponding hash algorithms are defined in [SHS].
対応するAEADアルゴリズムAEAD_AES_128_GCM、AEAD_AES_256_GCM、およびAEAD_AES_128_CCMは、[RFC5116]で定義されています。 AEAD_CHACHA20_POLY1305は[RFC8439]で定義されています。 AEAD_AES_128_CCM_8は[RFC6655]で定義されています。 対応するハッシュアルゴリズムは[SHS]で定義されています。
Although TLS 1.3 uses the same cipher suite space as previous versions of TLS, TLS 1.3 cipher suites are defined differently, only specifying the symmetric ciphers, and cannot be used for TLS 1.2. Similarly, cipher suites for TLS 1.2 and lower cannot be used with TLS 1.3.
TLS 1.3は以前のバージョンのTLSと同じ暗号スイートスペースを使用しますが、TLS 1.3暗号スイートの定義は異なり、対称暗号のみを指定し、TLS 1.2には使用できません。 同様に、TLS 1.2以前の暗号スイートはTLS 1.3では使用できません。
New cipher suite values are assigned by IANA as described in Section 11.
セクション11で説明されているように、新しい暗号スイート値はIANAによって割り当てられます。
The TLS protocol cannot prevent many common security mistakes. This appendix provides several recommendations to assist implementors. [TLS13-TRACES] provides test vectors for TLS 1.3 handshakes.
TLSプロトコルは、多くの一般的なセキュリティの間違いを防ぐことはできません。 この付録では、実装者を支援するためのいくつかの推奨事項を示します。 [TLS13-TRACES]は、TLS 1.3ハンドシェイクのテストベクトルを提供します。
TLS requires a cryptographically secure pseudorandom number generator (CSPRNG). In most cases, the operating system provides an appropriate facility such as /dev/urandom, which should be used absent other (e.g., performance) concerns. It is RECOMMENDED to use an existing CSPRNG implementation in preference to crafting a new one. Many adequate cryptographic libraries are already available under favorable license terms. Should those prove unsatisfactory, [RFC4086] provides guidance on the generation of random values.
TLSには、暗号で保護された疑似乱数ジェネレーター（CSPRNG）が必要です。 ほとんどの場合、オペレーティングシステムは/ dev / urandomなどの適切な機能を提供します。これは、他の（パフォーマンスなど）懸念事項がない場合に使用する必要があります。 新しい実装を作成するよりも、既存のCSPRNG実装を使用することをお勧めします。 多くの適切な暗号化ライブラリは、有利なライセンス条件の下ですでに利用可能です。 それらが不十分であると判明した場合、[RFC4086]はランダム値の生成に関するガイダンスを提供します。
TLS uses random values (1) in public protocol fields such as the public Random values in the ClientHello and ServerHello and (2) to generate keying material. With a properly functioning CSPRNG, this does not present a security problem, as it is not feasible to determine the CSPRNG state from its output. However, with a broken CSPRNG, it may be possible for an attacker to use the public output to determine the CSPRNG internal state and thereby predict the keying material, as documented in [CHECKOWAY]. Implementations can provide extra security against this form of attack by using separate CSPRNGs to generate public and private values.
TLSは、（1）ClientHelloおよびServerHelloのパブリックランダム値などのパブリックプロトコルフィールドでランダム値を使用し、（2）キー情報を生成します。 CSPRNGが適切に機能していれば、出力からCSPRNGの状態を判断することは不可能であるため、セキュリティの問題は発生しません。 ただし、CSPRNGが破損している場合、[CHECKOWAY]で文書化されているように、攻撃者がパブリック出力を使用してCSPRNGの内部状態を判断し、それによってキー情報を予測できる可能性があります。 実装では、個別のCSPRNGを使用してパブリック値とプライベート値を生成することにより、この形式の攻撃に対する追加のセキュリティを提供できます。
Implementations are responsible for verifying the integrity of certificates and should generally support certificate revocation messages. Absent a specific indication from an application profile, certificates should always be verified to ensure proper signing by a trusted certificate authority (CA). The selection and addition of trust anchors should be done very carefully. Users should be able to view information about the certificate and trust anchor. Applications SHOULD also enforce minimum and maximum key sizes. For example, certification paths containing keys or signatures weaker than 2048-bit RSA or 224-bit ECDSA are not appropriate for secure applications.
実装は証明書の整合性を検証する責任があり、一般に証明書失効メッセージをサポートする必要があります。 アプリケーションプロファイルから特定の指示がない場合、証明書は常に検証され、信頼できる認証局（CA）による適切な署名が保証されます。 トラストアンカーの選択と追加は、非常に慎重に行う必要があります。 ユーザーは、証明書とトラストアンカーに関する情報を表示できる必要があります。 アプリケーションは、キーの最小サイズと最大サイズも強制する必要があります。 たとえば、2048ビットRSAまたは224ビットECDSAよりも弱いキーまたは署名を含む証明書パスは、安全なアプリケーションには適していません。
Implementation experience has shown that certain parts of earlier TLS specifications are not easy to understand and have been a source of interoperability and security problems. Many of these areas have been clarified in this document, but this appendix contains a short list of the most important things that require special attention from implementors.
実装の経験から、以前のTLS仕様の特定の部分は理解が容易ではなく、相互運用性とセキュリティの問題の原因であることが示されています。 これらの領域の多くはこのドキュメントで明確にされていますが、この付録には、実装者からの特別な注意が必要な最も重要なものの短いリストが含まれています。
TLS protocol issues:
TLSプロトコルの問題：
- Do you correctly handle handshake messages that are fragmented to multiple TLS records (see Section 5.1)? Do you correctly handle corner cases like a ClientHello that is split into several small fragments? Do you fragment handshake messages that exceed the maximum fragment size? In particular, the Certificate and CertificateRequest handshake messages can be large enough to require fragmentation.
- 複数のTLSレコードに断片化されたハンドシェイクメッセージを正しく処理していますか（セクション5.1を参照）。 いくつかの小さなフラグメントに分割されるClientHelloのようなコーナーケースを正しく処理しますか？ 最大フラグメントサイズを超えるハンドシェイクメッセージをフラグメント化しますか？ 特に、CertificateおよびCertificateRequestハンドシェイクメッセージは、断片化を必要とするほど大きくなる可能性があります。
- Do you ignore the TLS record layer version number in all unencrypted TLS records (see Appendix D)?
- 暗号化されていないすべてのTLSレコードのTLSレコードレイヤーバージョン番号を無視しますか（付録Dを参照）。
- Have you ensured that all support for SSL, RC4, EXPORT ciphers, and MD5 (via the "signature_algorithms" extension) is completely removed from all possible configurations that support TLS 1.3 or later, and that attempts to use these obsolete capabilities fail correctly (see Appendix D)?
- SSL、RC4、EXPORT暗号、およびMD5（「signature_algorithms」拡張機能を介した）のすべてのサポートが、TLS 1.3以降をサポートするすべての可能な構成から完全に削除され、これらの廃止された機能を使用しようとしても失敗することを確認しましたか（ 付録Dを参照）？
- Do you handle TLS extensions in ClientHellos correctly, including unknown extensions?
- ClientHellosで、未知の拡張子を含むTLS拡張を正しく処理しますか？
- When the server has requested a client certificate but no suitable certificate is available, do you correctly send an empty Certificate message, instead of omitting the whole message (see Section 4.4.2)?
- サーバーがクライアント証明書を要求したが、適切な証明書が利用できない場合、メッセージ全体を省略するのではなく、空の証明書メッセージを正しく送信しますか（セクション4.4.2を参照）？
- When processing the plaintext fragment produced by AEAD-Decrypt and scanning from the end for the ContentType, do you avoid scanning past the start of the cleartext in the event that the peer has sent a malformed plaintext of all zeros?
- AEAD-Decryptによって生成された暗号化されていないフラグメントを処理し、ContentTypeの末尾からスキャンするとき、ピアがすべてゼロの不正なプレーンテキストを送信した場合にクリアテキストの先頭を過ぎてスキャンすることを避けますか？
- Do you properly ignore unrecognized cipher suites (Section 4.1.2), hello extensions (Section 4.2), named groups (Section 4.2.7), key shares (Section 4.2.8), supported versions (Section 4.2.1), and signature algorithms (Section 4.2.3) in the ClientHello?
- 認識されない暗号スイート（セクション4.1.2）、hello拡張（セクション4.2）、名前付きグループ（セクション4.2.7）、キー共有（セクション4.2.8）、サポートされているバージョン（セクション4.2.1）、および ClientHelloの署名アルゴリズム（セクション4.2.3）を適切に無視していますか？
- As a server, do you send a HelloRetryRequest to clients which support a compatible (EC)DHE group but do not predict it in the "key_share" extension? As a client, do you correctly handle a HelloRetryRequest from the server?
- サーバーとして、互換性のある（EC）DHEグループをサポートするが「key_share」拡張で予測しないクライアントにHelloRetryRequestを送信しますか？ クライアントとして、サーバーからのHelloRetryRequestを正しく処理しますか？
Cryptographic details:
暗号の詳細：
- What countermeasures do you use to prevent timing attacks [TIMING]?
- タイミング攻撃を防ぐためにどのような対策を講じていますか[タイミング]。
- When using Diffie-Hellman key exchange, do you correctly preserve leading zero bytes in the negotiated key (see Section 7.4.1)?
- Diffie-Hellmanキー交換を使用する場合、ネゴシエートされたキーの先行ゼロバイトを正しく保存しますか（セクション7.4.1を参照）？
- Does your TLS client check that the Diffie-Hellman parameters sent by the server are acceptable (see Section 4.2.8.1)?
- TLSクライアントは、サーバーから送信されたDiffie-Hellmanパラメーターが受け入れ可能であることを確認していますか（セクション4.2.8.1を参照）。
- Do you use a strong and, most importantly, properly seeded random number generator (see Appendix C.1) when generating Diffie-Hellman private values, the ECDSA "k" parameter, and other security-critical values? It is RECOMMENDED that implementations implement "deterministic ECDSA" as specified in [RFC6979].
- Diffie-Hellmanプライベート値、ECDSA「k」パラメータ、およびその他のセキュリティクリティカルな値を生成するときに、強力で、最も重要な適切にシードされた乱数ジェネレーター（付録C.1を参照）を使用しますか？ [RFC6979]で指定されているように、実装が「決定論的ECDSA」を実装することが推奨されます。
- Do you zero-pad Diffie-Hellman public key values and shared secrets to the group size (see Section 4.2.8.1 and Section 7.4.1)?
- Diffie-Hellman公開キー値と共有シークレットをグループサイズにゼロパッドしますか（セクション4.2.8.1およびセクション7.4.1を参照）。
- Do you verify signatures after making them, to protect against RSA-CRT key leaks [FW15]?
- RSA-CRT鍵漏洩[FW15]から保護するために、署名後に署名を検証していますか？
Clients SHOULD NOT reuse a ticket for multiple connections. Reuse of a ticket allows passive observers to correlate different connections. Servers that issue tickets SHOULD offer at least as many tickets as the number of connections that a client might use; for example, a web browser using HTTP/1.1 [RFC7230] might open six connections to a server. Servers SHOULD issue new tickets with every connection. This ensures that clients are always able to use a new ticket when creating a new connection.
クライアントは、複数の接続にチケットを再利用するべきではありません。 チケットを再利用すると、パッシブオブザーバーは異なる接続を相互に関連付けることができます。 チケットを発行するサーバーは、クライアントが使用する可能性がある接続の数と少なくとも同じ数のチケットを提供する必要があります。 たとえば、HTTP / 1.1 [RFC7230]を使用するWebブラウザは、サーバーへの6つの接続を開く場合があります。 サーバーは、すべての接続で新しいチケットを発行する必要があります。 これにより、クライアントは新しい接続を作成するときに常に新しいチケットを使用できるようになります。
Previous versions of TLS offered explicitly unauthenticated cipher suites based on anonymous Diffie-Hellman. These modes have been deprecated in TLS 1.3. However, it is still possible to negotiate parameters that do not provide verifiable server authentication by several methods, including:
TLSの以前のバージョンは、匿名のDiffie-Hellmanに基づいて明示的に認証されていない暗号スイートを提供していました。 これらのモードはTLS 1.3で非推奨になりました。 ただし、次のようないくつかの方法で、検証可能なサーバー認証を提供しないパラメーターをネゴシエートすることは依然として可能です。
- Raw public keys [RFC7250].
- 生の公開鍵[RFC7250]。
- Using a public key contained in a certificate but without validation of the certificate chain or any of its contents.
- 証明書に含まれる公開鍵を使用しますが、証明書チェーンまたはその内容の検証は行いません。
Either technique used alone is vulnerable to man-in-the-middle attacks and therefore unsafe for general use. However, it is also possible to bind such connections to an external authentication mechanism via out-of-band validation of the server's public key, trust on first use, or a mechanism such as channel bindings (though the channel bindings described in [RFC5929] are not defined for TLS 1.3). If no such mechanism is used, then the connection has no protection against active man-in-the-middle attack; applications MUST NOT use TLS in such a way absent explicit configuration or a specific application profile.
単独で使用されるいずれの手法も、中間者攻撃に対して脆弱であるため、一般的な使用には安全ではありません。 ただし、サーバーの公開キーの帯域外検証、最初の使用時の信頼、またはチャネルバインディングなどのメカニズムを介して、そのような接続を外部認証メカニズムにバインドすることもできます（ただし、[RFC5929] TLS 1.3には定義されていません。 そのようなメカニズムが使用されていない場合、接続はアクティブな中間者攻撃から保護されません。 アプリケーションは、明示的な構成や特定のアプリケーションプロファイルがない場合に、TLSを使用しないでください。
The TLS protocol provides a built-in mechanism for version negotiation between endpoints potentially supporting different versions of TLS.
TLSプロトコルは、異なるバージョンのTLSを潜在的にサポートするエンドポイント間のバージョンネゴシエーションのための組み込みメカニズムを提供します。
TLS 1.x and SSL 3.0 use compatible ClientHello messages. Servers can also handle clients trying to use future versions of TLS as long as the ClientHello format remains compatible and there is at least one protocol version supported by both the client and the server.
TLS 1.xおよびSSL 3.0は、互換性のあるClientHelloメッセージを使用します。 サーバーは、ClientHello形式の互換性が維持され、クライアントとサーバーの両方で少なくとも1つのプロトコルバージョンがサポートされている限り、TLSの将来のバージョンを使用しようとするクライアントも処理できます。
Prior versions of TLS used the record layer version number (TLSPlaintext.legacy_record_version and TLSCiphertext.legacy_record_version) for various purposes. As of TLS 1.3, this field is deprecated. The value of TLSPlaintext.legacy_record_version MUST be ignored by all implementations. The value of TLSCiphertext.legacy_record_version is included in the additional data for deprotection but MAY otherwise be ignored or MAY be validated to match the fixed constant value. Version negotiation is performed using only the handshake versions (ClientHello.legacy_version and ServerHello.legacy_version, as well as the ClientHello, HelloRetryRequest, and ServerHello "supported_versions" extensions). In order to maximize interoperability with older endpoints, implementations that negotiate the use of TLS 1.0-1.2 SHOULD set the record layer version number to the negotiated version for the ServerHello and all records thereafter.
TLSの以前のバージョンでは、さまざまな目的でレコードレイヤーバージョン番号（TLSPlaintext.legacy_record_versionおよびTLSCiphertext.legacy_record_version）が使用されていました。 TLS 1.3以降、このフィールドは廃止されました。 TLSPlaintext.legacy_record_versionの値は、すべての実装で無視されなければなりません。 TLSCiphertext.legacy_record_versionの値は、保護解除のための追加データに含まれますが、それ以外の場合は無視されるか、固定定数値と一致するように検証される場合があります。 バージョンネゴシエーションは、ハンドシェイクバージョン（ClientHello.legacy_versionおよびServerHello.legacy_version、およびClientHello、HelloRetryRequest、およびServerHelloの「supported_versions」拡張機能）のみを使用して実行されます。 古いエンドポイントとの相互運用性を最大化するために、TLS 1.0-1.2の使用をネゴシエートする実装は、ServerHelloおよびその後のすべてのレコードのネゴシエートされたバージョンにレコード層バージョン番号を設定する必要があります。
For maximum compatibility with previously non-standard behavior and misconfigured deployments, all implementations SHOULD support validation of certification paths based on the expectations in this document, even when handling prior TLS versions' handshakes (see Section 4.4.2.2).
以前の非標準の動作と誤って構成された展開との最大の互換性のために、以前のTLSバージョンのハンドシェイクを処理する場合でも、すべての実装は、このドキュメントの期待に基づいて証明書パスの検証をサポートする必要があります（セクション4.4.2.2を参照）。
TLS 1.2 and prior supported an "Extended Master Secret" [RFC7627] extension which digested large parts of the handshake transcript into the master secret. Because TLS 1.3 always hashes in the transcript up to the server Finished, implementations which support both TLS 1.3 and earlier versions SHOULD indicate the use of the Extended Master Secret extension in their APIs whenever TLS 1.3 is used.
TLS 1.2以前では、ハンドシェイクのトランスクリプトの大部分をマスターシークレットにダイジェストする「Extended Master Secret」[RFC7627]エクステンションがサポートされていました。 TLS 1.3は常に終了するサーバーまでトランスクリプトでハッシュするため、TLS 1.3とそれ以前のバージョンの両方をサポートする実装は、TLS 1.3が使用されるたびにAPIで拡張マスターシークレット拡張を使用する必要があります。
A TLS 1.3 client who wishes to negotiate with servers that do not support TLS 1.3 will send a normal TLS 1.3 ClientHello containing 0x0303 (TLS 1.2) in ClientHello.legacy_version but with the correct version(s) in the "supported_versions" extension. If the server does not support TLS 1.3, it will respond with a ServerHello containing an older version number. If the client agrees to use this version, the negotiation will proceed as appropriate for the negotiated protocol. A client using a ticket for resumption SHOULD initiate the connection using the version that was previously negotiated.
TLS 1.3をサポートしないサーバーとネゴシエートしたいTLS 1.3クライアントは、ClientHello.legacy_versionに0x0303（TLS 1.2）を含むが、「supported_versions」拡張子に正しいバージョンを含む通常のTLS 1.3 ClientHelloを送信します。 サーバーがTLS 1.3をサポートしていない場合、古いバージョン番号を含むServerHelloで応答します。 クライアントがこのバージョンの使用に同意した場合、ネゴシエートされたプロトコルに応じてネゴシエーションが適切に進行します。 再開にチケットを使用するクライアントは、以前にネゴシエートされたバージョンを使用して接続を開始する必要があります。
Note that 0-RTT data is not compatible with older servers and SHOULD NOT be sent absent knowledge that the server supports TLS 1.3. See Appendix D.3.
0-RTTデータは古いサーバーと互換性がないため、サーバーがTLS 1.3をサポートしているという知識がない場合は送信しないでください。 付録D.3を参照してください。
If the version chosen by the server is not supported by the client (or is not acceptable), the client MUST abort the handshake with a "protocol_version" alert.
サーバーが選択したバージョンがクライアントでサポートされていない（または受け入れられない）場合、クライアントは「protocol_version」アラートでハンドシェイクを中止する必要があります。
Some legacy server implementations are known to not implement the TLS specification properly and might abort connections upon encountering TLS extensions or versions which they are not aware of. Interoperability with buggy servers is a complex topic beyond the scope of this document. Multiple connection attempts may be required in order to negotiate a backward-compatible connection; however, this practice is vulnerable to downgrade attacks and is NOT RECOMMENDED.
レガシーサーバーの実装によっては、TLS仕様を適切に実装しないことが知られており、TLS拡張機能や認識していないバージョンが検出されると接続を中断する場合があります。 バギーサーバーとの相互運用性は、このドキュメントの範囲を超える複雑なトピックです。 下位互換性のある接続をネゴシエートするには、複数の接続試行が必要になる場合があります。 ただし、この方法はダウングレード攻撃に対して脆弱であり、推奨されません。
A TLS server can also receive a ClientHello indicating a version number smaller than its highest supported version. If the "supported_versions" extension is present, the server MUST negotiate using that extension as described in Section 4.2.1. If the "supported_versions" extension is not present, the server MUST negotiate the minimum of ClientHello.legacy_version and TLS 1.2. For example, if the server supports TLS 1.0, 1.1, and 1.2, and legacy_version is TLS 1.0, the server will proceed with a TLS 1.0 ServerHello. If the "supported_versions" extension is absent and the server only supports versions greater than ClientHello.legacy_version, the server MUST abort the handshake with a "protocol_version" alert.
TLSサーバーは、サポートされている最高バージョンよりも小さいバージョン番号を示すClientHelloも受信できます。 「supported_versions」拡張が存在する場合、サーバーはセクション4.2.1で説明されているようにその拡張を使用してネゴシエートしなければなりません。 「supported_versions」拡張機能が存在しない場合、サーバーはClientHello.legacy_versionおよびTLS 1.2の最小値をネゴシエートしなければなりません。 たとえば、サーバーがTLS 1.0、1.1、および1.2をサポートし、legacy_versionがTLS 1.0である場合、サーバーはTLS 1.0 ServerHelloを続行します。 「supported_versions」拡張機能がなく、サーバーがClientHello.legacy_versionよりも大きいバージョンのみをサポートする場合、サーバーは「protocol_version」アラートでハンドシェイクを中止する必要があります。
Note that earlier versions of TLS did not clearly specify the record layer version number value in all cases (TLSPlaintext.legacy_record_version). Servers will receive various TLS 1.x versions in this field, but its value MUST always be ignored.
TLSの以前のバージョンでは、すべてのケースでレコード層のバージョン番号の値が明確に指定されていなかったことに注意してください（TLSPlaintext.legacy_record_version）。 サーバーはこのフィールドでさまざまなTLS 1.xバージョンを受け取りますが、その値は常に無視されなければなりません。
0-RTT data is not compatible with older servers. An older server will respond to the ClientHello with an older ServerHello, but it will not correctly skip the 0-RTT data and will fail to complete the handshake. This can cause issues when a client attempts to use 0-RTT, particularly against multi-server deployments. For example, a deployment could deploy TLS 1.3 gradually with some servers implementing TLS 1.3 and some implementing TLS 1.2, or a TLS 1.3 deployment could be downgraded to TLS 1.2.
0-RTTデータは古いサーバーと互換性がありません。 古いサーバーは古いServerHelloでClientHelloに応答しますが、0-RTTデータを正しくスキップせず、ハンドシェイクを完了できません。 これは、クライアントが0-RTTを使用しようとしたときに、特にマルチサーバー展開に対して問題を引き起こす可能性があります。 たとえば、一部のサーバーでTLS 1.3を実装し、一部のサーバーでTLS 1.2を実装して、展開でTLS 1.3を徐々に展開したり、TLS 1.3展開をTLS 1.2にダウングレードしたりできます。
A client that attempts to send 0-RTT data MUST fail a connection if it receives a ServerHello with TLS 1.2 or older. It can then retry the connection with 0-RTT disabled. To avoid a downgrade attack, the client SHOULD NOT disable TLS 1.3, only 0-RTT.
0-RTTデータを送信しようとするクライアントは、TLS 1.2以前のServerHelloを受信した場合、接続に失敗する必要があります。 その後、0-RTTを無効にして接続を再試行できます。 ダウングレード攻撃を避けるために、クライアントはTLS 1.3を無効にするべきではなく、0-RTTのみを無効にする必要があります。
To avoid this error condition, multi-server deployments SHOULD ensure a uniform and stable deployment of TLS 1.3 without 0-RTT prior to enabling 0-RTT.
このエラー状態を回避するために、マルチサーバー展開では、0-RTTを有効にする前に、0-RTTを使用せずにTLS 1.3を均一かつ安定して展開する必要があります。
Field measurements [Ben17a] [Ben17b] [Res17a] [Res17b] have found that a significant number of middleboxes misbehave when a TLS client/server pair negotiates TLS 1.3. Implementations can increase the chance of making connections through those middleboxes by making the TLS 1.3 handshake look more like a TLS 1.2 handshake:
フィールド測定[Ben17a] [Ben17b] [Res17a] [Res17b]は、TLSクライアント/サーバーペアがTLS 1.3をネゴシエートするとき、かなりの数のミドルボックスが誤動作することを発見しました。 実装では、TLS 1.3ハンドシェイクをTLS 1.2ハンドシェイクのように見せることにより、これらのミドルボックスを介して接続を確立する機会を増やすことができます。
- The client always provides a non-empty session ID in the ClientHello, as described in the legacy_session_id section of Section 4.1.2.
- セクション4.1.2のlegacy_session_idセクションで説明されているように、クライアントは常にClientHelloで空でないセッションIDを提供します。
- If not offering early data, the client sends a dummy change_cipher_spec record (see the third paragraph of Section 5) immediately before its second flight. This may either be before its second ClientHello or before its encrypted handshake flight. If offering early data, the record is placed immediately after the first ClientHello.
- 初期データを提供しない場合、クライアントは2回目のフライトの直前にダミーのchange_cipher_specレコード（セクション5の3番目の段落を参照）を送信します。 これは、2番目のClientHelloの前、または暗号化されたハンドシェイクフライトの前のいずれかです。 初期データを提供する場合、レコードは最初のClientHelloの直後に配置されます。
- The server sends a dummy change_cipher_spec record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest.
- サーバーは、最初のハンドシェイクメッセージの直後にダミーのchange_cipher_specレコードを送信します。 これは、ServerHelloまたはHelloRetryRequestの後になります。
When put together, these changes make the TLS 1.3 handshake resemble TLS 1.2 session resumption, which improves the chance of successfully connecting through middleboxes. This "compatibility mode" is partially negotiated: the client can opt to provide a session ID or not, and the server has to echo it. Either side can send change_cipher_spec at any time during the handshake, as they must be ignored by the peer, but if the client sends a non-empty session ID, the server MUST send the change_cipher_spec as described in this appendix.
これらの変更により、TLS 1.3ハンドシェイクがTLS 1.2セッションの再開に似たものになり、ミドルボックスを介して正常に接続できる可能性が向上します。 この「互換モード」は部分的にネゴシエートされます。クライアントはセッションIDを提供するかどうかを選択でき、サーバーはそれをエコーする必要があります。 ピアは無視する必要があるため、どちらの側もハンドシェイク中にchange_cipher_specをいつでも送信できますが、クライアントが空でないセッションIDを送信する場合、サーバーはこの付録で説明するようにchange_cipher_specを送信する必要があります。
Implementations negotiating the use of older versions of TLS SHOULD prefer forward secret and AEAD cipher suites, when available.
TLSの古いバージョンの使用をネゴシエートする実装は、利用可能な場合、フォワードシークレットおよびAEAD暗号スイートを優先する必要があります。
The security of RC4 cipher suites is considered insufficient for the reasons cited in [RFC7465]. Implementations MUST NOT offer or negotiate RC4 cipher suites for any version of TLS for any reason.
RC4暗号スイートのセキュリティは、[RFC7465]に引用されている理由により不十分であると考えられています。 実装は、何らかの理由でTLSの任意のバージョンのRC4暗号スイートを提供またはネゴシエートしてはなりません。
Old versions of TLS permitted the use of very low strength ciphers. Ciphers with a strength less than 112 bits MUST NOT be offered or negotiated for any version of TLS for any reason.
TLSの古いバージョンでは、非常に低い強度の暗号を使用できました。 112ビット未満の強度の暗号は、何らかの理由でTLSのどのバージョンでも提供またはネゴシエートしてはなりません。
The security of SSL 3.0 [RFC6101] is considered insufficient for the reasons enumerated in [RFC7568], and it MUST NOT be negotiated for any reason.
SSL 3.0 [RFC6101]のセキュリティは、[RFC7568]に列挙された理由により不十分であると見なされ、何らかの理由で交渉してはなりません。
The security of SSL 2.0 [SSL2] is considered insufficient for the reasons enumerated in [RFC6176], and it MUST NOT be negotiated for any reason.
SSL 2.0 [SSL2]のセキュリティは、[RFC6176]に列挙されている理由により不十分であると考えられ、何らかの理由で交渉してはなりません。
Implementations MUST NOT send an SSL version 2.0 compatible CLIENT-HELLO. Implementations MUST NOT negotiate TLS 1.3 or later using an SSL version 2.0 compatible CLIENT-HELLO. Implementations are NOT RECOMMENDED to accept an SSL version 2.0 compatible CLIENT-HELLO in order to negotiate older versions of TLS.
実装は、SSLバージョン2.0互換のCLIENT-HELLOを送信してはなりません。 実装は、SSLバージョン2.0互換のCLIENT-HELLOを使用してTLS 1.3以降をネゴシエートしてはなりません。 古いバージョンのTLSをネゴシエートするために、SSLバージョン2.0互換のCLIENT-HELLOを受け入れることは推奨されません。
Implementations MUST NOT send a ClientHello.legacy_version or ServerHello.legacy_version set to 0x0300 or less. Any endpoint receiving a Hello message with ClientHello.legacy_version or ServerHello.legacy_version set to 0x0300 MUST abort the handshake with a "protocol_version" alert.
実装は、0x0300以下に設定されたClientHello.legacy_versionまたはServerHello.legacy_versionを送信してはなりません。 ClientHello.legacy_versionまたはServerHello.legacy_versionが0x0300に設定されたHelloメッセージを受信するエンドポイントは、「protocol_version」アラートでハンドシェイクを中止する必要があります。
Implementations MUST NOT send any records with a version less than 0x0300. Implementations SHOULD NOT accept any records with a version less than 0x0300 (but may inadvertently do so if the record version number is ignored completely).
実装は、0x0300未満のバージョンのレコードを送信してはなりません。 実装は、0x0300未満のバージョンのレコードを受け入れるべきではありません（ただし、レコードのバージョン番号が完全に無視された場合、誤って受け入れる可能性があります）。
Implementations MUST NOT use the Truncated HMAC extension, defined in Section 7 of [RFC6066], as it is not applicable to AEAD algorithms and has been shown to be insecure in some scenarios.
実装は[RFC6066]のセクション7で定義されているTruncated HMAC拡張を使用してはなりません。これはAEADアルゴリズムには適用されず、一部のシナリオでは安全でないことが示されているためです。
A complete security analysis of TLS is outside the scope of this document. In this appendix, we provide an informal description of the desired properties as well as references to more detailed work in the research literature which provides more formal definitions.
TLSの完全なセキュリティ分析は、このドキュメントの範囲外です。 この付録では、目的のプロパティの非公式の説明と、より正式な定義を提供する研究文献のより詳細な作業への参照を提供します。
We cover properties of the handshake separately from those of the record layer.
ハンドシェイクのプロパティについては、レコードレイヤーのプロパティとは別に説明します。
The TLS handshake is an Authenticated Key Exchange (AKE) protocol which is intended to provide both one-way authenticated (server-only) and mutually authenticated (client and server) functionality. At the completion of the handshake, each side outputs its view of the following values:
TLSハンドシェイクは、認証鍵交換（AKE）プロトコルであり、一方向認証（サーバーのみ）と相互認証（クライアントとサーバー）の両方の機能を提供することを目的としています。 ハンドシェイクの完了時に、各サイドは次の値のビューを出力します。
- A set of "session keys" (the various secrets derived from the master secret) from which can be derived a set of working keys.
- 一連の作業キーを派生できる「セッションキー」（マスターシークレットから派生したさまざまなシークレット）のセット。
- A set of cryptographic parameters (algorithms, etc.).
- 暗号化パラメーターのセット（アルゴリズムなど）。
- The identities of the communicating parties.
- 通信相手の身元。
We assume the attacker to be an active network attacker, which means it has complete control over the network used to communicate between the parties [RFC3552]. Even under these conditions, the handshake should provide the properties listed below. Note that these properties are not necessarily independent, but reflect the protocol consumers' needs.
攻撃者はアクティブなネットワーク攻撃者であると想定します。つまり、当事者間の通信に使用されるネットワークを完全に制御できます[RFC3552]。 これらの条件下でも、ハンドシェイクは以下のプロパティを提供する必要があります。 これらのプロパティは必ずしも独立しているわけではありませんが、プロトコルコンシューマのニーズを反映していることに注意してください。
Establishing the same session keys: The handshake needs to output the same set of session keys on both sides of the handshake, provided that it completes successfully on each endpoint (see [CK01], Definition 1, part 1).
同じセッションキーの確立：各エンドポイントで正常に完了する場合、ハンドシェイクはハンドシェイクの両側で同じセッションキーのセットを出力する必要があります（[CK01]、定義1、パート1を参照）。
Secrecy of the session keys: The shared session keys should be known only to the communicating parties and not to the attacker (see [CK01], Definition 1, part 2). Note that in a unilaterally authenticated connection, the attacker can establish its own session keys with the server, but those session keys are distinct from those established by the client.
セッションキーの機密性：共有セッションキーは、攻撃者ではなく通信側のみに知られる必要があります（[CK01]、定義1、パート2を参照）。 一方的に認証された接続では、攻撃者はサーバーとの独自のセッションキーを確立できますが、これらのセッションキーはクライアントが確立したものとは異なります。
Peer authentication: The client's view of the peer identity should reflect the server's identity. If the client is authenticated, the server's view of the peer identity should match the client's identity.
ピア認証：ピアIDのクライアントのビューは、サーバーのIDを反映する必要があります。 クライアントが認証される場合、ピアIDのサーバーのビューはクライアントのIDと一致する必要があります。
Uniqueness of the session keys: Any two distinct handshakes should produce distinct, unrelated session keys. Individual session keys produced by a handshake should also be distinct and independent.
セッションキーの一意性：2つの異なるハンドシェイクは、無関係の無関係なセッションキーを生成する必要があります。 ハンドシェイクによって生成される個々のセッションキーも明確で独立している必要があります。
Downgrade protection: The cryptographic parameters should be the same on both sides and should be the same as if the peers had been communicating in the absence of an attack (see [BBFGKZ16], Definitions 8 and 9).
ダウングレード保護：暗号化パラメーターは両側で同じであり、攻撃がない場合にピアが通信していた場合と同じである必要があります（[BBFGKZ16]、定義8および9を参照）。
Forward secret with respect to long-term keys: If the long-term keying material (in this case the signature keys in certificate-based authentication modes or the external/resumption PSK in PSK with (EC)DHE modes) is compromised after the handshake is complete, this does not compromise the security of the session key (see [DOW92]), as long as the session key itself has been erased. The forward secrecy property is not satisfied when PSK is used in the "psk_ke" PskKeyExchangeMode.
長期キーに関するフォワードシークレット：ハンドシェイク後に長期キー情報（この場合、証明書ベースの認証モードの署名キーまたはPSKの（EC）DHEモードの外部/再開PSK）が危険にさらされた場合 セッションキー自体が消去されている限り、これはセッションキーのセキュリティを侵害しません（[DOW92]を参照）。 PSKが "psk_ke" PskKeyExchangeModeで使用されている場合、forward secrecyプロパティは満たされません。
Key Compromise Impersonation (KCI) resistance: In a mutually authenticated connection with certificates, compromising the long-term secret of one actor should not break that actor's authentication of their peer in the given connection (see [HGFS15]). For example, if a client's signature key is compromised, it should not be possible to impersonate arbitrary servers to that client in subsequent handshakes.
鍵侵害偽装（KCI）耐性：証明書を使用した相互認証接続では、1人のアクターの長期的な秘密を侵害しても、特定の接続におけるピアのそのアクターの認証が破られることはありません（[HGFS15]を参照）。 たとえば、クライアントの署名キーが侵害された場合、後続のハンドシェイクでそのクライアントに任意のサーバーを偽装することはできません。
Protection of endpoint identities: The server's identity (certificate) should be protected against passive attackers. The client's identity should be protected against both passive and active attackers.
エンドポイントIDの保護：サーバーのID（証明書）は、受動的な攻撃者から保護する必要があります。 クライアントのIDは、受動的攻撃者と能動的攻撃者の両方から保護する必要があります。
Informally, the signature-based modes of TLS 1.3 provide for the establishment of a unique, secret, shared key established by an (EC)DHE key exchange and authenticated by the server's signature over the handshake transcript, as well as tied to the server's identity by a MAC. If the client is authenticated by a certificate, it also signs over the handshake transcript and provides a MAC tied to both identities. [SIGMA] describes the design and analysis of this type of key exchange protocol. If fresh (EC)DHE keys are used for each connection, then the output keys are forward secret.
非公式には、TLS 1.3の署名ベースのモードは、（EC）DHEキー交換によって確立され、ハンドシェイクのトランスクリプト上のサーバーの署名によって認証され、サーバーのIDに関連付けられた一意の秘密共有キーの確立を提供します MACによって。 クライアントが証明書によって認証される場合、クライアントはハンドシェイクのトランスクリプトに署名し、両方のIDに関連付けられたMACを提供します。 [SIGMA]は、このタイプの鍵交換プロトコルの設計と分析について説明しています。 各接続に新しい（EC）DHEキーが使用される場合、出力キーは前方秘密です。
The external PSK and resumption PSK bootstrap from a long-term shared secret into a unique per-connection set of short-term session keys. This secret may have been established in a previous handshake. If PSK with (EC)DHE key establishment is used, these session keys will also be forward secret. The resumption PSK has been designed so that the resumption master secret computed by connection N and needed to form connection N+1 is separate from the traffic keys used by connection N, thus providing forward secrecy between the connections. In addition, if multiple tickets are established on the same connection, they are associated with different keys, so compromise of the PSK associated with one ticket does not lead to the compromise of connections established with PSKs associated with other tickets. This property is most interesting if tickets are stored in a database (and so can be deleted) rather than if they are self-encrypted.
外部PSKおよび再開PSKブートストラップ。長期共有秘密から、短期セッションキーの一意の接続ごとのセットになります。 この秘密は、以前のハンドシェイクで確立された可能性があります。 （EC）DHEキー確立を使用するPSKが使用される場合、これらのセッションキーも転送シークレットになります。 再開PSKは、接続Nによって計算され、接続N + 1を形成するために必要な再開マスターシークレットが接続Nによって使用されるトラフィックキーから分離されるように設計されています。 さらに、同じ接続で複数のチケットが確立された場合、それらは異なるキーに関連付けられるため、1つのチケットに関連付けられたPSKの侵害は、他のチケットに関連付けられたPSKで確立された接続の侵害につながりません。 このプロパティは、チケットが自己暗号化されている場合ではなく、データベースに保存されている（したがって削除できる）場合に最も興味深いものです。
The PSK binder value forms a binding between a PSK and the current handshake, as well as between the session where the PSK was established and the current session. This binding transitively includes the original handshake transcript, because that transcript is digested into the values which produce the resumption master secret. This requires that both the KDF used to produce the resumption master secret and the MAC used to compute the binder be collision resistant. See Appendix E.1.1 for more on this. Note: The binder does not cover the binder values from other PSKs, though they are included in the Finished MAC.
PSKバインダ値は、PSKと現在のハンドシェイクの間、およびPSKが確立されたセッションと現在のセッションの間のバインディングを形成します。 このバインディングには、元のハンドシェイクのトランスクリプトが一時的に含まれます。トランスクリプトは、再開マスターシークレットを生成する値にダイジェストされるためです。 これには、再開マスターシークレットを生成するために使用されるKDFと、バインダーを計算するために使用されるMACの両方が耐衝突性であることが必要です。 詳細については、付録E.1.1を参照してください。 注：バインダーは、他のPSKからのバインダー値をカバーしませんが、それらはFinished MACに含まれています。
TLS does not currently permit the server to send a certificate_request message in non-certificate-based handshakes (e.g., PSK). If this restriction were to be relaxed in future, the client's signature would not cover the server's certificate directly. However, if the PSK was established through a NewSessionTicket, the client's signature would transitively cover the server's certificate through the PSK binder. [PSK-FINISHED] describes a concrete attack on constructions that do not bind to the server's certificate (see also [Kraw16]). It is unsafe to use certificate-based client authentication when the client might potentially share the same PSK/key-id pair with two different endpoints. Implementations MUST NOT combine external PSKs with certificate-based authentication of either the client or the server unless negotiated by some extension.
TLSは現在、サーバーが非証明書ベースのハンドシェイク（PSKなど）でcertificate_requestメッセージを送信することを許可していません。 この制限が将来緩和される場合、クライアントの署名はサーバーの証明書を直接カバーしません。 ただし、PSKがNewSessionTicketを介して確立された場合、クライアントの署名は、PSKバインダーを介してサーバーの証明書を一時的にカバーします。 [PSK-FINISHED]は、サーバーの証明書にバインドしない構造に対する具体的な攻撃について説明しています（[Kraw16]も参照）。 クライアントが2つの異なるエンドポイントと同じPSK / key-idペアを共有する可能性がある場合、証明書ベースのクライアント認証を使用することは安全ではありません。 実装は、何らかの拡張によってネゴシエートされない限り、クライアントまたはサーバーの証明書ベースの認証と外部PSKを組み合わせてはなりません。
If an exporter is used, then it produces values which are unique and secret (because they are generated from a unique session key). Exporters computed with different labels and contexts are computationally independent, so it is not feasible to compute one from another or the session secret from the exported value. Note: Exporters can produce arbitrary-length values; if exporters are to be used as channel bindings, the exported value MUST be large enough to provide collision resistance. The exporters provided in TLS 1.3 are derived from the same Handshake Contexts as the early traffic keys and the application traffic keys, respectively, and thus have similar security properties. Note that they do not include the client's certificate; future applications which wish to bind to the client's certificate may need to define a new exporter that includes the full handshake transcript.
エクスポーターが使用される場合、一意の値が生成されます（一意のセッションキーから生成されるため）。 異なるラベルとコンテキストで計算されたエクスポーターは計算的に独立しているため、エクスポートされた値からセッションシークレットを計算したり、セッションシークレットを計算したりすることはできません。 注：エクスポーターは、任意の長さの値を生成できます。 エクスポーターをチャネルバインディングとして使用する場合、エクスポートされた値は、衝突抵抗を提供するのに十分な大きさでなければなりません。 TLS 1.3で提供されるエクスポーターは、初期トラフィックキーおよびアプリケーショントラフィックキーとそれぞれ同じハンドシェイクコンテキストから派生しているため、同様のセキュリティプロパティを持っています。 クライアントの証明書は含まれないことに注意してください。 クライアントの証明書にバインドしたい将来のアプリケーションは、完全なハンドシェイクトランスクリプトを含む新しいエクスポーターを定義する必要があるかもしれません。
For all handshake modes, the Finished MAC (and, where present, the signature) prevents downgrade attacks. In addition, the use of certain bytes in the random nonces as described in Section 4.1.3 allows the detection of downgrade to previous TLS versions. See [BBFGKZ16] for more details on TLS 1.3 and downgrade.
すべてのハンドシェイクモードで、Finished MAC（および存在する場合は署名）がダウングレード攻撃を防ぎます。 さらに、セクション4.1.3で説明されているように、ランダムナンスで特定のバイトを使用すると、以前のTLSバージョンへのダウングレードを検出できます。 TLS 1.3およびダウングレードの詳細については、[BBFGKZ16]を参照してください。
As soon as the client and the server have exchanged enough information to establish shared keys, the remainder of the handshake is encrypted, thus providing protection against passive attackers, even if the computed shared key is not authenticated. Because the server authenticates before the client, the client can ensure that if it authenticates to the server, it only reveals its identity to an authenticated server. Note that implementations must use the provided record-padding mechanism during the handshake to avoid leaking information about the identities due to length. The client's proposed PSK identities are not encrypted, nor is the one that the server selects.
クライアントとサーバーが共有キーを確立するのに十分な情報を交換するとすぐに、ハンドシェイクの残りは暗号化されるため、計算された共有キーが認証されていなくても、受動的な攻撃者から保護されます。 サーバーはクライアントよりも先に認証されるため、クライアントはサーバーに対して認証を行う場合、認証されたサーバーに対してのみその身元を明らかにすることができます。 実装は、長さによるアイデンティティに関する情報の漏洩を防ぐために、ハンドシェイク中に提供されたレコード埋め込みメカニズムを使用する必要があることに注意してください。 クライアントが提案するPSK IDは暗号化されず、サーバーが選択するIDも暗号化されません。
Key derivation in TLS 1.3 uses HKDF as defined in [RFC5869] and its two components, HKDF-Extract and HKDF-Expand. The full rationale for the HKDF construction can be found in [Kraw10] and the rationale for the way it is used in TLS 1.3 in [KW16]. Throughout this document, each application of HKDF-Extract is followed by one or more invocations of HKDF-Expand. This ordering should always be followed (including in future revisions of this document); in particular, one SHOULD NOT use an output of HKDF-Extract as an input to another application of HKDF-Extract without an HKDF-Expand in between. Multiple applications of HKDF-Expand to some of the same inputs are allowed as long as these are differentiated via the key and/or the labels.
TLS 1.3のキー派生では、[RFC5869]で定義されているHKDFとその2つのコンポーネント、HKDF-ExtractおよびHKDF-Expandが使用されます。 HKDF構築の完全な理論的根拠は[Kraw10]に、それがTLS 1.3で使用される方法の理論的根拠は[KW16]にあります。 このドキュメント全体を通して、HKDF-Extractの各アプリケーションの後に、HKDF-Expandの1つ以上の呼び出しが続きます。 この順序は常に守られる必要があります（このドキュメントの将来の改訂版を含む）。 特に、HKDF-Extractの出力を、間にHKDF-Expandを使用せずにHKDF-Extractの別のアプリケーションへの入力として使用するべきではありません。 同じ入力のいくつかへのHKDF-Expandの複数のアプリケーションは、キーおよび/またはラベルによって区別されている限り許可されます。
Note that HKDF-Expand implements a pseudorandom function (PRF) with both inputs and outputs of variable length. In some of the uses of HKDF in this document (e.g., for generating exporters and the resumption_master_secret), it is necessary that the application of HKDF-Expand be collision resistant; namely, it should be infeasible to find two different inputs to HKDF-Expand that output the same value. This requires the underlying hash function to be collision resistant and the output length from HKDF-Expand to be of size at least 256 bits (or as much as needed for the hash function to prevent finding collisions).
HKDF-Expandは、可変長の入力と出力の両方で疑似ランダム関数（PRF）を実装することに注意してください。 このドキュメントでのHKDFの使用のいくつかでは（たとえば、エクスポーターとresumption_master_secretを生成するため）、HKDF-Expandのアプリケーションが衝突に強いことが必要です。 つまり、同じ値を出力するHKDF-Expandへの2つの異なる入力を見つけることは不可能です。 これには、基礎となるハッシュ関数が耐衝突性であり、HKDF-Expandからの出力長が少なくとも256ビットのサイズである必要があります（または、ハッシュ関数が衝突の検出を防ぐために必要な長さ）。
A client that has sent authentication data to a server, either during the handshake or in post-handshake authentication, cannot be sure whether the server afterwards considers the client to be authenticated or not. If the client needs to determine if the server considers the connection to be unilaterally or mutually authenticated, this has to be provisioned by the application layer. See [CHHSV17] for details. In addition, the analysis of post-handshake authentication from [Kraw16] shows that the client identified by the certificate sent in the post-handshake phase possesses the traffic key. This party is therefore the client that participated in the original handshake or one to whom the original client delegated the traffic key (assuming that the traffic key has not been compromised).
ハンドシェイク中またはハンドシェイク後の認証のいずれかで認証データをサーバーに送信したクライアントは、その後サーバーがクライアントが認証されたとみなすかどうかを確認できません。 サーバーが接続を一方的に認証するか相互認証するかをクライアントが判断する必要がある場合、これはアプリケーション層によってプロビジョニングする必要があります。 詳細については、[CHHSV17]を参照してください。 さらに、[Kraw16]からのポストハンドシェイク認証の分析は、ポストハンドシェイクフェーズで送信された証明書によって識別されるクライアントがトラフィックキーを所有していることを示しています。 したがって、このパーティは、元のハンドシェイクに参加したクライアント、または元のクライアントがトラフィックキーを委任したクライアントです（トラフィックキーが侵害されていない場合）。
The 0-RTT mode of operation generally provides security properties similar to those of 1-RTT data, with the two exceptions that the 0-RTT encryption keys do not provide full forward secrecy and that the server is not able to guarantee uniqueness of the handshake (non-replayability) without keeping potentially undue amounts of state. See Section 8 for mechanisms to limit the exposure to replay.
通常、0-RTT動作モードは1-RTTデータのセキュリティプロパティと同様のセキュリティプロパティを提供しますが、2つの例外は0-RTT暗号化キーは完全な転送秘密を提供せず、サーバーはハンドシェイクの一意性を保証できないことです。 （再生不能）潜在的に過度の量の状態を維持することなく。 リプレイへの露出を制限するメカニズムについては、セクション8を参照してください。
The exporter_master_secret and early_exporter_master_secret are derived to be independent of the traffic keys and therefore do not represent a threat to the security of traffic encrypted with those keys. However, because these secrets can be used to compute any exporter value, they SHOULD be erased as soon as possible. If the total set of exporter labels is known, then implementations SHOULD pre-compute the inner Derive-Secret stage of the exporter computation for all those labels, then erase the [early_]exporter_master_secret, followed by each inner value as soon as it is known that it will not be needed again.
exporter_master_secretおよびearly_exporter_master_secretは、トラフィックキーに依存しないように導出されているため、これらのキーで暗号化されたトラフィックのセキュリティに対する脅威を表していません。 ただし、これらのシークレットはエクスポーター値の計算に使用できるため、できるだけ早く消去する必要があります。 エクスポーターラベルの合計セットがわかっている場合、実装は、それらすべてのラベルのエクスポーター計算の内部秘密導出ステージを事前計算し、[early_] exporter_master_secretを消去し、その後、各内部値がわかるとすぐに消去する必要があります。 二度と必要ないこと。
TLS does not provide security for handshakes which take place after the peer's long-term secret (signature key or external PSK) is compromised. It therefore does not provide post-compromise security [CCG16], sometimes also referred to as backward or future secrecy. This is in contrast to KCI resistance, which describes the security guarantees that a party has after its own long-term secret has been compromised.
TLSは、ピアの長期シークレット（署名キーまたは外部PSK）が侵害された後に行われるハンドシェイクのセキュリティを提供しません。 したがって、事後セキュリティ[CCG16]は提供されず、逆方向または将来の秘密とも呼ばれます。 これは、KCIの抵抗とは対照的です。KCIの抵抗は、長期的な秘密が侵害された後のパーティのセキュリティ保証を示します。
The reader should refer to the following references for analysis of the TLS handshake: [DFGS15], [CHSV16], [DFGS16], [KW16], [Kraw16], [FGSW16], [LXZFH16], [FG17], and [BBK17].
読者は、TLSハンドシェイクの分析について次のリファレンスを参照する必要があります。[DFGS15]、[CHSV16]、[DFGS16]、[KW16]、[Kraw16]、[FGSW16]、[LXZFH16]、[FG17]、および[BBK17] ]。
The record layer depends on the handshake producing strong traffic secrets which can be used to derive bidirectional encryption keys and nonces. Assuming that is true, and the keys are used for no more data than indicated in Section 5.5, then the record layer should provide the following guarantees:
レコード層は、双方向の暗号化キーとナンスを導出するために使用できる強力なトラフィックシークレットを生成するハンドシェイクに依存します。 それが真実であり、キーがセクション5.5に示されている以上のデータに使用されないと仮定すると、レコード層は次の保証を提供する必要があります。
Confidentiality: An attacker should not be able to determine the plaintext contents of a given record.
機密性：攻撃者は、特定のレコードのプレーンテキストの内容を判別できないようにする必要があります。
Integrity: An attacker should not be able to craft a new record which is different from an existing record which will be accepted by the receiver.
整合性：攻撃者は、受信者によって受け入れられる既存のレコードとは異なる新しいレコードを作成することはできません。
Order protection/non-replayability: An attacker should not be able to cause the receiver to accept a record which it has already accepted or cause the receiver to accept record N+1 without having first processed record N.
注文保護/非再生可能性：攻撃者は、受信者に既に受け入れたレコードを受け入れさせたり、受信者に最初のレコードNを処理させずにレコードN + 1を受け入れさせたりすることはできません。
Length concealment: Given a record with a given external length, the attacker should not be able to determine the amount of the record that is content versus padding.
長さの隠蔽：指定された外部の長さのレコードが与えられた場合、攻撃者はコンテンツとパディングのレコードの量を判断できないはずです。
Forward secrecy after key change: If the traffic key update mechanism described in Section 4.6.3 has been used and the previous generation key is deleted, an attacker who compromises the endpoint should not be able to decrypt traffic encrypted with the old key.
キー変更後の秘密の転送：セクション4.6.3で説明したトラフィックキー更新メカニズムが使用され、前世代のキーが削除された場合、エンドポイントを侵害する攻撃者は、古いキーで暗号化されたトラフィックを解読できません。
Informally, TLS 1.3 provides these properties by AEAD-protecting the plaintext with a strong key. AEAD encryption [RFC5116] provides confidentiality and integrity for the data. Non-replayability is provided by using a separate nonce for each record, with the nonce being derived from the record sequence number (Section 5.3), with the sequence number being maintained independently at both sides; thus, records which are delivered out of order result in AEAD deprotection failures. In order to prevent mass cryptanalysis when the same plaintext is repeatedly encrypted by different users under the same key (as is commonly the case for HTTP), the nonce is formed by mixing the sequence number with a secret per-connection initialization vector derived along with the traffic keys. See [BT16] for analysis of this construction.
非公式には、TLS 1.3は、強力なキーでプレーンテキストをAEADで保護することにより、これらのプロパティを提供します。 AEAD暗号化[RFC5116]は、データの機密性と整合性を提供します。 非再生可能性は、レコードごとに個別のノンスを使用することによって提供されます。ノンスは、レコードのシーケンス番号から派生し（5.3項）、シーケンス番号は両側で独立して維持されます。 したがって、順不同で配信されたレコードはAEAD保護解除エラーになります。 同じ平文が同じキーの下で異なるユーザーによって繰り返し暗号化される場合の大量暗号解析を防ぐために（HTTPの一般的な場合）、nonceは、シーケンス番号と、 交通キー。 この構造の分析については[BT16]を参照してください。
The rekeying technique in TLS 1.3 (see Section 7.2) follows the construction of the serial generator as discussed in [REKEY], which shows that rekeying can allow keys to be used for a larger number of encryptions than without rekeying. This relies on the security of the HKDF-Expand-Label function as a pseudorandom function (PRF). In addition, as long as this function is truly one way, it is not possible to compute traffic keys from prior to a key change (forward secrecy).
TLS 1.3のキー再生成手法（セクション7.2を参照）は、[REKEY]で説明したシリアルジェネレーターの構造に従います。これは、キー再生成により、キー再生成なしでより多くの暗号化にキーを使用できることを示しています。 これは、HKDF-Expand-Label関数のセキュリティを擬似ランダム関数（PRF）として使用します。 さらに、この機能が本当に1つの方法である限り、キー変更（前方秘匿性）の前からトラフィックキーを計算することはできません。
TLS does not provide security for data which is communicated on a connection after a traffic secret of that connection is compromised. That is, TLS does not provide post-compromise security/future secrecy/backward secrecy with respect to the traffic secret. Indeed, an attacker who learns a traffic secret can compute all future traffic secrets on that connection. Systems which want such guarantees need to do a fresh handshake and establish a new connection with an (EC)DHE exchange.
TLSは、接続のトラフィックシークレットが危険にさらされた後に接続で通信されるデータのセキュリティを提供しません。 つまり、TLSは、トラフィックシークレットに関して、事後のセキュリティ/将来の秘密/後方の秘密を提供しません。 実際、トラフィックシークレットを学習する攻撃者は、その接続で将来のすべてのトラフィックシークレットを計算できます。 そのような保証を必要とするシステムは、新しいハンドシェイクを行い、（EC）DHE交換との新しい接続を確立する必要があります。
The reader should refer to the following references for analysis of the TLS record layer: [BMMRT15], [BT16], [BDFKPPRSZZ16], [BBK17], and [PS18].
読者は、TLSレコード層の分析について次の参照を参照する必要があります：[BMMRT15]、[BT16]、[BDFKPPRSZZ16]、[BBK17]、および[PS18]。
TLS is susceptible to a variety of traffic analysis attacks based on observing the length and timing of encrypted packets [CLINIC] [HCJC16]. This is particularly easy when there is a small set of possible messages to be distinguished, such as for a video server hosting a fixed corpus of content, but still provides usable information even in more complicated scenarios.
TLSは、暗号化されたパケットの長さとタイミングの観察に基づいたさまざまなトラフィック分析攻撃を受けやすい[CLINIC] [HCJC16]。 これは、コンテンツの固定コーパスをホストするビデオサーバーなど、区別される可能性のあるメッセージの小さなセットがある場合に特に簡単ですが、さらに複雑なシナリオでも有用な情報を提供します。
TLS does not provide any specific defenses against this form of attack but does include a padding mechanism for use by applications: The plaintext protected by the AEAD function consists of content plus variable-length padding, which allows the application to produce arbitrary-length encrypted records as well as padding-only cover traffic to conceal the difference between periods of transmission and periods of silence. Because the padding is encrypted alongside the actual content, an attacker cannot directly determine the length of the padding but may be able to measure it indirectly by the use of timing channels exposed during record processing (i.e., seeing how long it takes to process a record or trickling in records to see which ones elicit a response from the server). In general, it is not known how to remove all of these channels because even a constant-time padding removal function will likely feed the content into data-dependent functions. At minimum, a fully constant-time server or client would require close cooperation with the application-layer protocol implementation, including making that higher-level protocol constant time.
TLSは、この形式の攻撃に対する特定の防御を提供しませんが、アプリケーションが使用するパディングメカニズムを含みます：AEAD機能で保護されたプレーンテキストは、コンテンツと可変長パディングで構成され、アプリケーションは任意の長さの暗号化されたレコードを作成できますまた、パディングのみでトラフィックをカバーし、送信期間と無音期間の違いを隠します。パディングは実際のコンテンツと一緒に暗号化されるため、攻撃者はパディングの長さを直接決定することはできませんが、レコード処理中に公開されたタイミングチャネルを使用して間接的に測定できる場合があります（つまり、レコードの処理にかかる時間を確認するまたはどのレコードがサーバーからの応答を引き出すかを確認するためにレコードを細流化します）。一般に、これらのすべてのチャネルを削除する方法は不明です。これは、一定時間のパディング削除関数でさえ、コンテンツをデータ依存関数に送り込む可能性が高いためです。少なくとも、完全に一定時間のサーバーまたはクライアントは、その上位レベルのプロトコルを一定時間にするなど、アプリケーション層プロトコルの実装との緊密な協力を必要とします。
Note: Robust traffic analysis defenses will likely lead to inferior performance due to delays in transmitting packets and increased traffic volume.
注：堅牢なトラフィック分析防御は、パケット送信の遅延とトラフィック量の増加により、パフォーマンスの低下につながる可能性があります。
In general, TLS does not have specific defenses against side-channel attacks (i.e., those which attack the communications via secondary channels such as timing), leaving those to the implementation of the relevant cryptographic primitives. However, certain features of TLS are designed to make it easier to write side-channel resistant code:
一般に、TLSにはサイドチャネル攻撃（つまり、タイミングなどのセカンダリチャネルを介して通信を攻撃する攻撃）に対する特定の防御策がなく、それらを関連する暗号プリミティブの実装に任せています。 ただし、TLSの特定の機能は、サイドチャネルに耐性のあるコードを簡単に記述できるように設計されています。
- Unlike previous versions of TLS which used a composite MAC-then-encrypt structure, TLS 1.3 only uses AEAD algorithms, allowing implementations to use self-contained constant-time implementations of those primitives.
- 複合MAC-then-encrypt構造を使用した以前のバージョンのTLSとは異なり、TLS 1.3はAEADアルゴリズムのみを使用し、実装がこれらのプリミティブの自己完結型の一定時間実装を使用できるようにします。
- TLS uses a uniform "bad_record_mac" alert for all decryption errors, which is intended to prevent an attacker from gaining piecewise insight into portions of the message. Additional resistance is provided by terminating the connection on such errors; a new connection will have different cryptographic material, preventing attacks against the cryptographic primitives that require multiple trials.
- TLSは、すべての復号化エラーに対して均一な「bad_record_mac」アラートを使用します。これは、攻撃者がメッセージの一部を区分的に洞察することを防ぐことを目的としています。 このようなエラーで接続を終了することにより、追加の抵抗が提供されます。 新しい接続には異なる暗号化マテリアルがあり、複数の試行を必要とする暗号化プリミティブに対する攻撃を防ぎます。
Information leakage through side channels can occur at layers above TLS, in application protocols and the applications that use them. Resistance to side-channel attacks depends on applications and application protocols separately ensuring that confidential information is not inadvertently leaked.
サイドチャネルを介した情報漏えいは、アプリケーションプロトコルおよびそれらを使用するアプリケーションで、TLSの上の層で発生する可能性があります。 サイドチャネル攻撃に対する耐性は、機密情報が不注意に漏洩しないことを保証するアプリケーションとアプリケーションプロトコルに個別に依存します。
Replayable 0-RTT data presents a number of security threats to TLS-using applications, unless those applications are specifically engineered to be safe under replay (minimally, this means idempotent, but in many cases may also require other stronger conditions, such as constant-time response). Potential attacks include:
再生可能な0-RTTデータは、TLSを使用するアプリケーションに対して、それらのアプリケーションが再生時に安全になるように特別に設計されていない限り、多くのセキュリティ上の脅威を示します（最低限、これはべき等を意味しますが、多くの場合、他のより強い条件、例えば 時間応答）。 潜在的な攻撃には次のものがあります。
- Duplication of actions which cause side effects (e.g., purchasing an item or transferring money) to be duplicated, thus harming the site or the user.
- 副作用（アイテムの購入や送金など）を引き起こすアクションの複製が複製されるため、サイトまたはユーザーに損害を与えます。
- Attackers can store and replay 0-RTT messages in order to reorder them with respect to other messages (e.g., moving a delete to after a create).
- 攻撃者は、0-RTTメッセージを保存および再生して、他のメッセージに対して並べ替えることができます（たとえば、作成後に削除を移動する）。
- Exploiting cache timing behavior to discover the content of 0-RTT messages by replaying a 0-RTT message to a different cache node and then using a separate connection to measure request latency, to see if the two requests address the same resource.
- キャッシュタイミング動作を利用して、0-RTTメッセージを別のキャッシュノードに再生し、別の接続を使用してリクエストレイテンシを測定し、2つのリクエストが同じリソースに対応しているかどうかを確認することにより、0-RTTメッセージの内容を検出します。
If data can be replayed a large number of times, additional attacks become possible, such as making repeated measurements of the speed of cryptographic operations. In addition, they may be able to overload rate-limiting systems. For a further description of these attacks, see [Mac17].
データを何度も再生できる場合、暗号化操作の速度を繰り返し測定するなど、追加の攻撃が可能になります。 さらに、レート制限システムに過負荷をかけることができます。 これらの攻撃の詳細については、[Mac17]を参照してください。
Ultimately, servers have the responsibility to protect themselves against attacks employing 0-RTT data replication. The mechanisms described in Section 8 are intended to prevent replay at the TLS layer but do not provide complete protection against receiving multiple copies of client data. TLS 1.3 falls back to the 1-RTT handshake when the server does not have any information about the client, e.g., because it is in a different cluster which does not share state or because the ticket has been deleted as described in Section 8.1. If the application-layer protocol retransmits data in this setting, then it is possible for an attacker to induce message duplication by sending the ClientHello to both the original cluster (which processes the data immediately) and another cluster which will fall back to 1-RTT and process the data upon application-layer replay. The scale of this attack is limited by the client's willingness to retry transactions and therefore only allows a limited amount of duplication, with each copy appearing as a new connection at the server.
最終的に、サーバーは0-RTTデータ複製を使用する攻撃から自身を保護する責任があります。セクション8で説明されているメカニズムは、TLS層での再生を防止することを目的としていますが、クライアントデータの複数のコピーの受信に対する完全な保護を提供するものではありません。 TLS 1.3は、サーバーがクライアントに関する情報を持っていない場合、たとえば、状態を共有しない別のクラスターにあるか、セクション8.1で説明されているようにチケットが削除されたため、1-RTTハンドシェイクにフォールバックします。アプリケーション層プロトコルがこの設定でデータを再送信する場合、攻撃者は、ClientHelloを元のクラスター（データを直ちに処理する）と1-RTTにフォールバックする別のクラスターの両方に送信することにより、メッセージの重複を誘発する可能性がありますアプリケーション層の再生時にデータを処理します。この攻撃の規模は、クライアントがトランザクションを再試行する意思によって制限されるため、複製が制限され、各コピーはサーバーで新しい接続として表示されます。
If implemented correctly, the mechanisms described in Sections 8.1 and 8.2 prevent a replayed ClientHello and its associated 0-RTT data from being accepted multiple times by any cluster with consistent state; for servers which limit the use of 0-RTT to one cluster for a single ticket, then a given ClientHello and its associated 0-RTT data will only be accepted once. However, if state is not completely consistent, then an attacker might be able to have multiple copies of the data be accepted during the replication window. Because clients do not know the exact details of server behavior, they MUST NOT send messages in early data which are not safe to have replayed and which they would not be willing to retry across multiple 1-RTT connections.
正しく実装されている場合、セクション8.1および8.2で説明されているメカニズムにより、再生されたClientHelloとそれに関連する0-RTTデータが、一貫した状態のクラスターによって複数回受け入れられるのを防ぎます。 1つのチケットに対して0-RTTの使用を1つのクラスターに制限するサーバーの場合、特定のClientHelloとそれに関連付けられた0-RTTデータは1回しか受け入れられません。 ただし、状態が完全に一貫していない場合、攻撃者はレプリケーションウィンドウ中にデータの複数のコピーを受け入れることができる場合があります。 クライアントはサーバーの動作の正確な詳細を知らないため、リプレイするのが安全ではなく、複数の1-RTT接続で再試行したくない初期データのメッセージを送信してはなりません。
Application protocols MUST NOT use 0-RTT data without a profile that defines its use. That profile needs to identify which messages or interactions are safe to use with 0-RTT and how to handle the situation when the server rejects 0-RTT and falls back to 1-RTT.
アプリケーションプロトコルは、その使用を定義するプロファイルなしで0-RTTデータを使用してはなりません。 そのプロファイルでは、0-RTTで安全に使用できるメッセージまたは対話を特定し、サーバーが0-RTTを拒否して1-RTTにフォールバックする状況を処理する方法を識別する必要があります。
In addition, to avoid accidental misuse, TLS implementations MUST NOT enable 0-RTT (either sending or accepting) unless specifically requested by the application and MUST NOT automatically resend 0-RTT data if it is rejected by the server unless instructed by the application. Server-side applications may wish to implement special processing for 0-RTT data for some kinds of application traffic (e.g., abort the connection, request that data be resent at the application layer, or delay processing until the handshake completes). In order to allow applications to implement this kind of processing, TLS implementations MUST provide a way for the application to determine if the handshake has completed.
さらに、偶発的な誤用を避けるために、TLS実装は、アプリケーションによって特に要求されない限り、0-RTT（送信または受け入れのいずれか）を有効にしてはならず、アプリケーションによって指示されない限り、サーバーによって拒否された場合、0-RTTデータを自動的に再送信してはなりません。 サーバー側のアプリケーションは、ある種のアプリケーショントラフィックの0-RTTデータに特別な処理を実装することを希望する場合があります（たとえば、接続の中止、アプリケーション層でのデータの再送信の要求、またはハンドシェイクが完了するまで処理を遅らせる）。 アプリケーションがこの種の処理を実装できるようにするため、TLS実装は、アプリケーションがハンドシェイクが完了したかどうかを判断する方法を提供する必要があります。
Replays of the ClientHello produce the same early exporter, thus requiring additional care by applications which use these exporters. In particular, if these exporters are used as an authentication channel binding (e.g., by signing the output of the exporter), an attacker who compromises the PSK can transplant authenticators between connections without compromising the authentication key.
ClientHelloのリプレイは同じ初期エクスポーターを生成するため、これらのエクスポーターを使用するアプリケーションによる追加の注意が必要です。 特に、これらのエクスポーターが認証チャネルバインディングとして使用される場合（エクスポーターの出力に署名するなど）、PSKを侵害する攻撃者は、認証キーを損なうことなく、接続間で認証子を移植できます。
In addition, the early exporter SHOULD NOT be used to generate server-to-client encryption keys because that would entail the reuse of those keys. This parallels the use of the early application traffic keys only in the client-to-server direction.
さらに、初期エクスポーターは、サーバーからクライアントへの暗号化キーを生成するために使用しないでください（これらのキーの再利用が必要になるため）。 これは、クライアントからサーバーへの方向でのみ、初期のアプリケーショントラフィックキーの使用と並行しています。
Because implementations respond to an invalid PSK binder by aborting the handshake, it may be possible for an attacker to verify whether a given PSK identity is valid. Specifically, if a server accepts both external-PSK handshakes and certificate-based handshakes, a valid PSK identity will result in a failed handshake, whereas an invalid identity will just be skipped and result in a successful certificate handshake. Servers which solely support PSK handshakes may be able to resist this form of attack by treating the cases where there is no valid PSK identity and where there is an identity but it has an invalid binder identically.
実装はハンドシェイクを中止することで無効なPSKバインダーに応答するため、攻撃者は特定のPSK IDが有効かどうかを確認できる可能性があります。 具体的には、サーバーが外部PSKハンドシェイクと証明書ベースのハンドシェイクの両方を受け入れる場合、有効なPSK IDはハンドシェイクに失敗しますが、無効なIDはスキップされ、証明書ハンドシェイクに成功します。 PSKハンドシェイクのみをサポートするサーバーは、有効なPSK IDが存在せず、IDは存在するが無効なバインダーを持つケースを処理することにより、この形式の攻撃に抵抗できる場合があります。
TLS 1.3 takes a conservative approach to PSKs by binding them to a specific KDF. By contrast, TLS 1.2 allows PSKs to be used with any hash function and the TLS 1.2 PRF. Thus, any PSK which is used with both TLS 1.2 and TLS 1.3 must be used with only one hash in TLS 1.3, which is less than optimal if users want to provision a single PSK. The constructions in TLS 1.2 and TLS 1.3 are different, although they are both based on HMAC. While there is no known way in which the same PSK might produce related output in both versions, only limited analysis has been done. Implementations can ensure safety from cross-protocol related output by not reusing PSKs between TLS 1.3 and TLS 1.2.
TLS 1.3は、PSKを特定のKDFにバインドすることにより、PSKに対して保守的なアプローチを取ります。 対照的に、TLS 1.2では、PSKを任意のハッシュ関数およびTLS 1.2 PRFで使用できます。 したがって、TLS 1.2とTLS 1.3の両方で使用されるPSKは、TLS 1.3の1つのハッシュのみで使用する必要があります。これは、ユーザーが単一のPSKをプロビジョニングする場合は最適ではありません。 TLS 1.2とTLS 1.3の構造は異なりますが、どちらもHMACに基づいています。 同じPSKが両方のバージョンで関連する出力を生成する既知の方法はありませんが、限られた分析のみが行われています。 実装では、TLS 1.3とTLS 1.2の間でPSKを再利用しないことで、クロスプロトコル関連の出力から安全性を確保できます。
Although TLS 1.3 does not use RSA key transport and so is not directly susceptible to Bleichenbacher-type attacks [Blei98], if TLS 1.3 servers also support static RSA in the context of previous versions of TLS, then it may be possible to impersonate the server for TLS 1.3 connections [JSS15]. TLS 1.3 implementations can prevent this attack by disabling support for static RSA across all versions of TLS. In principle, implementations might also be able to separate certificates with different keyUsage bits for static RSA decryption and RSA signature, but this technique relies on clients refusing to accept signatures using keys in certificates that do not have the digitalSignature bit set, and many clients do not enforce this restriction.
TLS 1.3はRSAキー転送を使用しないため、Bleichenbacherタイプの攻撃[Blei98]の影響を直接受けませんが、TLS 1.3サーバーもTLSの以前のバージョンのコンテキストで静的RSAをサポートしている場合、サーバーになりすます可能性があります TLS 1.3接続の場合[JSS15]。 TLS 1.3実装は、TLSのすべてのバージョンで静的RSAのサポートを無効にすることにより、この攻撃を防ぐことができます。 原則として、実装は静的RSA復号化とRSA署名用に異なるkeyUsageビットの証明書を分離することもできますが、この手法は、digitalSignatureビットが設定されていない証明書のキーを使用して署名を受け入れることを拒否するクライアントに依存し、多くのクライアントはそうします この制限を強制しません。
Contributors
貢献者
Martin Abadi University of California, Santa Cruz abadi@cs.ucsc.edu
カリフォルニア州マーティンアバディ大学、サンタクルーズabadi@cs.ucsc.edu
Christopher Allen (co-editor of TLS 1.0) Alacrity Ventures ChristopherA@AlacrityManagement.com
クリストファーアレン（TLS 1.0の共同編集者）Alacrity Ventures ChristopherA@AlacrityManagement.com
Richard Barnes Cisco rlb@ipv.sx
リチャードバーンズシスコrlb@ipv.sx
Steven M. Bellovin Columbia University smb@cs.columbia.edu
スティーブンM.ベロビンコロンビア大学smb@cs.columbia.edu
David Benjamin Google davidben@google.com
デビッド・ベンジャミンGoogle davidben@google.com
Benjamin Beurdouche INRIA & Microsoft Research benjamin.beurdouche@ens.fr
Benjamin Beurdouche INRIA＆Microsoft Research benjamin.beurdouche@ens.fr
Karthikeyan Bhargavan (editor of [RFC7627]) INRIA karthikeyan.bhargavan@inria.fr
Karthikeyan Bhargavan（[RFC7627]の編集者）INRIA karthikeyan.bhargavan@inria.fr
Simon Blake-Wilson (co-author of [RFC4492]) BCI sblakewilson@bcisse.com
Simon Blake-Wilson（[RFC4492]の共著者）BCI sblakewilson@bcisse.com
Nelson Bolyard (co-author of [RFC4492]) Sun Microsystems, Inc. nelson@bolyard.com
Nelson Bolyard（[RFC4492]の共著者）Sun Microsystems、Inc. nelson@bolyard.com
Ran Canetti IBM canetti@watson.ibm.com
Ran Canetti IBM canetti@watson.ibm.com
Matt Caswell OpenSSL matt@openssl.org
Matt Caswell OpenSSL matt@openssl.org
Stephen Checkoway University of Illinois at Chicago sfc@uic.edu
スティーブン・チェックウェイイリノイ大学シカゴ校sfc@uic.edu
Pete Chown Skygate Technology Ltd pc@skygate.co.uk
ピートチャウンスカイゲートテクノロジーリミテッドpc@skygate.co.uk
Katriel Cohn-Gordon University of Oxford me@katriel.co.uk
オックスフォード大学カトリエル・コーン・ゴードン大学me@katriel.co.uk
Cas Cremers University of Oxford cas.cremers@cs.ox.ac.uk
オックスフォードのカスクレマーズ大学cas.cremers@cs.ox.ac.uk
Antoine Delignat-Lavaud (co-author of [RFC7627]) INRIA antdl@microsoft.com
Antoine Delignat-Lavaud（[RFC7627]の共著者）INRIA antdl@microsoft.com
Tim Dierks (co-author of TLS 1.0, co-editor of TLS 1.1 and 1.2) Independent tim@dierks.org
Tim Dierks（TLS 1.0の共著者、TLS 1.1および1.2の共同編集者）独立tim@dierks.org
Roelof DuToit Symantec Corporation roelof_dutoit@symantec.com
Roelof DuToit Symantec Corporation roelof_dutoit@symantec.com
Taher Elgamal Securify taher@securify.com
Taher Elgamal Securify taher@securify.com
Pasi Eronen Nokia pasi.eronen@nokia.com
Pasi Eronen Nokia pasi.eronen@nokia.com
Cedric Fournet Microsoft fournet@microsoft.com
Cedric Fournet Microsoft fournet@microsoft.com
Anil Gangolli anil@busybuddha.org
アニル・ガンゴリanil@busybuddha.org
David M. Garrett dave@nulldereference.com
デビッド・M・ギャレットdave@nulldereference.com
Illya Gerasymchuk Independent illya@iluxonchik.me
Illya Gerasymchuk Independent illya@iluxonchik.me
Alessandro Ghedini Cloudflare Inc. alessandro@cloudflare.com
Alessandro Ghedini Cloudflare Inc. alessandro@cloudflare.com
Daniel Kahn Gillmor ACLU dkg@fifthhorseman.net
ダニエルカーンギルモアACLU dkg@fifthhorseman.net
Matthew Green Johns Hopkins University mgreen@cs.jhu.edu
マシュー・グリーン・ジョンズ・ホプキンス大学mgreen@cs.jhu.edu
Jens Guballa ETAS jens.guballa@etas.com
Jens Guballa ETAS jens.guballa@etas.com
Felix Guenther TU Darmstadt mail@felixguenther.info
Felix Guenther TUダルムシュタットmail@felixguenther.info
Vipul Gupta (co-author of [RFC4492]) Sun Microsystems Laboratories vipul.gupta@sun.com
Vipul Gupta（[RFC4492]の共著者）Sun Microsystems Laboratories vipul.gupta@sun.com
Chris Hawk (co-author of [RFC4492]) Corriente Networks LLC chris@corriente.net
クリス・ホーク（[RFC4492]の共著者）Corriente Networks LLC chris@corriente.net
Kipp Hickman
キップ・ヒックマン
Alfred Hoenes
アルフレッド・ホーネス
David Hopwood Independent Consultant david.hopwood@blueyonder.co.uk
デビッド・ホップウッド独立コンサルタントdavid.hopwood@blueyonder.co.uk
Marko Horvat MPI-SWS mhorvat@mpi-sws.org
Marko Horvat MPI-SWS mhorvat@mpi-sws.org
Jonathan Hoyland Royal Holloway, University of London jonathan.hoyland@gmail.com
ジョナサン・ホイランドロイヤル・ホロウェイ、ロンドン大学jonathan.hoyland@gmail.com
Subodh Iyengar Facebook subodh@fb.com
Subodh Iyengar Facebook subodh@fb.com
Benjamin Kaduk Akamai Technologies kaduk@mit.edu
Benjamin Kaduk Akamai Technologies kaduk@mit.edu
Hubert Kario Red Hat Inc. hkario@redhat.com
ヒューバート・カリオ・レッドハット・インクhkario@redhat.com
Phil Karlton (co-author of SSL 3.0)
Phil Karlton（SSL 3.0の共著者）
Leon Klingele Independent mail@leonklingele.de
Leon Klingele Independent mail@leonklingele.de
Paul Kocher (co-author of SSL 3.0) Cryptography Research paul@cryptography.com
Paul Kocher（SSL 3.0の共著者）Cryptography Research paul@cryptography.com
Hugo Krawczyk IBM hugokraw@us.ibm.com
Hugo Krawczyk IBM hugokraw@us.ibm.com
Adam Langley (co-author of [RFC7627]) Google agl@google.com
Adam Langley（[RFC7627]の共著者）Google agl@google.com
Olivier Levillain ANSSI olivier.levillain@ssi.gouv.fr
オリヴィエ・レヴィランANSSI olivier.levillain@ssi.gouv.fr
Xiaoyin Liu University of North Carolina at Chapel Hill xiaoyin.l@outlook.com
ノースカロライナ州のy音Li大学、チャペルヒルxiaoyin.l@outlook.com
Ilari Liusvaara Independent ilariliusvaara@welho.com
Ilari Liusvaara独立ilariliusvaara@welho.com
Atul Luykx K.U. Leuven atul.luykx@kuleuven.be
Atul Luykx K.U. ルーベンatul.luykx@kuleuven.be
Colm MacCarthaigh Amazon Web Services colm@allcosts.net
Colm MacCarthaighアマゾンウェブサービスcolm@allcosts.net
Carl Mehner USAA carl.mehner@usaa.com
Carl Mehner USAA carl.mehner@usaa.com
Jan Mikkelsen Transactionware janm@transactionware.com
ヤン・ミケルセンTransactionware janm@transactionware.com
Bodo Moeller (co-author of [RFC4492]) Google bodo@acm.org
Bodo Moeller（[RFC4492]の共著者）Google bodo@acm.org
Kyle Nekritz Facebook knekritz@fb.com
カイル・ネクリッツFacebook knekritz@fb.com
Erik Nygren Akamai Technologies erik+ietf@nygren.org
Erik Nygren Akamai Technologies erik+ietf@nygren.org
Magnus Nystrom Microsoft mnystrom@microsoft.com
Magnus Nystromマイクロソフトmnystrom@microsoft.com
Kazuho Oku DeNA Co., Ltd. kazuhooku@gmail.com
奥一穂DeNA Co.、Ltd. kazuhooku@gmail.com
Kenny Paterson Royal Holloway, University of London kenny.paterson@rhul.ac.uk
ロンドン大学ケニー・パターソン・ロイヤル・ホロウェイkenny.paterson@rhul.ac.uk
Christopher Patton University of Florida cjpatton@ufl.edu
クリストファー・パットン大学フロリダ大学cjpatton@ufl.edu
Alfredo Pironti (co-author of [RFC7627]) INRIA alfredo.pironti@inria.fr
Alfredo Pironti（[RFC7627]の共著者）INRIA alfredo.pironti@inria.fr
Andrei Popov Microsoft andrei.popov@microsoft.com
アンドレイ・ポポフマイクロソフトandrei.popov@microsoft.com
Marsh Ray (co-author of [RFC7627]) Microsoft maray@microsoft.com
マーシュレイ（[RFC7627]の共著者）Microsoft maray@microsoft.com
Robert Relyea Netscape Communications relyea@netscape.com
ロバート・レリエア・ネットスケープ・コミュニケーションズreliea@netscape.com
Kyle Rose Akamai Technologies krose@krose.org
カイルローズアカマイテクノロジーズkrose@krose.org
Jim Roskind Amazon jroskind@amazon.com
ジム・ロスキンドAmazon jroskind@amazon.com
Michael Sabin
マイケル・サビン
Joe Salowey Tableau Software joe@salowey.net
Joe Salowey Tableau Software joe@salowey.net
Rich Salz Akamai rsalz@akamai.com
リッチザルツアカマイrsalz@akamai.com
David Schinazi Apple Inc. dschinazi@apple.com
David Schinazi Apple Inc. dschinazi@apple.com
Sam Scott Royal Holloway, University of London me@samjs.co.uk
ロンドン大学サム・スコット・ロイヤル・ホロウェイme@samjs.co.uk
Thomas Shrimpton University of Florida teshrim@ufl.edu
フロリダ大学トーマス・シュリンプトン大学teshrim@ufl.edu
Dan Simon Microsoft, Inc. dansimon@microsoft.com
ダンサイモンマイクロソフト社dansimon@microsoft.com
Brian Smith Independent brian@briansmith.org
ブライアン・スミス独立brian@briansmith.org
Brian Sniffen Akamai Technologies ietf@bts.evenmere.org
ブライアン・スニフェン・アカマイ・テクノロジーズietf@bts.evenmere.org
Nick Sullivan Cloudflare Inc. nick@cloudflare.com
Nick Sullivan Cloudflare Inc. nick@cloudflare.com
Bjoern Tackmann University of California, San Diego btackmann@eng.ucsd.edu
Bjoern Tackmannカリフォルニア大学サンディエゴ校btackmann@eng.ucsd.edu
Tim Taubert Mozilla ttaubert@mozilla.com
Tim Taubert Mozilla ttaubert@mozilla.com
Martin Thomson Mozilla mt@mozilla.com
マーティントムソンMozilla mt@mozilla.com
Hannes Tschofenig Arm Limited Hannes.Tschofenig@arm.com
Hannes Tschofenig Arm Limited Hannes.Tschofenig@arm.com
Sean Turner sn3rd sean@sn3rd.com
ショーン・ターナーsn3rd sean@sn3rd.com
Steven Valdez Google svaldez@google.com
Steven Valdez Google svaldez@google.com
Filippo Valsorda Cloudflare Inc. filippo@cloudflare.com
Filippo Valsorda Cloudflare Inc. filippo@cloudflare.com
Thyla van der Merwe Royal Holloway, University of London tjvdmerwe@gmail.com
Thyla van der Merwe Royal Holloway、ロンドン大学tjvdmerwe@gmail.com
Victor Vasiliev Google vasilvv@google.com
Victor Vasiliev Google vasilvv@google.com
Hoeteck Wee Ecole Normale Superieure, Paris hoeteck@alum.mit.edu
Hoeteck Wee Ecole Normale Superieure、パリhoeteck@alum.mit.edu
Tom Weinstein
トム・ワインスタイン
David Wong NCC Group david.wong@nccgroup.trust
デビッドウォンNCCグループdavid.wong@nccgroup.trust
Christopher A. Wood Apple Inc. cawood@apple.com
クリストファー・A・ウッドApple Inc. cawood@apple.com
Tim Wright Vodafone timothy.wright@vodafone.com
ティム・ライト・ボーダフォンtimothy.wright@vodafone.com
Peter Wu Independent peter@lekensteyn.nl
ピーター・ウー・インディペンデントpeter@lekensteyn.nl
Kazu Yamamoto Internet Initiative Japan Inc. kazu@iij.ad.jp
山本和一インターネットイニシアティブジャパン株式会社kazu@iij.ad.jp
Author's Address
著者の住所
Eric Rescorla Mozilla
エリック・レスコーラ・モジラ
Email: ekr@rtfm.com