Internet Engineering Task Force (IETF) E. Rescorla
Request for Comments: 9846 Independent
Obsoletes: 5077, 5246, 6961, 7627, 8422, 8446 July 2026
Updates: 5705, 6066
Category: Standards Track
ISSN: 2070-1721
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.
この文書では、トランスポート層セキュリティ (TLS) プロトコルのバージョン 1.3 を指定します。TLS を使用すると、クライアント/サーバー アプリケーションは、盗聴、改ざん、メッセージ偽造を防ぐように設計された方法でインターネット経由で通信できるようになります。
This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations.
この文書は、TLS 1.3 を規定した RFC 8446 を廃止します。この文書は、RFC 5246 (TLS 1.2 を指定) および RFC 5077、6961、7627、および 8422 を廃止し、これらはすべて TLS 1.2 以前に関連し、RFC 5705 および 6066 を更新します。この文書は、TLS 1.2 実装の新しい要件も指定します。
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/rfc9846.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9846 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この文書には、2008 年 11 月 10 日より前に発行または一般公開された IETF 文書または IETF 寄稿の資料が含まれている場合があります。この資料の一部の著作権を管理している人物は、IETF 標準プロセス外でそのような資料の変更を許可する権利を IETF トラストに付与していない可能性があります。かかる資料の著作権を管理する者から適切なライセンスを取得しない限り、この文書を IETF 標準プロセスの外で変更することはできません。また、RFC として出版するための形式にするか、英語以外の言語に翻訳する場合を除き、IETF 標準プロセスの外でその派生著作物を作成することはできません。
1. Introduction
1.1. Conventions and Terminology
1.2. Relationship to RFC 8446
1.3. Major Differences from TLS 1.2
1.4. Updates Affecting TLS 1.2
2. Protocol Overview
2.1. Incorrect DHE Share
2.2. Resumption and Pre-Shared Key (PSK)
2.3. 0-RTT Data
3. Presentation Language
3.1. Basic Block Size
3.2. Miscellaneous
3.3. Numbers
3.4. Vectors
3.5. Enumerateds
3.6. Constructed Types
3.7. Constants
3.8. Variants
4. Handshake Protocol
4.1. The Transcript Hash
4.2. Key Exchange Messages
4.2.1. Cryptographic Negotiation
4.2.2. Client Hello
4.2.3. Server Hello
4.2.4. Hello Retry Request
4.3. Extensions
4.3.1. Supported Versions
4.3.2. Cookie
4.3.3. Signature Algorithms
4.3.4. Certificate Authorities
4.3.5. OID Filters
4.3.6. Post-Handshake Certificate-Based Client Authentication
4.3.7. Supported Groups
4.3.8. Key Share
4.3.9. Pre-Shared Key Exchange Modes
4.3.10. Early Data Indication
4.3.11. Pre-Shared Key Extension
4.4. Server Parameters
4.4.1. Encrypted Extensions
4.4.2. Certificate Request
4.5. Authentication Messages
4.5.1. Certificate
4.5.2. Certificate Verify
4.5.3. Finished
4.6. End of Early Data
4.7. Post-Handshake Messages
4.7.1. New Session Ticket Message
4.7.2. Post-Handshake Authentication
4.7.3. Key and Initialization Vector Update
5. Record Protocol
5.1. Record Layer
5.2. Record Payload Protection
5.3. Per-Record Nonce
5.4. Record Padding
5.5. Limits on Key Usage
6. Alert Protocol
6.1. Closure Alerts
6.2. Error Alerts
7. Cryptographic Computations
7.1. Key Schedule
7.2. Updating Traffic Secrets
7.3. Traffic Key Calculation
7.4. Asymmetric Shared Secret Calculation
7.4.1. Finite Field Diffie-Hellman
7.4.2. Elliptic Curve Diffie-Hellman
7.5. Exporters
8. 0-RTT and Anti-Replay
8.1. Single-Use Tickets
8.2. Client Hello Recording
8.3. Freshness Checks
9. Compliance Requirements
9.1. Mandatory-to-Implement Cipher Suites
9.2. Mandatory-to-Implement Extensions
9.3. Protocol Invariants
10. Security Considerations
11. IANA Considerations
11.1. Changes for this RFC
12. References
12.1. Normative References
12.2. Informative References
Appendix A. State Machine
A.1. Client
A.2. Server
Appendix B. Protocol Data Structures and Constant Values
B.1. Record Layer
B.2. Alert Messages
B.3. Handshake Protocol
B.3.1. Key Exchange Messages
B.3.2. Server Parameters Messages
B.3.3. Authentication Messages
B.3.4. Ticket Establishment
B.3.5. Updating Keys
B.4. Cipher Suites
Appendix C. Implementation Notes
C.1. Random Number Generation and Seeding
C.2. Certificates and Authentication
C.3. Implementation Pitfalls
C.4. Client and Server Tracking Prevention
C.5. Unauthenticated Operation
Appendix D. Updates to TLS 1.2
Appendix E. Backward Compatibility
E.1. Negotiating with an Older Server
E.2. Negotiating with an Older Client
E.3. 0-RTT Backward Compatibility
E.4. Middlebox Compatibility Mode
E.5. Security Restrictions Related to Backward Compatibility
Appendix F. Overview of Security Properties
F.1. Handshake
F.1.1. Key Derivation and HKDF
F.1.2. Certificate-Based Client Authentication
F.1.3. 0-RTT
F.1.4. Exporter Independence
F.1.5. Post-Compromise Security
F.1.6. External References
F.2. Record Layer
F.2.1. External References
F.3. Traffic Analysis
F.4. Side Channel Attacks
F.5. Replay Attacks on 0-RTT
F.5.1. Replay and Exporters
F.6. PSK Identity Exposure
F.7. Sharing PSKs Across Protocol Versions
F.8. External PSKs and Rerouting
F.9. Misbinding When Using Self-Signed Certificates or Raw
Public Keys
F.10. Attacks on Static RSA
Contributors
Author's Address
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) [DSS], or the Edwards-Curve Digital Signature Algorithm (EdDSA) [RFC8032]) or a symmetric pre-shared key (PSK).
* 認証: チャネルのサーバー側は常に認証されます。クライアント側はオプションで認証されます。認証は、非対称暗号化 (RSA [RSA]、楕円曲線デジタル署名アルゴリズム (ECDSA) [DSS]、エドワーズ曲線デジタル署名アルゴリズム (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 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 F for a more complete statement of the relevant security properties.
これらのプロパティは、[RFC3552] で説明されているように、ネットワークを完全に制御している攻撃者に直面した場合でも当てはまります。関連するセキュリティ プロパティの詳細については、付録 F を参照してください。
TLS consists of two primary components:
TLS は 2 つの主要なコンポーネントで構成されます。
* A handshake protocol (Section 4) that authenticates the communicating parties, negotiates cryptographic algorithms 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. Application protocols using TLS MUST specify how TLS works with their application protocol, including how and when handshaking occurs, and how to do identity verification. [RFC9525] provides useful guidance on integrating TLS with application protocols.
TLS はアプリケーション プロトコルに依存しません。上位レベルのプロトコルは透過的に TLS の上に重ねることができます。ただし、TLS 標準では、プロトコルが TLS でセキュリティを追加する方法は規定されていません。TLS ハンドシェイクを開始する方法と、交換される認証証明書を解釈する方法は、TLS 上で実行されるプロトコルの設計者と実装者の判断に任されています。TLS を使用するアプリケーション プロトコルは、ハンドシェイクがいつどのように発生するか、ID 検証を行う方法など、TLS がアプリケーション プロトコルとどのように連携するかを指定しなければなりません (MUST)。[RFC9525] は、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], the extended master secret extension [RFC7627], and elliptic curve definitions for TLS 1.2 [RFC8422]. 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; exporters no longer distinguish between having no context and having an empty context. It also changes how Online Certificate Status Protocol (OCSP) messages are carried and therefore updates [RFC6066] and obsoletes [RFC6961] as described in Section 4.5.1.1.
この文書は、バージョン 1.2 [RFC5246]、拡張マスター シークレット拡張 [RFC7627]、および TLS 1.2 の楕円曲線定義 [RFC8422] を含む、以前のバージョンの TLS に取って代わり、廃止します。また、[RFC5077] で定義されている TLS チケットメカニズムも廃止され、セクション 2.2 で定義されているメカニズムに置き換えられます。TLS 1.3 は鍵の導出方法を変更するため、セクション 7.5 で説明されているように [RFC5705] を更新します。エクスポーターは、コンテキストがないことと空のコンテキストがあることを区別しなくなりました。また、オンライン証明書ステータス プロトコル (OCSP) メッセージの伝送方法も変更されるため、セクション 4.5.1.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」、「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 接続を開始しなかったエンドポイント。
TLS 1.3 was originally specified in [RFC8446]. This document is a minor update to TLS 1.3 that retains the same version number and is backward compatible. It tightens some requirements and contains updated text in areas which were found to be unclear as well as other editorial improvements. In addition, it removes the use of the term "master" as applied to secrets in favor of the term "main" or shorter names where no term was necessary. This document makes the following specific technical changes:
TLS 1.3 は元々 [RFC8446] で規定されました。このドキュメントは TLS 1.3 へのマイナー アップデートであり、同じバージョン番号を維持し、下位互換性があります。いくつかの要件を強化し、不明瞭であることが判明した領域の更新されたテキストやその他の編集上の改善が含まれています。さらに、シークレットに適用される「マスター」という用語の使用が削除され、「メイン」という用語、または用語が必要ない短い名前が使用されます。このドキュメントでは、次のような特定の技術的な変更が加えられています。
* Forbid the reuse of KeyShare values between connections.
* 接続間での KeyShare 値の再利用を禁止します。
* Forbid negotiating TLS 1.0 and 1.1 as they are now deprecated by [RFC8996].
* TLS 1.0 および 1.1 は現在 [RFC8996] によって非推奨となっているため、ネゴシエーションを禁止します。
* Remove ambiguity around which hash is used with PreSharedKeys and HelloRetryRequest.
* PreSharedKeys と HelloRetryRequest でどのハッシュが使用されるかに関する曖昧さを解消します。
* Require that clients ignore NewSessionTicket if they do not support resumption.
* クライアントが再開をサポートしていない場合は、NewSessionTicket を無視するように要求します。
* Upgrade the requirement to initiate key update before exceeding key usage limits to MUST and clarified the scope of key usage limits.
* キーの使用制限を超える前にキーの更新を開始するという要件を「MUST」にアップグレードし、キーの使用制限の範囲を明確にしました。
* Limit the number of permitted KeyUpdate messages.
* 許可される KeyUpdate メッセージの数を制限します。
* Restore text defining the level of "close_notify" to "warning".
* 「close_notify」のレベルを定義するテキストを「警告」に戻します。
* Clarify behavior around "user_canceled", requiring that "close_notify" be sent and that "user_canceled" should be ignored.
* 「user_canceled」に関する動作を明確にし、「close_notify」を送信し、「user_canceled」を無視する必要があることを要求します。
* Add a "general_error" generic alert.
* 「general_error」汎用アラートを追加します。
* Correct the lower bound on CertificateRequest.extensions to be 0 bytes. This was an error in the syntax as it is possible to send no extensions, which results in length 0.
* CertificateRequest.extensions の下限を 0 バイトに修正します。拡張子を送信しないこともできるため、これは構文のエラーであり、その結果長さは 0 になります。
* Correct the lower bound on ClientHello.extensions. This was a calculation error.
* ClientHello.extensions の下限を修正します。これは計算ミスでした。
* Correct the upper bound on NewSessionTicket.extensions. This was a calculation error.
* NewSessionTicket.extensions の上限を修正します。これは計算ミスでした。
* Use more generic language for the asymmetric key exchange, which was previously exclusively (EC)DHE, to reflect the use of KEM-based key exchange.
* KEM ベースの鍵交換の使用を反映するために、以前は (EC)DHE のみであった非対称鍵交換に、より汎用的な言語を使用します。
* Clarify the interaction of the transcript hash with future specifications.
* トランスクリプト ハッシュと将来の仕様との相互作用を明確にします。
* Remove text requiring RSA PSS, matching [RFC9963].
* [RFC9963] に一致する RSA PSS を必要とするテキストを削除します。
In addition, there have been some improvements to the security considerations, especially around privacy.
さらに、セキュリティ、特にプライバシーに関する考慮事項がいくつか改善されました。
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).
* サポートされている対称暗号化アルゴリズムのリストからは、レガシーと考えられるすべてのアルゴリズムが削除されています。残っているものはすべて、Authenticated Encryption with Associated Data (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 function has 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 specification, 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 Probabilistic Signature Scheme (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.2.3.
* バージョンダウングレード保護メカニズムについては、セクション 4.2.3 で説明されています。
* RSASSA-PSS signature schemes are defined in Section 4.3.3.
* RSASSA-PSS 署名スキームはセクション 4.3.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 証明書でどの署名アルゴリズムを検証できるかを指定できます。
* The term "master" as applied to secrets has been removed, and the "extended_master_secret" extension [RFC7627] has been renamed to "extended_main_secret".
* シークレットに適用される「マスター」という用語は削除され、「extended_master_secret」拡張 [RFC7627] は「extended_main_secret」に名前変更されました。
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, authenticate each other (with client authentication being optional), 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 つの基本的な鍵交換モードをサポートします。
* asymmetric key exchange
* 非対称鍵交換
* PSK
* PSK
* combined PSK and asymmetric key exchange
* PSK と非対称鍵交換の組み合わせ
In this document, asymmetric key exchange includes Diffie-Hellman over either finite fields or elliptic curves. Other extensions define the use of key-encapsulation mechanisms (KEMs).
この文書では、非対称鍵交換には、有限体または楕円曲線上の Diffie-Hellman が含まれます。他の拡張機能では、キー カプセル化メカニズム (KEM) の使用を定義します。
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.
[] Indicates messages protected using keys
derived from [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.2.2) message, which contains a random nonce (ClientHello.random); its offered protocol versions; a list of symmetric cipher/hash pairs; either a list of asymmetric key exchange shares (in the "key_share" (Section 4.3.8) extension), a list of pre-shared key labels (in the "pre_shared_key" (Section 4.3.11) extension), or both; and potentially additional extensions. Additional fields and/or messages may also be present for middlebox compatibility.
鍵交換フェーズでは、クライアントはランダムな nonce (ClientHello.random) を含む ClientHello (セクション 4.2.2) メッセージを送信します。提供されているプロトコルのバージョン。対称暗号/ハッシュペアのリスト。非対称鍵交換共有のリスト (「key_share」 (セクション 4.3.8) 拡張内)、事前共有鍵ラベルのリスト (「pre_shared_key」 (セクション 4.3.11) 拡張内)、またはその両方。追加の拡張機能が追加される可能性もあります。ミドルボックスの互換性のために、追加のフィールドやメッセージが存在する場合もあります。
The server processes the ClientHello and determines the appropriate cryptographic parameters for the connection. It then responds with its own ServerHello (Section 4.2.3), which indicates the negotiated connection parameters. The combination of the ClientHello and the ServerHello determines the shared keys. If asymmetric key establishment is in use, then the ServerHello contains a "key_share" extension with the server's ephemeral asymmetric key exchange 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 asymmetric key exchange and PSK together, in which case both extensions will be supplied.
サーバーは ClientHello を処理し、接続に適切な暗号パラメータを決定します。次に、ネゴシエートされた接続パラメータを示す独自の ServerHello (セクション 4.2.3) で応答します。ClientHello と ServerHello の組み合わせによって共有キーが決まります。非対称キーの確立が使用されている場合、ServerHello にはサーバーの一時的な非対称キー交換共有を含む「key_share」拡張機能が含まれます。サーバーの共有は、クライアントの共有の 1 つと同じグループに属している必要があります。PSK キーの確立が使用されている場合、ServerHello には、クライアントが提供した PSK のどれが選択されたかを示す「pre_shared_key」拡張子が含まれます。実装では非対称鍵交換と 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.4.1]
個々の証明書に固有のものを除き、暗号化パラメータを決定するために必要のない ClientHello 拡張機能への応答。[セクション 4.4.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.4.2]
証明書ベースのクライアント認証が必要な場合は、その証明書に必要なパラメータ。クライアント認証が必要ない場合、このメッセージは省略されます。[セクション 4.4.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.5.1]
エンドポイントの証明書と証明書ごとの拡張子。このメッセージは、証明書で認証しない場合はサーバーによって省略され、サーバーが CertificateRequest を送信しなかった場合はクライアントによって省略されます (したがって、クライアントが証明書で認証すべきではないことを示します)。生の公開鍵 [RFC7250] またはキャッシュ情報拡張子 [RFC7924] が使用されている場合、このメッセージには証明書が含まれるのではなく、サーバーの長期鍵に対応する他の値が含まれることに注意してください。[セクション4.5.1]
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.5.2]
証明書メッセージ内の公開キーに対応する秘密キーを使用したハンドシェイク全体の署名。エンドポイントが証明書を介して認証されていない場合、このメッセージは省略されます。[セクション 4.5.2]
Finished:
終了した：
A MAC (Message Authentication Code) over the entire handshake. This message provides key confirmation for the shared secrets established in the handshake, binds the endpoint's identity to the exchanged keys, and in PSK mode also authenticates the handshake. [Section 4.5.3]
ハンドシェイク全体にわたる MAC (メッセージ認証コード)。このメッセージは、ハンドシェイクで確立された共有秘密のキー確認を提供し、交換されたキーにエンドポイントの ID をバインドし、PSK モードではハンドシェイクも認証します。[セクション4.5.3]
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 メッセージを送信する前に送信してはなりません (MUST NOT)。サーバーはクライアントの認証メッセージを受信する前にアプリケーション データを送信する可能性がありますが、その時点で送信されるデータは当然、認証されていないピアに送信されることに注意してください。
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
図 2: パラメータが一致しないフル ハンドシェイクのメッセージ フロー
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 externally, 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.7.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.7.1 を参照)。その後、クライアントは今後のハンドシェイクでその PSK ID を使用して、関連付けられた PSK の使用をネゴシエートできます。サーバーが PSK を受け入れる場合、新しい接続のセキュリティ コンテキストは元の接続に暗号的に関連付けられ、最初のハンドシェイクから得られたキーを使用して、完全なハンドシェイクの代わりに暗号状態をブートストラップします。TLS 1.2 以前では、この機能は「セッション ID」と「セッション チケット」[RFC5077] によって提供されていました。どちらのメカニズムも TLS 1.3 では廃止されます。
PSKs can be used with asymmetric key exchange 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 は、非対称キー交換で使用して共有キーと組み合わせて前方機密性を提供することも、アプリケーション データの前方機密性を失うという犠牲を払って単独で使用することもできます。
Figure 3 shows a pair of handshakes in which the first handshake establishes a PSK and the second handshake uses it:
図 3 は、最初のハンドシェイクで PSK を確立し、2 番目のハンドシェイクでそれを使用する 1 組のハンドシェイクを示しています。
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*
+ psk_key_exchange_modes
+ 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 asymmetric key establishment, thus providing forward secrecy.
サーバーは PSK を介して認証しているため、証明書または CertificateVerify メッセージを送信しません。クライアントが PSK 経由で再開を提案する場合、必要に応じてサーバーが再開を拒否し、完全なハンドシェイクにフォールバックできるように、「key_share」拡張機能もサーバーに提供する必要があります (SHOULD)。サーバーは、「pre_shared_key」拡張子で応答して PSK キー確立の使用をネゴシエートし、(ここに示すように)「key_share」拡張子で応答して非対称キーの確立を行うことができるため、前方機密性が提供されます。
When PSKs are provisioned externally, the PSK identity and the KDF hash algorithm to be used with the PSK MUST also be provisioned.
PSK が外部でプロビジョニングされる場合、PSK で使用される PSK ID と KDF ハッシュ アルゴリズムもプロビジョニングされなければなりません (MUST)。
Note: When using an externally 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 asymmetric 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 認証は、非対称キーの確立で使用された場合でも、強力なパスワード ベースの認証済みキー交換ではありません。具体的には、ハンドシェイクを監視できる攻撃者がパスワード/事前共有キーに対してブルート フォース攻撃を実行することを防ぐことはできません。
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.
{} Indicates messages protected using keys
derived from a [sender]_handshake_traffic_secret.
[] Indicates messages protected using keys
derived from [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. The protocol does not provide any forward secrecy guarantees for this data. The server's behavior determines what forward secrecy guarantees, if any, apply (see Section 8.1). This behavior is not communicated to the client as part of the protocol. Therefore, absent out-of-band knowledge of the server's behavior, the client should assume that this data is not forward secret.
1. このプロトコルは、このデータに対する前方機密性の保証を提供しません。サーバーの動作によって、どの前方秘匿性保証が適用されるかが決まります (セクション 8.1 を参照)。この動作は、プロトコルの一部としてクライアントに伝達されません。したがって、サーバーの動作に関する帯域外の知識がなければ、クライアントはこのデータが前方秘密ではないと想定する必要があります。
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_secret.
2. 接続間で再生が行われないという保証はありません。通常の TLS 1.3 1-RTT データのリプレイに対する保護はサーバーのランダム値によって提供されますが、0-RTT データは ServerHello に依存しないため、保証が弱くなります。これは、データが TLS クライアント認証またはアプリケーション プロトコル内で認証される場合に特に関係します。同じ警告が、early_exporter_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 F.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 データのように見せることはできません (異なるキーで保護されているため)。付録 F.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.
このドキュメントでは、外部表現におけるデータのフォーマットについて説明します。次の非常に基本的で、ややカジュアルに定義されたプレゼンテーション構文が使用されます。
In the definitions below, optional components of this syntax are denoted by enclosing them in "[[ ]]" (double brackets).
以下の定義では、この構文のオプションのコンポーネントは、「[[ ]]」 (二重括弧) で囲むことによって示されます。
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 "*/".
コメントは「/*」で始まり「*/」で終わります。
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. For presentation purposes, this specification refers to vectors as lists. 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 つの連続したバイトとして定義されていますが、データは 3 つの連続したデータであり、合計 9 バイトを消費します。
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.
可変長ベクトルは、<floor..ceiling> という表記を使用して、有効な長さの部分範囲を指定することによって定義されます。これらがエンコードされると、実際の長さはバイト ストリーム内のベクトルの内容よりも前に置かれます。長さは、ベクトルの指定された最大 (上限) 長さを保持するために必要なバイト数を消費する数値の形式になります。実際の長さフィールドが 0 の可変長ベクトルは、空ベクトルと呼ばれます。
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 list (vector) fields are allowed using the standard list 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.
定義された構造には、環境内で利用可能な知識に基づいたバリアントが存在する場合があります。セレクターは、構造体が定義する可能なバリアントを定義する列挙型である必要があります。select の各アーム (以下) は、そのバリアントのフィールドのタイプとオプションのフィールド ラベルを指定します。実行時にバリアントが選択されるメカニズムは、プレゼンテーション言語によって規定されていません。
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.1 and shown in the diagrams in Section 2, unless modified by a TLS extension. A peer which receives a handshake message in an unexpected order MUST abort the handshake with an "unexpected_message" alert.
プロトコルメッセージは、TLS 拡張によって変更されない限り、セクション 4.1 で定義され、セクション 2 の図に示されている順序で送信されなければなりません (MUST)。予期しない順序でハンドシェイク メッセージを受信したピアは、「unexpected_message」アラートでハンドシェイクを中止しなければなりません (MUST)。
New handshake message types are assigned by IANA as described in Section 11.
新しいハンドシェイク メッセージ タイプは、セクション 11 で説明されているように IANA によって割り当てられます。
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" (254) containing Hash(ClientHello1). I.e.,
この一般規則の例外として、サーバーが HelloRetryRequest で ClientHello に応答する場合、ClientHello1 の値は、Hash(ClientHello1) を含むハンドシェイク タイプ「message_hash」(254) の特別な合成ハンドシェイク メッセージに置き換えられます。つまり、
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.3.2).
この構造の理由は、サーバーが中間ハッシュ状態全体をエクスポートすることを要求するのではなく、ClientHello1 のハッシュのみを Cookie に保存することでステートレスな HelloRetryRequest を実行できるようにするためです (セクション 4.3.2 を参照)。
When a range of messages is specified with "...", the transcript hash is taken from the sequence of handshake messages that were sent or received during the main handshake, starting and ending at the specified messages. In this document, it is taken from the following sequence of handshake messages (some of which might be omitted): ClientHello, HelloRetryRequest, ClientHello, ServerHello, EncryptedExtensions, server CertificateRequest, server Certificate, server CertificateVerify, server Finished, EndOfEarlyData, client Certificate, client CertificateVerify, and client Finished. TLS extensions may add or remove messages, in which case the transcript hash will reflect the modified sequence.
メッセージの範囲を「...」で指定すると、トランスクリプト ハッシュは、メイン ハンドシェイク中に送受信された、指定されたメッセージで開始および終了する一連のハンドシェイク メッセージから取得されます。このドキュメントでは、次の一連のハンドシェイク メッセージ (一部は省略される場合があります) から取得されています: ClientHello、HelloRetryRequest、ClientHello、ServerHello、EncryptedExtensions、server CertificateRequest、server Certificate、server CertificateVerify、server Finished、EndOfEarlyData、client Certificate、client CertificateVerify、および client Finished。TLS 拡張機能はメッセージを追加または削除する場合があり、その場合、トランスクリプト ハッシュには変更されたシーケンスが反映されます。
In general, implementations can implement the transcript by keeping a running transcript hash value based on the negotiated hash, once the hash has been selected in the ServerHello.
一般に、実装では、ServerHello でハッシュが選択されると、ネゴシエートされたハッシュに基づいて実行中のトランスクリプトのハッシュ値を保持することで、トランスクリプトを実装できます。
Note, however, that subsequent post-handshake authentications do not include each other, just the messages through the end of the main handshake.
ただし、後続のハンドシェイク後の認証には相互の認証は含まれず、メイン ハンドシェイクの終了までのメッセージのみが含まれることに注意してください。
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.3.7) extension which indicates the key exchange groups which the client supports and a "key_share" (Section 4.3.8) extension which contains key exchange shares for some or all of these groups. The term "groups" is historical, dating from the original version of TLS 1.3, which did not support non-DHE key key establishment algorithms).
* クライアントがサポートする鍵交換グループを示す "supported_groups" (セクション 4.3.7) 拡張子と、これらのグループの一部またはすべての鍵交換共有を含む "key_share" (セクション 4.3.8) 拡張子。「グループ」という用語は歴史的なもので、非 DHE キー確立アルゴリズムをサポートしていなかった TLS 1.3 のオリジナル バージョンからのものです。
* A "signature_algorithms" (Section 4.3.3) extension which indicates the signature algorithms which the client can accept. A "signature_algorithms_cert" extension (Section 4.3.3) may also be added to indicate certificate-specific signature algorithms.
* クライアントが受け入れることができる署名アルゴリズムを示す「signature_algorithms」(セクション 4.3.3) 拡張子。証明書固有の署名アルゴリズムを示すために、「signature_algorithms_cert」拡張子 (セクション 4.3.3) を追加することもできます。
* A "pre_shared_key" (Section 4.3.11) extension which contains a list of symmetric key identities known to the client and a "psk_key_exchange_modes" (Section 4.3.9) extension which indicates the key exchange modes that may be used with PSKs.
* クライアントに既知の対称鍵 ID のリストを含む「pre_shared_key」(セクション 4.3.11) 拡張機能と、PSK で使用できる鍵交換モードを示す「psk_key_exchange_modes」(セクション 4.3.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 asymmetric key exchange 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 つは完全に直交します。サーバーは、暗号スイート、鍵確立のための非対称鍵交換グループと鍵共有、およびクライアントに対して自身を認証するための署名アルゴリズムと証明書のペアを独立して選択します。受信した "supported_groups" とサーバーがサポートするグループの間に重複がない場合、サーバーは "handshake_failure" または "insufficient_security" アラートでハンドシェイクを中止しなければなりません (MUST)。
If the server selects a PSK, then it MUST also select a key establishment mode from the list indicated by the client's "psk_key_exchange_modes" extension (at present, PSK alone or with asymmetric key exchange). Note that if the PSK can be used without asymmetric key exchange, 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 単独または非対称鍵交換を使用)。非対称キー交換なしで PSK を使用できる場合は、前の段落で説明した非 PSK の場合のように、「supported_groups」パラメータの非重複が致命的になる必要はないことに注意してください。
If the server selects an asymmetric key exchange 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.2.4) message.
サーバーが非対称鍵交換グループを選択し、クライアントが最初の ClientHello で互換性のある「key_share」拡張を提供しなかった場合、サーバーは HelloRetryRequest (セクション 4.2.4) メッセージで応答しなければなりません (MUST)。
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 asymmetric key exchange is in use, the server will also provide a "key_share" extension. If PSK is not being used, then asymmetric key exchange and certificate-based authentication are always used.
* 非対称鍵交換が使用されている場合、サーバーは「key_share」拡張機能も提供します。PSK が使用されていない場合は、非対称キー交換と証明書ベースの認証が常に使用されます。
* When authenticating via a certificate, the server will send the Certificate (Section 4.5.1) and CertificateVerify (Section 4.5.2) 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.
* 証明書を介して認証する場合、サーバーは Certificate (セクション 4.5.1) および CertificateVerify (セクション 4.5.2) メッセージを送信します。この文書で定義されている 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:
クライアントが初めてサーバーに接続するときは、最初の TLS メッセージとして ClientHello を送信する必要があります。サーバーがその ClientHello に HelloRetryRequest で応答した場合、クライアントは 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.3.10) if one was present. Early data is not permitted after a HelloRetryRequest.
* 「early_data」拡張子 (セクション 4.3.10) が存在する場合は削除します。HelloRetryRequest 後の初期データは許可されません。
* Including a "cookie" extension if one was provided in the HelloRetryRequest.
* 「cookie」拡張子が HelloRetryRequest で提供されている場合は、これを含めます。
* 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 を受信した場合、以前のプロトコル バージョンを保持しなければなりません (MUST)。特に、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<7..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.3.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 E for details about backward compatibility.) A server which receives a legacy_version value not equal to 0x0303 MUST abort the handshake with a "protocol_version" alert.
以前のバージョンの TLS では、このフィールドはバージョン ネゴシエーションに使用され、クライアントがサポートする最高のバージョン番号を表していました。経験上、多くのサーバーはバージョン ネゴシエーションを適切に実装しておらず、サポートされているバージョン番号よりも高いバージョン番号を持つ通常は許容される ClientHello をサーバーが拒否する「バージョン不寛容」につながることがわかっています。TLS 1.3 では、クライアントは「supported_versions」拡張機能 (セクション 4.3.1) でバージョン設定を示し、legacy_version フィールドは TLS 1.2 のバージョン番号である 0x0303 に設定しなければなりません (MUST)。TLS 1.3 ClientHello は、legacy_version が 0x0303 であり、supported_versions 拡張子がその中で示される最高バージョンとして 0x0304 を持つものとして識別されます。(下位互換性の詳細については、付録 E を参照してください。) 0x0303 に等しくない Legacy_version 値を受信したサーバーは、「protocol_version」アラートでハンドシェイクを中止しなければなりません (MUST)。
random:
ランダム：
32 bytes generated by a secure random number generator. See Appendix C for additional information.
安全な乱数発生器によって生成される 32 バイト。詳細については、付録 C を参照してください。
legacy_session_id:
レガシーセッション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 E.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 list (i.e., a zero-valued single byte length field).
TLS 1.3 より前のバージョンの TLS は「セッション再開」機能をサポートしていましたが、このバージョンでは事前共有キーと統合されました (セクション 2.2 を参照)。TLS 1.3 以前のサーバーによって設定されたキャッシュされたセッション ID を持つクライアントは、このフィールドをその値に設定すべきです (SHOULD)。互換モード (付録 E.4 を参照) では、このフィールドは空であってはなりません (MUST)。そのため、TLS 1.3 以前のセッションを提供していないクライアントは、新しい 32 バイト値を生成しなければなりません (MUST)。この値はランダムである必要はありませんが、実装が特定の値に固執すること（骨化とも呼ばれる）を避けるために、予測不可能であるべきです。それ以外の場合は、長さ 0 のリスト (つまり、値が 0 の 1 バイト長フィールド) として設定しなければなりません (MUST)。
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.
クライアントによってサポートされている対称暗号オプションのリスト、特にレコード保護アルゴリズム (秘密キーの長さを含む) と HKDF で使用されるハッシュ (クライアントの優先順位の降順)。値は付録 B.4 で定義されています。サーバーが認識、サポートしていない、または使用を希望していない暗号スイートがリストに含まれている場合、サーバーはそれらの暗号スイートを無視し、残りの暗号スイートを通常どおり処理しなければなりません(MUST)。クライアントが PSK 鍵の確立を試みている場合、PSK に関連付けられたハッシュを示す少なくとも 1 つの暗号スイートをアドバタイズする必要があります (SHOULD)。
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 list 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.
1.3 より前のバージョンの TLS は、このフィールドで送信されるサポートされる圧縮方法のリストによる圧縮をサポートしていました。すべての TLS 1.3 ClientHello について、このリストにはゼロに設定された 1 バイトが含まれていなければなりません (MUST)。これは、TLS の以前のバージョンの「null」圧縮方式に対応します。このフィールドに他の値が含まれる TLS 1.3 ClientHello を受信した場合、サーバーは「illegal_parameter」アラートでハンドシェイクを中止しなければなりません (MUST)。TLS 1.3 サーバーは、他の圧縮方式を含む TLS 1.2 またはそれ以前の ClientHello を受信する可能性があるため、(そのような以前のバージョンをネゴシエートする場合は) TLS の適切な以前のバージョンの手順に従わなければならないことに注意してください。
extensions:
拡張子:
Clients request extended functionality from servers by sending data in the extensions field. The actual "Extension" format is defined in Section 4.3. 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.
クライアントは、拡張フィールドにデータを送信することで、サーバーに拡張機能を要求します。実際の「拡張」形式はセクション 4.3 で定義されます。TLS 1.3 では、TLS の以前のバージョンとの ClientHello 互換性を維持するために機能が拡張機能に移行されているため、特定の拡張機能の使用が必須です。サーバーは、認識できない拡張子を無視しなければなりません (MUST)。
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 の後にデータが含まれていないこと、またはその後にデータのない有効な拡張ブロックが含まれていることを確認しなければなりません (MUST)。そうでない場合は、「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.
クライアントが拡張機能を使用して追加の機能を要求し、その機能がサーバーによって提供されない場合、クライアントはハンドシェイクを中止してもよい(MAY)。
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.3.1), and the legacy_version field MUST be set to 0x0303, which is the version number for TLS 1.2. (See Appendix E for details about backward compatibility.) A client which receives a TLS 1.3 Server Hello with a legacy_version value not equal to 0x0303 MUST abort the handshake with a "protocol_version" alert.
TLS の以前のバージョンでは、このフィールドはバージョン ネゴシエーションに使用され、接続に対して選択されたバージョン番号を表していました。残念ながら、一部のミドルボックスは新しい値が与えられると失敗します。TLS 1.3 では、TLS サーバーは「supported_versions」拡張子 (セクション 4.3.1) を使用してそのバージョンを示し、legacy_version フィールドは TLS 1.2 のバージョン番号である 0x0303 に設定しなければなりません (MUST)。(下位互換性の詳細については、付録 E を参照してください。) 0x0303 に等しくない Legacy_version 値を持つ TLS 1.3 Server Hello を受信したクライアントは、「protocol_version」アラートでハンドシェイクを中止しなければなりません (MUST)。
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.
安全な乱数発生器によって生成される 32 バイト。詳細については、付録 C を参照してください。TLS 1.2 または TLS 1.1 をネゴシエートする場合、最後の 8 バイトは以下で説明するように上書きされなければなりません (MUST) が、残りのバイトはランダムでなければなりません (MUST)。この構造はサーバーによって生成され、ClientHello.random とは独立して生成されなければなりません (MUST)。
legacy_session_id_echo:
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フィールドの内容。このフィールドは、クライアントの値が、サーバーが再開しないことを選択した、キャッシュされた TLS 1.3 以前のセッションに対応する場合でもエコーされることに注意してください。ClientHello で送信したものと一致しない Legacy_session_id_echo フィールドを受信したクライアントは、「illegal_parameter」アラートでハンドシェイクを中止しなければなりません (MUST)。
cipher_suite:
暗号スイート:
The single cipher suite selected by the server from the ClientHello.cipher_suites list. A client which receives a cipher suite that was not offered MUST abort the handshake with an "illegal_parameter" alert.
サーバーによって ClientHello.cipher_suites リストから選択された単一の暗号スイート。提供されていない暗号スイートを受け取ったクライアントは、「illegal_parameter」アラートを出してハンドシェイクを中止しなければなりません(MUST)。
legacy_compression_method:
従来の圧縮方法:
A single byte which MUST have the value 0. If a TLS 1.3 ServerHello is received with any other value in this field, the client MUST abort the handshake with an "illegal_parameter" alert.
値 0 を持たなければならない 1 バイト。このフィールドに他の値を持つ TLS 1.3 ServerHello を受信した場合、クライアントは「illegal_parameter」アラートでハンドシェイクを中止しなければなりません。
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 asymmetric key establishment). Other extensions (see Section 4.3) are sent separately in the EncryptedExtensions message.
拡張子のリスト。ServerHello には、暗号化コンテキストを確立し、プロトコル バージョンをネゴシエートするために必要な拡張機能のみを含めなければなりません (MUST)。すべての TLS 1.3 ServerHello メッセージには、「supported_versions」拡張子が含まれている必要があります。現在の ServerHello メッセージには、さらに「pre_shared_key」拡張子または「key_share」拡張子のいずれか、または両方が含まれています (非対称キー確立で PSK を使用する場合)。他の拡張機能 (セクション 4.3 を参照) は、EncryptedExtensions メッセージで個別に送信されます。
For reasons of backward compatibility with middleboxes (see Appendix E.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":
ミドルボックスとの下位互換性のため (付録 E.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.2.4.
タイプserver_helloのメッセージを受信すると、実装は最初にRandom値を検査し、それがこの値と一致する場合、セクション4.2.4で説明されているように処理しなければなりません(MUST)。
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 に Random 値の最後の 8 バイトを設定しなければなりません (MUST)。
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
[RFC8996] and Appendix E.5 forbid the negotiation of TLS versions below 1.2. However, server implementations which do not follow that guidance MUST set the last 8 bytes of their ServerHello.random value to the bytes:
[RFC8996] と付録 E.5 は、1.2 より前の TLS バージョンのネゴシエーションを禁止しています。ただし、そのガイダンスに従わないサーバー実装では、ServerHello.random 値の最後の 8 バイトを次のバイトに設定する必要があります。
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 バイトがこれらの値のいずれにも等しくないことを確認しなければなりません (MUST)。ServerHello が TLS 1.1 以下を示している場合、TLS 1.2 クライアントは最後の 8 バイトが 2 番目の値と等しくないこともチェックする必要があります (SHOULD)。一致が見つかった場合、クライアントは「illegal_parameter」アラートを発行してハンドシェイクを中止しなければなりません(MUST)。このメカニズムは、Finished 交換によって提供されるもの以上のダウングレード攻撃に対する限定的な保護を提供します。TLS 1.2 以下に存在するメッセージである ServerKeyExchange には、両方のランダム値に対する署名が含まれているため、一時的な暗号が使用されている限り、アクティブな攻撃者が検出されずにランダム値を変更することは不可能です。静的 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」アラートでハンドシェイクを中止しなければなりません (MUST)。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.2.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.2.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. 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.3.2) extension.
サーバーの拡張機能には「supported_versions」が含まれている必要があります。さらに、クライアントが正しい ClientHello ペアを生成するために必要な拡張機能の最小限のセットを含める必要があります (SHOULD)。HelloRetryRequest には、オプションの「cookie」拡張子 (セクション 4.3.2 を参照) を除き、ClientHello でクライアントによって最初に提供されていない拡張子を含めてはなりません (MUST NOT)。
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.2.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.2.3 で指定されているとおり、legacy_version、legacy_session_id_echo、cipher_suite、legacy_compression_method をチェックし、「supported_versions」を使用してバージョンを決定することから始めて、拡張機能を処理しなければなりません (MUST)。HelloRetryRequest によって ClientHello が変更されない場合、クライアントは「illegal_parameter」アラートでハンドシェイクを中止しなければなりません (MUST)。クライアントが同じ接続内で 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.3.1)
* Supported_versions (セクション 4.3.1 を参照)
* cookie (see Section 4.3.2)
* Cookie (セクション 4.3.2 を参照)
* key_share (see Section 4.3.8)
* key_share (セクション 4.3.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.
提供されていない暗号スイートを受け取ったクライアントは、ハンドシェイクを中止しなければなりません (MUST)。サーバーは、準拠して更新された 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 では、クライアントは、選択された暗号スイート以外のハッシュに関連付けられた事前共有キーを提供してはなりません (SHOULD NOT)。これにより、クライアントは 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 に保持されなければなりません (MUST)。値が変更された場合、クライアントは "illegal_parameter" アラートでハンドシェイクを中止しなければなりません (MUST)。
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, 9261 */
status_request(5), /* RFC 6066, 9846 */
supported_groups(10), /* RFC 7919, 9846 */
signature_algorithms(13), /* RFC 9846 */
use_srtp(14), /* RFC 5764 */
heartbeat(15), /* RFC 6520 */
application_layer_protocol_negotiation(16), /* RFC 7301 */
client_certificate_type(19), /* RFC 7250 */
server_certificate_type(20), /* RFC 7250 */
padding(21), /* RFC 7685 */
compress_certificate(27), /* RFC 8879 */
record_size_limit(28), /* RFC 8449 */
delegated_credential(34), /* RFC 9345 */
supported_ekt_ciphers(39), /* RFC 8870 */
pre_shared_key(41), /* RFC 9846 */
early_data(42), /* RFC 9846 */
supported_versions(43), /* RFC 9846 */
cookie(44), /* RFC 9846 */
psk_key_exchange_modes(45), /* RFC 9846 */
certificate_authorities(47), /* RFC 9846 */
oid_filters(48), /* RFC 9846 */
post_handshake_auth(49), /* RFC 9846 */
signature_algorithms_cert(50), /* RFC 9846 */
key_share(51), /* RFC 9846 */
transparency_info(52), /* RFC 9162 */
external_id_hash(55), /* RFC 8844 */
external_session_id(56), /* RFC 8844 */
quic_transport_parameters(57), /* RFC 9001 */
ticket_request(58), /* RFC 9149 */
ech_outer_extensions(64768), /* RFC 9849 */
encrypted_client_hello(65037), /* RFC 9849 */
(65535)
} ExtensionType;
Note: This list includes only extensions marked "Recommended" and allowed for TLS 1.3 at the time of this writing.
注: このリストには、この記事の執筆時点で「推奨」とマークされ、TLS 1.3 で許可されている拡張子のみが含まれています。
Here:
ここ：
* "extension_type" identifies the particular extension type.
* 「extension_type」は、特定の拡張タイプを識別します。
* "extension_data" contains information specific to the particular extension type.
* 「extension_data」には、特定の拡張タイプに固有の情報が含まれます。
The contents of the "extension_data" field are typically defined by an extension-specific structure defined in the TLS presentation language. Unless otherwise specified, trailing data is forbidden. That is, senders MUST NOT include data after the structure in the "extension_data" field. When processing an extension, receivers MUST abort the handshake with a "decode_error" alert if there is data left over after parsing the structure. This does not apply if the receiver does not implement or is configured to ignore an extension.
「extension_data」フィールドの内容は、通常、TLS プレゼンテーション言語で定義された拡張固有の構造によって定義されます。特に指定がない限り、後続データは禁止されます。つまり、送信者は「extension_data」フィールドの構造体の後にデータを含めてはなりません。拡張機能を処理するとき、構造を解析した後にデータが残っている場合、受信者は「decode_error」アラートでハンドシェイクを中止しなければなりません(MUST)。これは、受信側が拡張機能を実装していない場合、または拡張機能を無視するように構成されている場合には適用されません。
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 requests with no corresponding response (i.e., indications). 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 メッセージで拡張リクエストを送信し、クライアントはこれに Certificate メッセージで応答できます (MAY)。サーバーは、NewSessionTicket で一方的な拡張機能を送信してもよい (MAY)。ただし、クライアントはこれらに直接応答しない。
Implementations MUST NOT send extension responses (i.e., in the ServerHello, EncryptedExtensions, HelloRetryRequest, and Certificate messages) 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" 拡張を除き、リモート エンドポイントが対応する拡張リクエストを送信しなかった場合、実装は拡張応答 (つまり、ServerHello、EncryptedExtensions、HelloRetryRequest、および Certificate メッセージ) を送信してはなりません (MUST NOT)。このような拡張を受信すると、エンドポイントは「unsupported_extension」アラートを出してハンドシェイクを中止しなければなりません(MUST)。
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 (証明書)、CR (CertificateRequest)、NST (NewSessionTicket)、および HRR (HelloRetryRequest) の表記を使用して、特定の拡張子が表示されるメッセージを示しています。実装が認識する拡張子を受け取った場合、その拡張子が表示されるメッセージに指定されていない場合は、「illegal_parameter」アラートでハンドシェイクを中止しなければなりません(MUST)。
+==================================================+=============+
| Extension | TLS 1.3 |
+==================================================+=============+
| server_name [RFC6066] [RFC9261] | CH, EE, CR |
+--------------------------------------------------+-------------+
| status_request [RFC6066] [RFC9846] | CH, CR, CT |
+--------------------------------------------------+-------------+
| supported_groups [RFC7919] [RFC9846] | CH, EE |
+--------------------------------------------------+-------------+
| signature_algorithms [RFC9846] | CH, CR |
+--------------------------------------------------+-------------+
| use_srtp [RFC5764] | CH, EE |
+--------------------------------------------------+-------------+
| heartbeat [RFC6520] | CH, EE |
+--------------------------------------------------+-------------+
| application_layer_protocol_negotiation [RFC7301] | CH, EE |
+--------------------------------------------------+-------------+
| client_certificate_type [RFC7250] | CH, EE |
+--------------------------------------------------+-------------+
| server_certificate_type [RFC7250] | CH, EE |
+--------------------------------------------------+-------------+
| padding [RFC7685] | CH |
+--------------------------------------------------+-------------+
| compress_certificate [RFC8879] | CH, CR |
+--------------------------------------------------+-------------+
| record_size_limit [RFC8449] | CH, EE |
+--------------------------------------------------+-------------+
| delegated_credential [RFC9345] | CH, CR, CT |
+--------------------------------------------------+-------------+
| supported_ekt_ciphers [RFC8870] | CH, EE |
+--------------------------------------------------+-------------+
| pre_shared_key [RFC9846] | CH, SH |
+--------------------------------------------------+-------------+
| early_data [RFC9846] | CH, EE, NST |
+--------------------------------------------------+-------------+
| supported_versions [RFC9846] | CH, SH, HRR |
+--------------------------------------------------+-------------+
| cookie [RFC9846] | CH, HRR |
+--------------------------------------------------+-------------+
| psk_key_exchange_modes [RFC9846] | CH |
+--------------------------------------------------+-------------+
| certificate_authorities [RFC9846] | CH, CR |
+--------------------------------------------------+-------------+
| oid_filters [RFC9846] | CR |
+--------------------------------------------------+-------------+
| post_handshake_auth [RFC9846] | CH |
+--------------------------------------------------+-------------+
| signature_algorithms_cert [RFC9846] | CH, CR |
+--------------------------------------------------+-------------+
| key_share [RFC9846] | CH, SH, HRR |
+--------------------------------------------------+-------------+
| transparency_info [RFC9162] | CH, CR, CT |
+--------------------------------------------------+-------------+
| external_id_hash [RFC8844] | CH, EE |
+--------------------------------------------------+-------------+
| external_session_id [RFC8844] | CH, EE |
+--------------------------------------------------+-------------+
| quic_transport_parameters [RFC9001] | CH, EE |
+--------------------------------------------------+-------------+
| ticket_request [RFC9149] | CH, EE |
+--------------------------------------------------+-------------+
| ech_outer_extensions [RFC9849] | CH |
+--------------------------------------------------+-------------+
| encrypted_client_hello [RFC9849] | CH, HRR, EE |
+--------------------------------------------------+-------------+
Table 1: TLS Extensions
表 1: TLS 拡張機能
Note: This table includes only extensions marked "Recommended" and allowed for TLS 1.3 at the time of this writing.
注: この表には、この記事の執筆時点で「推奨」とマークされ、TLS 1.3 で許可されている拡張子のみが含まれています。
When multiple extensions of different types are present, the extensions MAY appear in any order, with the exception of "pre_shared_key" (Section 4.3.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 の最後の拡張機能でなければならない (ただし、ServerHello 拡張機能ブロックのどこにでも表示できます) を除いて、任意の順序で表示できます (MAY)。特定の拡張ブロック内に同じタイプの拡張が複数存在してはなりません。
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.3.10).
TLS 1.3 では、TLS 1.2 とは異なり、再開 PSK モードの場合でもハンドシェイクごとに拡張がネゴシエートされます。ただし、0-RTT パラメータは前のハンドシェイクでネゴシエートされたパラメータです。不一致がある場合は、0-RTT を拒否する必要がある場合があります (セクション 4.3.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 のネゴシエーションが許可されている場合は、それらも存在しなければなりません)。
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.
この拡張機能が存在しない場合、この仕様に準拠し、TLS 1.2 もサポートするサーバーは、たとえ ClientHello.legacy_version が 0x0304 以降であっても、[RFC5246] で指定されているように TLS 1.2 以前とネゴシエートしなければなりません (MUST)。サーバーは、legacy_version 0x0304 以降の ClientHello を受信するとハンドシェイクを中止してもよい (MAY)。
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" 拡張のみを使用しなければなりません (MUST)。サーバーは、その拡張機能に存在する TLS のバージョンのみを選択しなければならず (MUST)、その拡張機能に存在する未知のバージョンは無視しなければなりません (MUST)。このメカニズムにより、一方の側がスパース範囲をサポートしている場合、TLS 1.2 より前のバージョンをネゴシエートできることに注意してください。以前のバージョンの TLS をサポートすることを選択した TLS 1.3 の実装は、TLS 1.2 をサポートする必要があります (SHOULD)。サーバーは、この拡張子を含むがバージョンのリストに 0x0304 を含まない ClientHello を受信できるように準備しなければなりません (MUST)。
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).
TLS 1.3 より前のバージョンの TLS をネゴシエートするサーバーは、ServerHello.version を設定しなければならず、「supported_versions」拡張子を送信してはなりません。TLS 1.3 をネゴシエートするサーバーは、選択されたバージョン値 (0x0304) を含む「supported_versions」拡張子を送信して応答しなければなりません。ServerHello.legacy_version フィールドを 0x0303 (TLS 1.2) に設定する必要があります。
After checking ServerHello.random to determine if the server handshake message is a ServerHello or HelloRetryRequest, clients MUST check for this extension prior to processing the rest of the ServerHello. This will require clients to parse the ServerHello 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.
ServerHello.random をチェックしてサーバー ハンドシェイク メッセージが ServerHello か HelloRetryRequest かを判断した後、クライアントは残りの ServerHello を処理する前にこの拡張子をチェックしなければなりません (MUST)。これには、クライアントが ServerHello を解析して拡張機能を読み取る必要があります。この拡張機能が存在する場合、クライアントは ServerHello.legacy_version 値を無視し、選択されたバージョンを決定するために "supported_versions" 拡張機能のみを使用しなければなりません (MUST)。ServerHello の "supported_versions" 拡張機能にクライアントによって提供されていないバージョンが含まれている場合、または TLS 1.3 より前のバージョンが含まれている場合、クライアントは "illegal_parameter" アラートでハンドシェイクを中止しなければなりません (MUST)。
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 [RFC9147] for an example of this).
* サーバーがクライアントに、見かけ上のネットワーク アドレスでの到達可能性を実証できるようにします (これにより、DoS 保護の手段が提供されます)。これは主に、非接続指向のトランスポートに役立ちます (この例については [RFC9147] を参照)。
* 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」拡張子を提供してもよい(MAY) (これは、送信できる拡張子は ClientHello に表示される拡張子のみであるという通常の規則の例外である)。新しい ClientHello を送信するとき、クライアントは HelloRetryRequest で受信した拡張機能の内容を新しい ClientHello の「Cookie」拡張機能にコピーしなければなりません (MUST)。クライアントは、その後の接続で最初の ClientHello で Cookie を使用してはなりません (MUST NOT)。
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 を参照)。サーバーは状態を保存していないため、これが最初に受信されたメッセージであるかのように表示されます。ステートレスに動作するサーバーは、これらのレコードを無視しなければなりません (MUST)。
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」拡張子は証明書内の署名に適用され、「signature_algorithms」拡張子は元々 TLS 1.2 で登場し、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 実装もこの拡張機能を処理すべきです (SHOULD)。どちらの場合も同じポリシーを持つ実装では、「signature_algorithms_cert」拡張子を省略してもよい(MAY)。
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:
RSASSA-PKCS1-v1_5 アルゴリズム:
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.5.1.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 [RFC8017] と、[SHS] で定義されている対応するハッシュ アルゴリズムを使用する署名アルゴリズムを示します。これらの値は、証明書 (セクション 4.5.1.2 を参照) に表示される署名のみを参照し、署名付き TLS ハンドシェイク メッセージで使用するために定義されていません。ただし、TLS 1.2 との下位互換性のために、「signature_algorithms」および「signature_algorithms_cert」に表示されてもよい[MAY]。
ECDSA algorithms:
ECDSA アルゴリズム:
Indicates a signature algorithm using ECDSA [DSS], the corresponding curve as defined in NIST SP 800-186 [ECDP], and the corresponding hash algorithm as defined in [SHS]. The signature is represented as a DER-encoded [X690] ECDSA-Sig-Value structure as defined in [RFC4492].
ECDSA [DSS] を使用した署名アルゴリズム、NIST SP 800-186 [ECDP] で定義されている対応する曲線、および [SHS] で定義されている対応するハッシュ アルゴリズムを示します。署名は、[RFC4492] で定義されている DER エンコードされた [X690] ECDSA-Sig-Value 構造として表されます。
RSASSA-PSS RSAE algorithms:
RSASSA-PSS RSAE アルゴリズム:
Indicates a signature algorithm using RSASSA-PSS with a mask generation function of MGF1, as defined in [RFC8017]. The digest used in MGF1 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 [RFC3279].
[RFC8017]で定義されている、MGF1のマスク生成機能を備えたRSASSA-PSSを使用する署名アルゴリズムを示します。MGF1 で使用されるダイジェストと署名されるダイジェストは両方とも、[SHS] で定義されている対応するハッシュ アルゴリズムです。ソルトの長さは、ダイジェスト アルゴリズムの出力の長さと等しくなければなりません。公開鍵が X.509 証明書で運ばれる場合、rsaEncryption OID [RFC3279] を使用しなければなりません (MUST)。
EdDSA algorithms:
EdDSA アルゴリズム:
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.
[RFC8032] またはその後継で定義されている EdDSA を使用した署名アルゴリズムを示します。これらは「PureEdDSA」アルゴリズムに対応し、「プレハッシュ」バリアントには対応しないことに注意してください。
RSASSA-PSS PSS algorithms:
RSASSA-PSS PSS アルゴリズム:
Indicates a signature algorithm using RSASSA-PSS with a mask generation function of MGF1, as defined in [RFC8017]. The digest used in MGF1 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.
[RFC8017]で定義されている、MGF1のマスク生成機能を備えたRSASSA-PSSを使用する署名アルゴリズムを示します。MGF1 で使用されるダイジェストと署名されるダイジェストは両方とも、[SHS] で定義されている対応するハッシュ アルゴリズムです。ソルトの長さは、ダイジェスト アルゴリズムの長さと等しくなければなりません。公開鍵が X.509 証明書で伝送される場合、RSASSA-PSS OID [RFC5756] を使用しなければなりません (MUST)。証明書の署名で使用する場合、アルゴリズム パラメーターは 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.5.1.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.5.1.2).
既知の弱点のあるアルゴリズム、具体的には、(1) RSASSA-PKCS1-v1_5 を使用する RSA または (2) ECDSA のいずれかでこのコンテキストで使用される SHA-1 を使用しているため、非推奨になるアルゴリズムを示します。これらの値は、証明書 (セクション 4.5.1.2 を参照) に表示される署名のみを参照し、署名付き TLS ハンドシェイク メッセージで使用するために定義されていません。ただし、TLS 1.2 との下位互換性のために、「signature_algorithms」および「signature_algorithms_cert」に表示されてもよい[MAY]。エンドポイントはこれらのアルゴリズムをネゴシエートすべきではありませんが、下位互換性のためだけにネゴシエートすることは許可されています。これらの値を提供するクライアントは、それらを最も低い優先順位としてリストしなければなりません (SignatureSchemeList 内の他のすべてのアルゴリズムの後にリストされます)。TLS 1.3 サーバーは、SHA-1 署名付き証明書なしでは有効な証明書チェーンを作成できない場合を除き、SHA-1 署名付き証明書を提供してはなりません (セクション 4.5.1.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" and "signature_algorithms_cert" extensions.
自己署名証明書またはトラストアンカーである証明書の署名は、証明書パスの始まりであるため、検証されません ([RFC5280]、セクション 3.2 を参照)。認証パスを開始する証明書は、「signature_algorithms」および「signature_algorithms_cert」拡張機能でサポートされているとして公表されていない署名アルゴリズムを使用してもよい（MAY）。
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.3 implementations willing to negotiate TLS 1.2 MUST behave in accordance with the requirements of [RFC5246] when negotiating that version.特に：
* TLS 1.2 ClientHellos MAY omit this extension.
* TLS 1.2 ClientHellos は、この拡張子を省略してもよい(MAY)。
* 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」拡張でアドバタイズされた任意の曲線を使用する署名を受け入れる準備をしなければなりません (MUST)。
* 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 がネゴシエートされている場合でも、そのスキームを使用した署名を受け入れる準備ができていなければなりません (MUST)。TLS 1.2 では、RSASSA-PSS が RSA 暗号スイートとともに使用されます。
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.
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」拡張子を送信してもよい(MAY)。サーバーはそれをCertificateRequestメッセージで送信してもよい(MAY)。
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 list 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 メッセージでのみ送信されなければなりません (MUST)。
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 がすべて含まれていなければなりません (MUST)。クライアントによって認識される各拡張 OID について、指定されたすべての値がクライアント証明書に存在しなければなりません (ただし、証明書には他の値があってもよい)。ただし、クライアントは、認識されない証明書拡張 OID を無視してスキップしなければなりません (MUST)。クライアントが必要な証明書拡張 OID の一部を無視し、要求を満たさない証明書を提供した場合、サーバーはその裁量で、クライアント認証なしで接続を継続するか、「unsupported_certificate」アラートを出してハンドシェイクを中止してもよい(MAY)。特定の 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 をリクエストで使用してはなりません (MUST NOT)。
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.7.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.7.2)。サーバーは、この拡張機能を提供しないクライアントにハンドシェイク後の CertificateRequest を送信してはなりません (MUST NOT)。サーバーはこの拡張機能を送信してはなりません。
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.3.3).
注: TLS 1.3 より前のバージョンの TLS では、この拡張機能は「elliptic_curves」という名前で、楕円曲線グループのみが含まれていました。[RFC8422] および [RFC7919] を参照してください。この拡張は、ECDSA 曲線をネゴシエートするためにも使用されました。署名アルゴリズムは独立してネゴシエートされるようになりました (セクション 4.3.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):
楕円曲線グループ (ECDHE):
Indicates support for the corresponding named curve, defined in either NIST SP 800-186 [ECDP] or in [RFC7748]. Values 0xFE00 through 0xFEFF are reserved for Private Use [RFC8126].
NIST SP 800-186 [ECDP] または [RFC7748] で定義された、対応する名前付き曲線のサポートを示します。値 0xFE00 から 0xFEFF は私的使用のために予約されています [RFC8126]。
Finite Field Groups (DHE):
有限体グループ (DHE):
Indicates support for the corresponding finite field group, defined in [RFC7919]. Values 0x01FC through 0x01FF are reserved for Private Use.
[RFC7919] で定義されている、対応する有限体グループのサポートを示します。値 0x01FC ～ 0x01FF は私的使用のために予約されています。
Items in "named_group_list" are ordered according to the sender's preferences (most preferred choice first). The "named_group_list" MUST NOT contain any duplicate entries. A recipient MAY abort a connection with a fatal "illegal_parameter" alert if it detects a duplicate entry.
「named_group_list」内の項目は、送信者の設定に従って順序付けされます (最も好ましい選択肢が最初に表示されます)。「named_group_list」には重複したエントリを含めてはなりません。受信者は、重複エントリを検出した場合、致命的な「illegal_parameter」アラートを出して接続を中止してもよい(MAY)。
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」を送信して、その設定に関するクライアントのビューを更新する必要があります (SHOULD)。この拡張機能には、クライアントによって現在サポートされているかどうかに関係なく、サーバーがサポートするすべてのグループが含まれるべきです(SHOULD)。
The "key_share" extension contains the endpoint's cryptographic parameters.
「key_share」拡張子には、エンドポイントの暗号化パラメータが含まれています。
Clients MAY send an empty client_shares list to request group selection from the server, at the cost of an additional round trip (see Section 4.2.4).
クライアントは、追加のラウンドトリップを犠牲にして、空の client_shares リストを送信してサーバーからのグループ選択を要求してもよい(MAY) (セクション 4.2.4 を参照)。
struct {
NamedGroup group;
opaque key_exchange<1..2^16-1>;
} KeyShareEntry;
group:
グループ：
The named group for the key being exchanged.
交換されるキーの名前付きグループ。
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.3.8.1; Elliptic Curve Diffie-Hellman parameters are described in Section 4.3.8.2.
鍵交換情報。このフィールドの内容は、指定されたグループとそれに対応する定義によって決まります。有限体 Diffie-Hellman [DH76] パラメータについては、セクション 4.3.8.1 で説明されています。楕円曲線 Diffie-Hellman パラメータについては、セクション 4.3.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:
client_shares:
A list of offered KeyShareEntry values in descending order of client preference.
提供された KeyShareEntry 値のリスト (クライアントの優先順位の降順)。
This list 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 をリクエストしている場合、このリストは空であってもよい (MAY)。各 KeyShareEntry 値は、「supported_groups」拡張で提供されるグループに対応しなければならず、同じ順序で出現しなければなりません。ただし、値は「supported_groups」拡張子の非連続サブセットであってもよく、最も優先されるグループを省略してもよいです。このような状況は、最も優先されるグループが新しく、そのグループに対するキー共有を効率的に事前生成するのに十分な場所でサポートされそうにない場合に発生する可能性があります。
For this reason, the omission of a share for group A and inclusion of one for group B does not mean that the client prefers B to A. Selecting a group based on KeyShareEntry may result in the use of a less preferred group than the client and server mutually support, though saving the round trip of HelloRetryRequest. Servers that wish to respect the client's group preferences SHOULD first select a group based on "supported_groups" and then either send a ServerHello or a HelloRetryRequest depending on the contents of KeyshareClientHello.
このため、グループ A の共有を省略してグループ B の共有を含めることは、クライアントが A よりも B を優先することを意味するものではありません。KeyShareEntry に基づいてグループを選択すると、HelloRetryRequest の往復は節約されますが、クライアントとサーバーが相互にサポートするグループよりも優先度の低いグループが使用される可能性があります。クライアントのグループ設定を尊重したいサーバーは、まず「supported_groups」に基づいてグループを選択し、次に KeyshareClientHello の内容に応じて ServerHello または HelloRetryRequest を送信する必要があります (SHOULD)。
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 値は個別に生成されなければなりません (MUST)。クライアントは、同じグループに対して複数の KeyShareEntry 値を提供してはなりません。クライアントは、クライアントの「supported_groups」拡張にリストされていないグループに対して KeyShareEntry 値を提供してはなりません。サーバーはこれらのルールの違反をチェックし、違反した場合は「illegal_parameter」アラートを出してハンドシェイクを中止してもよい(MAY)。
Clients and Servers MUST NOT reuse a key share for multiple connections. Because [RFC8446] permitted reuse, receiving implementations MUST permit reuse by the peer in order to prevent interoperability issues.
クライアントとサーバーは、複数の接続にキー共有を再利用してはなりません。[RFC8446] では再利用が許可されているため、受信実装は相互運用性の問題を防ぐためにピアによる再利用を許可しなければなりません (MUST)。
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.
サーバーがネゴシエートする予定であり、再試行された 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 のみを含む拡張子に置き換えなければなりません (MUST)。
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.
クライアントの共有の 1 つと同じグループにある単一の KeyShareEntry 値。
If using asymmetric 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 asymmetric 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.
非対称キーの確立を使用する場合、サーバーは ServerHello で KeyShareEntry を 1 つだけ提供します。この値は、サーバーがネゴシエートされた鍵交換用に選択した、クライアントによって提供される KeyShareEntry 値と同じグループ内になければなりません。サーバーは、クライアントの「supported_groups」拡張で示されていないグループに対して KeyShareEntry を送信してはなりません。また、「psk_ke」PskKeyExchangeMode を使用する場合は KeyShareEntry を送信してはなりません。非対称キーの確立を使用し、「key_share」拡張子を含む HelloRetryRequest がクライアントによって受信された場合、クライアントは、ServerHello で選択された NamedGroup が HelloRetryRequest の NamedGroup と同じであることを確認しなければなりません (MUST)。このチェックが失敗した場合、クライアントは「illegal_parameter」アラートを出してハンドシェイクを中止しなければなりません(MUST)。
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 を検証しなければなりません (MUST)。このチェックにより、リモート ピアが適切に動作し、ローカル システムを小さなサブグループに強制的に所属させていないことが確認されます。
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 Appendix D.1 of [ECDP] 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 を検証しなければなりません (MUST)。適切な検証手順は [ECDP] の付録 D.1、または [KEYAGREEMENT] のセクション 5.6.2.3 で定義されています。このプロセスは 3 つのステップで構成されます: (1) Q が無限遠点 (O) ではないことを確認する、(2) Q = (x, y) の場合、整数 x と y が両方とも正しい区間内にあることを確認する、(3) (x, y) が楕円曲線方程式の正しい解であることを確認する。これらの曲線の場合、実装者は正しいサブグループのメンバーシップを検証する必要はありません。
For X25519 and X448, the content of the public value is the K_A or K_B value described in Section 6 of [RFC7748]. This is 32 bytes for X25519 and 56 bytes for X448.
X25519 および X448 の場合、公開値の内容は [RFC7748] のセクション 6 に記載されている K_A または K_B 値です。これは、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 ではこの機能が削除され、各曲線の単一ポイント形式が採用されています。
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」を提供した場合、サーバーはハンドシェイクを中止しなければなりません(MUST)。サーバーは、クライアントによってリストされていない鍵交換モードを選択してはなりません。この拡張機能は、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_ke:
PSK-only key establishment. In this mode, the server MUST NOT supply a "key_share" value.
PSK のみのキーの確立。このモードでは、サーバーは「key_share」値を提供してはなりません。
psk_dhe_ke:
psk_dhe_ke:
PSK with asymmetric key establishment (the label "dhe" is historical, dating from the original version of TLS 1.3, which did not support non-DHE key key establishment algorithms). In this mode, the client and server MUST supply "key_share" values as described in Section 4.3.8.
非対称キー確立を使用した PSK (ラベル「dhe」は歴史的なもので、非 DHE キー確立アルゴリズムをサポートしていなかった TLS 1.3 のオリジナル バージョンからのものです)。このモードでは、クライアントとサーバーはセクション 4.3.8 で説明されているように「key_share」値を提供しなければなりません (MUST)。
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 (see for instance Appendix B.3.4), 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 に対して初期データが許可されている場合 (たとえば付録 B.3.4 を参照)、クライアントは最初のメッセージ フライトでアプリケーション データを送信できます。クライアントがそうすることを選択した場合、「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.7.1 for details regarding the use of the max_early_data_size field.
max_early_data_size フィールドの使用方法の詳細については、セクション 4.7.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」拡張子を含めてはなりません (MUST NOT)。その後、サーバーは、外部コンテンツ タイプが "application_data" (暗号化されていることを示す) を持つすべてのレコードを、構成された max_early_data_size までスキップすることにより、初期データを無視します。
* 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 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:
初期のデータを受け入れるために、サーバーはクライアントの「pre_shared_key」拡張で提供される最初のキーを選択しなければなりません。さらに、次の値が、選択された PSK に関連付けられている値と同じであることを確認する必要があります。
* The selected 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.
これらの要件は、問題の PSK を使用して 1-RTT ハンドシェイクを実行するために必要な要件のスーパーセットです。
Future extensions MUST define their interaction with 0-RTT.
将来の拡張機能では、0-RTT との相互作用を定義しなければなりません (MUST)。
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 ハンドシェイク キーを使用するか、HelloRetryRequest の場合は平文 ClientHello を探すことによって) を使用して、最初の 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" アラートを出して接続を終了しなければなりません (MUST)。
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」拡張子を拒否した場合、クライアント アプリケーションは、ハンドシェイクの完了後に、以前に初期データで送信されたアプリケーション データを再送信することを選択してもよい(MAY)。初期のデータを自動再送信すると、接続ステータスに関して誤った仮定が生じる可能性があることに注意してください。たとえば、ネゴシエートされた接続で初期のデータに使用されたものとは異なる 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 実装は初期データを自動的に再送信すべきではありません。アプリケーションは、再送信がいつ適切であるかを判断するのに有利な立場にあります。TLS 実装は、ネゴシエートされた接続が同じ ALPN プロトコルを選択しない限り、初期データを自動的に再送信してはなりません (MUST NOT)。
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.
キーのラベル。たとえば、チケット (付録 B.3.4 で定義) や、外部で確立された事前共有キーのラベルなどです。
obfuscated_ticket_age:
obfuscated_ticket_age:
An obfuscated version of the age of the key. Section 4.3.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.
鍵の年齢の難読化されたバージョン。セクション 4.3.11.1 では、NewSessionTicket メッセージを通じて確立された ID に対してこの値を形成する方法について説明します。外部で確立された ID の場合、obfuscated_ticket_age の 0 を使用する必要があり (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.3.10), the first identity is the one used for 0-RTT data.
クライアントがサーバーとネゴシエートすることを希望する ID のリスト。「early_data」拡張子 (セクション 4.3.10 を参照) と一緒に送信された場合、最初の ID は 0-RTT データに使用されるものです。
binders:
バインダー:
A series of HMAC values, one for each value in the identities list and in the same order, computed as described below.
一連の HMAC 値 (ID リストの各値に 1 つずつ、同じ順序で) は、以下で説明するように計算されます。
selected_identity:
選択されたアイデンティティ:
The server's chosen identity expressed as a (0-based) index into the identities in the client's "OfferedPsks.identities" list.
サーバーが選択した ID は、クライアントの「OfferedPsks.identities」リスト内の ID への (0 ベースの) インデックスとして表現されます。
Each PSK is associated with a single Hash algorithm. For PSKs established via the ticket mechanism (Section 4.7.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.7.1) を介して確立された PSK の場合、これはチケットが確立された接続上の KDF ハッシュ アルゴリズムです。外部で確立された PSK の場合、PSK が確立されるときにハッシュ アルゴリズムを設定する必要があります。そのようなアルゴリズムが定義されていない場合は、デフォルトで SHA-256 を設定する必要があります。サーバーは、互換性のある PSK (存在する場合) と暗号スイートを選択することを確認しなければなりません (MUST)。
In TLS versions prior to TLS 1.3, the Server Name Indication (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.7.1.
TLS 1.3 より前の TLS バージョンでは、Server Name Indication (SNI) 値はセッションに関連付けられることが意図されており ([RFC6066] のセクション 3)、サーバーはセッションに関連付けられた SNI 値が再開ハンドシェイクで指定された値と一致することを強制する必要がありました。ただし、実際には、提供された 2 つの SNI 値のどちらを使用するかについて実装に一貫性がなく、一貫性要件が事実上クライアントによって強制されることになりました。TLS 1.3 では、SNI 値は再開ハンドシェイクで常に明示的に指定され、サーバーが SNI 値をチケットに関連付ける必要はありません。ただし、クライアントは、セクション 4.7.1 の要件を満たすために、PSK とともに SNI を保存する必要があります (SHOULD)。
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 ハンドシェイクを実行する必要があります (SHOULD)。下位互換性が重要な場合、クライアントが提供し、外部で確立された PSK が暗号スイートの選択に影響を与えるべきです(SHOULD)。
Prior to accepting PSK key establishment, the server MUST validate the corresponding binder value (see Section 4.3.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 F.6 for the security rationale for this requirement. To accept PSK key establishment, the server sends a "pre_shared_key" extension indicating the selected identity.
PSK キーの確立を受け入れる前に、サーバーは対応するバインダー値を検証しなければなりません (下記のセクション 4.3.11.2 を参照)。この値が存在しないか検証されない場合、サーバーはハンドシェイクを中止しなければなりません (MUST)。サーバーは複数のバインダーを検証しようとしてはなりません。むしろ、単一の PSK を選択し、その PSK に対応するバインダーのみを検証する必要があります (SHOULD)。この要件のセキュリティ理論的根拠については、セクション 8.2 および付録 F.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 であることを確認しなければなりません（MUST）。他の値が返された場合、クライアントは「illegal_parameter」アラートでハンドシェイクを中止しなければなりません（MUST）。
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.7.1), modulo 2^32. This addition prevents passive observers from correlating connections unless tickets or key shares 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.7.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.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.1 を参照) 上の HMAC として計算されます。つまり、ClientHello はすべて含まれますが、バインダー リスト自体は含まれません。メッセージの長さフィールド (全体の長さ、拡張ブロックの長さ、「pre_shared_key」拡張の長さを含む) はすべて、正しい長さのバインダーが存在するかのように設定されます。
The PskBinderEntry is computed in the same way as the Finished message (Section 4.5.3) 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.5.3) と同じ方法で計算されますが、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. Note that this hash will be computed using the hash associated with the PSK, as the client does not know which cipher suite the server will select.
ここで、Truncate() は ClientHello からバインダー リストを削除します。クライアントはサーバーがどの暗号スイートを選択するかを知らないため、このハッシュは PSK に関連付けられたハッシュを使用して計算されることに注意してください。
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.1. Note that the "message_hash" will be hashed with the negotiated function, which may or may not match the hash associated with the PSK. This is consistent with how the transcript is calculated for the rest of the handshake.
完全な ClientHello1/ClientHello2 は、他のすべてのハンドシェイク ハッシュ計算に含まれます。最初のフライトでは Truncate(ClientHello1) が直接ハッシュされますが、セクション 4.1 で説明されているように、2 番目のフライトでは ClientHello1 がハッシュされてから「message_hash」メッセージとして再挿入されることに注意してください。「message_hash」はネゴシエートされた関数でハッシュ化されますが、PSK に関連付けられたハッシュと一致する場合と一致しない場合があることに注意してください。これは、残りのハンドシェイクのトランスクリプトの計算方法と一致しています。
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. 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」を受け入れるとき、サーバーはクライアントの EndOfEarlyData メッセージを待ってから ServerHello を送信するのではなく、クライアントの ClientHello を処理してからすぐに一連のメッセージを送信しなければなりません (MUST)。
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 メッセージを送信しなければなりません (MUST)。これは、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 をチェックしなければなりません (MUST)。もし見つかった場合は、「illegal_parameter」アラートでハンドシェイクを中止しなければなりません (MUST)。
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.3.
拡張子のリスト。詳細については、セクション 4.3 の表を参照してください。
A server which is authenticating with a certificate MAY optionally request a certificate from the client. This message, if sent, MUST follow EncryptedExtensions.
証明書で認証しているサーバーは、オプションでクライアントに証明書を要求してもよい(MAY)。このメッセージを送信する場合は、EncryptedExtensions に従わなければなりません。
Structure of this message:
このメッセージの構造:
struct {
opaque certificate_request_context<0..2^8-1>;
Extension extensions<0..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.7.2. When requesting post-handshake authentication, the server SHOULD make the context unpredictable to the client (e.g., by randomly generating it) to prevent an attacker who has temporary access to the client's private key from pre-computing valid CertificateVerify messages.
証明書要求を識別し、クライアントの証明書メッセージでエコーされる不透明な文字列。certificate_request_context は、この接続のスコープ内で一意である必要があります (したがって、クライアントの CertificateVerify メッセージの再生が防止されます)。このフィールドは、セクション 4.7.2 で説明されているハンドシェイク後の認証交換に使用されない限り、長さはゼロでなければなりません (SHALL)。ハンドシェイク後の認証をリクエストするとき、サーバーは、クライアントの秘密鍵に一時的にアクセスできる攻撃者が有効な CertificateVerify メッセージを事前に計算することを防ぐために、クライアントにとってコンテキストを予測不可能にする必要があります (SHOULD)。
extensions:
拡張子:
A list 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」拡張子を指定する必要があり、このメッセージに定義されている場合は、他の拡張子をオプションで含めることができます。クライアントは、認識できない拡張子を無視しなければなりません (MUST)。
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.3.4).
以前のバージョンの TLS では、CertificateRequest メッセージには、サーバーが受け入れる署名アルゴリズムと認証局のリストが含まれていました。TLS 1.3 では、前者は「signature_algorithms」拡張子と、オプションで「signature_algorithms_cert」拡張子を送信することによって表現されます。後者は、「certificate_authorities」拡張機能を送信することで表現されます (セクション 4.3.4 を参照)。
Servers which are authenticating with a resumption PSK MUST NOT send the CertificateRequest message in the main handshake, though they MAY send it in post-handshake authentication (see Section 4.7.2) provided that the client has sent the "post_handshake_auth" extension (see Section 4.3.6). In the absence of some other specification to the contrary, servers which are authenticating with an external PSK MUST NOT send the CertificateRequest message in the main handshake or request post-handshake authentication. [RFC8773] provides an extension to permit this but has received less analysis than this specification.
再開 PSK で認証しているサーバーは、クライアントが "post_handshake_auth" 拡張子 (セクション 4.3.6 を参照) を送信した場合に限り、ハンドシェイク後の認証 (セクション 4.7.2 を参照) でそれを送信してもよいが、メイン ハンドシェイクで CertificateRequest メッセージを送信してはなりません (MUST NOT)。これとは反対の仕様が他にない限り、外部 PSK で認証しているサーバーは、メイン ハンドシェイクで CertificateRequest メッセージを送信したり、ハンドシェイク後の認証を要求してはなりません (MUST NOT)。[RFC8773] はこれを許可する拡張を提供していますが、この仕様よりも少ない分析しか行われていません。
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, except for post-handshake authentication.
セクション 2 で説明したように、TLS は通常、認証、キーの確認、ハンドシェイクの整合性のために、Certificate、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 list 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).
認証に使用される証明書、およびチェーン内のサポートされる証明書。証明書ベースのクライアント認証は、PSK ハンドシェイク フロー (0-RTT を含む) では利用できないことに注意してください。
CertificateVerify:
証明書検証:
A signature over the value Transcript-Hash(Handshake Context, Certificate).
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.
ベース キーから派生した 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 ... |server_handshake_traffic_secret|
| |later of | |
| |EncryptedExtensions/| |
| |CertificateRequest | |
+--------------+--------------------+-------------------------------+
|Client |ClientHello ... |client_handshake_traffic_secret|
| |later of server | |
| |Finished/ | |
| |EndOfEarlyData | |
+--------------+--------------------+-------------------------------+
|Post-Handshake|ClientHello ... |[sender]_application_traffic_ |
| |client Finished + |secret_N |
| |CertificateRequest | |
+--------------+--------------------+-------------------------------+
Table 2: Authentication Inputs
表 2: 認証入力
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 certificate-based client authentication via a CertificateRequest message (Section 4.4.2). If the server requests certificate-based 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.4.2) を介して証明書ベースのクライアント認証を要求した場合に限り、証明書メッセージを送信しなければなりません (MUST)。サーバーが証明書ベースのクライアント認証を要求したが、適切な証明書が利用できない場合、クライアントは証明書を含まない(つまり、「certificate_list」フィールドの長さが0の)証明書メッセージを送信しなければなりません(MUST)。Certificate メッセージが空かどうかに関係なく、Finished メッセージを送信しなければなりません (MUST)。
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.
このメッセージが CertificateRequest に対する応答である場合、そのメッセージ内のcertificate_request_contextの値。それ以外の場合 (サーバー認証の場合)、このフィールドの長さはゼロでなければなりません(SHALL)。
certificate_list:
証明書リスト:
A list (chain) of CertificateEntry structures, each containing a single certificate and list of extensions.
CertificateEntry 構造のリスト (チェーン)。それぞれに 1 つの証明書と拡張機能のリストが含まれます。
extensions:
拡張子:
A list of extension values for the CertificateEntry. The "Extension" format is defined in Section 4.3. 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.
CertificateEntry の拡張値のリスト。「拡張」形式はセクション 4.3 で定義されています。現時点でサーバー証明書の有効な拡張には、OCSP Status 拡張 [RFC6066] および SignedCertificateTimestamp 拡張 [RFC6962] が含まれます。このメッセージに対して将来の拡張も定義される可能性があります。サーバーからの証明書メッセージの拡張子は、ClientHello メッセージの拡張子に対応する必要があります。クライアントからの Certificate メッセージの拡張子は、サーバーからの CertificateRequest メッセージの拡張子に対応しなければなりません (MUST)。拡張子がチェーン全体に適用される場合、最初の CertificateEntry に拡張子を含める必要があります (SHOULD)。
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 になければなりません。後続の各証明書は、その直前の証明書を直接認証する必要があります (SHOULD)。証明書の検証ではトラスト アンカーが独立して配布されることが必要なため、サポートされているピアが省略された証明書を所有していることがわかっている限り、トラスト アンカーを指定する証明書をチェーンから省略してもよい(MAY)。
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 バージョンからの任意の順序を処理できるように準備する必要があります (SHOULD)。
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 では使用してはなりません。
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は常に空であってはなりません(MUST)。クライアントは、サーバーの認証要求に応答して送信する適切な証明書がない場合、空の証明書リストを送信します。
[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 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.
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 応答を提示することを要求してもよい(MAY)。クライアントが 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 client or server:
クライアントまたはサーバーによって送信される証明書には、次のルールが適用されます。
* The certificate type MUST be X.509v3 [RFC5280], unless explicitly negotiated otherwise (e.g., [RFC7250]).
* 明示的にネゴシエートされない限り ([RFC7250] など)、証明書タイプは X.509v3 [RFC5280] でなければなりません。
* The end-entity certificate MUST allow the key to be used for signing with a signature scheme indicated in the peer's "signature_algorithms" extension (see Section 4.3.3). That is, the digitalSignature bit MUST be set if the Key Usage extension is present, and the public key (with associated restrictions) MUST be compatible with some supported signature scheme.
* エンドエンティティ証明書は、ピアの "signature_algorithms" 拡張で示される署名スキームでの署名に鍵を使用できるようにしなければなりません (セクション 4.3.3 を参照)。つまり、Key Use 拡張機能が存在する場合は、digitalSignature ビットを設定しなければならず、公開鍵 (関連する制限付き) は、サポートされている署名スキームと互換性がなければなりません (MUST)。
* If the peer sent a "certificate_authorities" extension, at least one of the certificates in the certificate chain SHOULD be issued by one of the listed CAs.
* ピアが「certificate_authorities」拡張を送信した場合、証明書チェーン内の少なくとも 1 つの証明書は、リストされている CA のいずれかによって発行されるべきです (SHOULD)。
The following rule additionally applies to certificates sent by the client:
さらに、次のルールがクライアントによって送信される証明書に適用されます。
* 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.3.5.
* CertificateRequest メッセージに空ではない「oid_filters」拡張子が含まれている場合、セクション 4.3.5 で説明されているように、エンドエンティティ証明書はクライアントによって認識される拡張子 OID と一致しなければなりません (MUST)。
The following rule additionally applies to certificates sent by the server:
さらに、次のルールがサーバーによって送信される証明書に適用されます。
* The "server_name" [RFC6066] extension is used to guide certificate selection. As servers MAY require the presence of the "server_name" extension, clients SHOULD send this extension when the server is identified by name.
* "server_name" [RFC6066] 拡張子は、証明書の選択をガイドするために使用されます。サーバーは「server_name」拡張子の存在を必要とする場合があります(MAY)ので、サーバーが名前で識別される場合、クライアントはこの拡張子を送信すべきです(SHOULD)。
All certificates provided by the sender MUST be signed by a signature algorithm advertised by the peer, if it is able to provide such a chain (see Section 4.3.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.3.3 を参照)。自己署名された証明書、またはトラストアンカーであることが期待される証明書はチェーンの一部として検証されないため、任意のアルゴリズムで署名されてもよい(MAY)。
If the sender is the server, and the server cannot produce a certificate chain that is signed only via the indicated supported algorithms, then it SHOULD continue the handshake by sending a certificate chain of its choice that may include algorithms that are not known to be supported by the client. This fallback chain MUST NOT use the deprecated SHA-1 hash, unless the client specifically advertises that it is willing to accept SHA-1.
送信者がサーバーであり、サーバーが、指定されたサポートされているアルゴリズムを介してのみ署名された証明書チェーンを生成できない場合、サーバーは、クライアントによってサポートされていることが知られていないアルゴリズムを含む可能性のある、選択した証明書チェーンを送信することによってハンドシェイクを続行すべきです(SHOULD)。このフォールバック チェーンは、クライアントが SHA-1 を受け入れる意思があることを明確に通知しない限り、非推奨の SHA-1 ハッシュを使用してはなりません (MUST NOT)。
If the sender is the client, the client MAY use a fallback chain as above or continue the handshake anonymously.
送信者がクライアントの場合、クライアントは上記のようにフォールバック チェーンを使用するか、匿名でハンドシェイクを継続してもよい(MAY)。
If the receiver 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 を参照) を発行してハンドシェイクを中止しなければなりません (MUST)。
If the sender 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).
送信者が複数の証明書を持っている場合は、(トランスポート層のエンドポイント、ローカル構成、設定などの他の基準に加えて) 前述の基準に基づいてそのうちの 1 つを選択します。
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」アラートを出してハンドシェイクを中止しなければなりません(MUST)。
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」アラートを発行してハンドシェイクを中止してもよい(MAY)。また、証明書チェーンの一部が受け入れられない場合 (例、既知の信頼できる CA によって署名されていない場合)、サーバーはその裁量で、(クライアントが認証されていないとみなして) ハンドシェイクを続行するか、ハンドシェイクを中止してもよい(MAY)。
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」アラートでハンドシェイクを中止しなければなりません (MUST)。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).
ある署名アルゴリズムの鍵を含む証明書は、別の署名アルゴリズム (たとえば、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 メッセージは、この時点までのハンドシェイクの整合性も提供します。サーバーは、証明書を介して認証するときにこのメッセージを送信しなければなりません。クライアントは、証明書を介して認証するとき（つまり、証明書メッセージが空でないとき）にこのメッセージを送信しなければなりません（MUST）。送信する場合、このメッセージは、Certificate メッセージの直後、および Finished メッセージの直前に表示されなければなりません。
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.3.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.1, namely:
アルゴリズム フィールドは、使用される署名アルゴリズムを指定します (このタイプの定義については、セクション 4.3.3 を参照)。署名はそのアルゴリズムを使用したデジタル署名です。署名でカバーされるコンテンツは、セクション 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
* オクテット 32 (0x20) を 64 回繰り返した文字列
* The context string (defined below)
* コンテキスト文字列 (以下で定義)
* 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、server CertificateVerify」です。クライアント署名のコンテキスト文字列は「TLS 1.3、client CertificateVerify」です。これは、異なるコンテキストで作成された署名を分離するために使用され、潜在的なクロスプロトコル攻撃を防ぐのに役立ちます。
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.3.3).
CertificateVerify メッセージがサーバーによって送信される場合、サポートされていないアルゴリズムなしでは有効な証明書チェーンを生成できない場合を除き、署名アルゴリズムはクライアントの "signature_algorithms" 拡張で提供されるものでなければなりません (セクション 4.3.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. The SHA-1 algorithm MUST NOT be used in any signatures of CertificateVerify messages. All SHA-1 signature algorithms in this specification are defined solely for use in legacy certificates and are not valid for CertificateVerify signatures.
In addition, the signature algorithm MUST be compatible with the key in the sender's end-entity certificate.The SHA-1 algorithm MUST NOT be used in any signatures of CertificateVerify messages.この仕様のすべての SHA-1 署名アルゴリズムは、従来の証明書でのみ使用するために定義されており、CertificateVerify 署名には無効です。
The receiver of a CertificateVerify message MUST verify the signature field. The verification process takes as input:
The receiver of a CertificateVerify message MUST verify the signature field.検証プロセスでは、以下を入力として受け取ります。
* 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」アラートを発行してハンドシェイクを終了しなければなりません(MUST)。
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.
Finished メッセージの受信者は、内容が正しいことを確認しなければならず、正しくない場合は、「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.3.10.
1. セクション 4.3.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. サーバーは、最初のフライトを送信した後にデータを送信してもよい[MAY]が、ハンドシェイクがまだ完了していないため、ピアのアイデンティティやその生存性の保証はありません(つまり、ClientHelloがリプレイされた可能性があります)。
The key used to compute the Finished message is computed from the Base Key defined in Section 4.5 using HKDF (see Section 7.1). Specifically:
Finished メッセージの計算に使用されるキーは、HKDF を使用してセクション 4.5 で定義されたベース キーから計算されます (セクション 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 で説明されているように、適切なアプリケーション トラフィック キーで暗号化されなければなりません (MUST)。特に、これには、クライアントの Certificate メッセージおよび 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 メッセージを送信してはなりません (MUST NOT)。このメッセージは、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 を使用すると、メイン ハンドシェイクの後に他のメッセージを送信することもできます。これらのメッセージはハンドシェイク コンテンツ タイプを使用し、適切なアプリケーション トラフィック キーで暗号化されます。
If the client's hello contained a suitable "psk_key_exchange_modes" extension, the server MAY send a NewSessionTicket message at any time after it has received the client Finished message. The NewSessionTicket message creates a unique association between the ticket value and a secret PSK derived from the resumption secret (see Section 7).
クライアントの hello に適切な「psk_key_exchange_modes」拡張子が含まれている場合、サーバーはクライアントの Finished メッセージを受信した後、いつでも NewSessionTicket メッセージを送信してもよい(MAY)。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.3.11). Clients which receive a NewSessionTicket message but do not support resumption MUST silently ignore this message. Resumption MAY be done while the original connection is still open. 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 thus encapsulating the additional client authentication state. Multiple tickets are useful for clients for a variety of purposes, including:
クライアントは、ClientHello (セクション 4.3.11) の「pre_shared_key」拡張子にチケット値を含めることにより、今後のハンドシェイクにこの PSK を使用してもよい(MAY)。NewSessionTicket メッセージを受信したが再開をサポートしていないクライアントは、このメッセージを黙って無視しなければなりません (MUST)。再開は、元の接続がまだ開いている間に行うことができます。サーバーは、単一の接続上で複数のチケットを、互いの直後に、または特定のイベントの後に送信してもよい(付録 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 ハッシュ アルゴリズムを持つ暗号スイートでのみ再開されなければなりません (MUST)。
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 値が元のセッションで提示されたサーバー証明書に対して有効な場合にのみ再開しなければならず (MUST)、SNI 値が元のセッションで使用されたものと一致する場合にのみ再開すべきです (SHOULD)。後者はパフォーマンスの最適化です。通常、単一の証明書でカバーされる異なるサーバーが互いのチケットを受け入れることができると期待する理由はありません。したがって、その場合に再開を試みると、1 回限りのチケットが無駄になります。そのような指示が (外部または他の手段によって) 提供された場合、クライアントは異なる 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 で送信された値を使用しなければなりません (MUST)。サーバー実装が異なる SNI 値を持つすべての PSK ID を拒否する場合、これら 2 つの値は常に同じであることに注意してください。
Note: Although the resumption secret depends on the client's second flight, a server which does not request certificate-based 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 を待つのではなく、Finished を送信するとすぐに NewSessionTicket を送信してもよい(MAY)。これは、クライアントが複数の 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-1>;
} 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 use tickets for longer than 7 days after issuance, 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.
チケット発行時からの存続期間をネットワークバイトオーダーの 32 ビット符号なし整数として秒単位で示します。サーバーは 604800 秒 (7 日) を超える値を使用してはなりません。値 0 は、チケットを直ちに破棄する必要があることを示します。クライアントは、ticket_lifetime に関係なく、発行後 7 日を超えてチケットを使用してはならず、ローカル ポリシーに基づいてチケットを早期に削除してもよいです。サーバーは、ticket_lifetime に記載されている期間よりも短い期間、チケットを有効なものとして扱ってもよい(MAY)。
ticket_age_add:
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.
安全に生成されたランダムな 32 ビット値。クライアントが「pre_shared_key」拡張子に含めるチケットの有効期限を隠すために使用されます。クライアント側のチケット有効期限がこの値に 2^32 を法として加算されて、クライアントによって送信される値が得られます。サーバーは、送信するチケットごとに新しい値を生成しなければなりません (MUST)。
ticket_nonce:
ticket_nonce:
A per-ticket value that is unique across all tickets issued on this connection.
この接続で発行されたすべてのチケットにわたって一意のチケットごとの値。
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.
PSK ID として使用されるチケットの値。チケット自体は不透明なラベルです。これは、データベース検索キー、または自己暗号化および自己認証された値のいずれかである場合があります。
extensions:
拡張子:
A list of extension values for the ticket. The "Extension" format is defined in Section 4.3. Clients MUST ignore unrecognized extensions.
チケットの拡張値のリスト。「拡張」形式はセクション 4.3 で定義されています。クライアントは、認識できない拡張子を無視しなければなりません (MUST)。
The sole extension currently defined for NewSessionTicket is "early_data", indicating that the ticket may be used to send 0-RTT data (Section 4.3.10). It contains the following value:
NewSessionTicket に対して現在定義されている唯一の拡張子は「early_data」で、チケットが 0-RTT データの送信に使用できることを示しています (セクション 4.3.10)。これには次の値が含まれます。
max_early_data_size:
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.
このチケットの使用時にクライアントが送信できる 0-RTT データの最大量 (バイト単位)。アプリケーション データ ペイロード (つまり、平文だがパディングや内部コンテンツ タイプ バイトは含まない) のみがカウントされます。max_early_data_size バイトを超える 0-RTT データを受信したサーバーは、「unexpected_message」アラートで接続を終了する必要があります (SHOULD)。暗号素材が不足しているために初期データを拒否するサーバーはパディングとコンテンツを区別できないため、クライアントは初期データ レコードで大量のパディングを送信できることに依存すべきではないことに注意してください。
The PSK associated with the ticket is computed as:
チケットに関連付けられた PSK は次のように計算されます。
HKDF-Expand-Label(resumption_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.3.6), a server MAY request certificate-based 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.5). 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 type or from other responses.
クライアントが "post_handshake_auth" 拡張子 (セクション 4.3.6 を参照) を送信した場合、サーバーは、ハンドシェイクが完了した後いつでも、CertificateRequest メッセージを送信することによって証明書ベースのクライアント認証を要求してもよい(MAY)。クライアントは適切な認証メッセージで応答しなければなりません (セクション 4.5 を参照)。クライアントが認証を選択した場合は、Certificate、CertificateVerify、および Finished を送信しなければなりません。拒否する場合は、証明書を含まない証明書メッセージに続いて「完了」を送信しなければなりません。特定の応答に対するクライアントのメッセージはすべて、他のタイプのメッセージや他の応答からのメッセージが介在することなく、連続して回線上に出現しなければなりません (MUST)。
A client that receives a post-handshake CertificateRequest message without having sent the "post_handshake_auth" extension MUST send an "unexpected_message" fatal alert.
"post_handshake_auth" 拡張機能を送信せずにハンドシェイク後の CertificateRequest メッセージを受信したクライアントは、"unexpected_message" 致命的アラートを送信しなければなりません (MUST)。
Note: Because certificate-based 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 を連続して受信したクライアントは、受信した順序とは異なる順序で応答してもよい (MAY) (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」アラートで接続を終了しなければなりません (MUST)。KeyUpdate メッセージを送信した後、送信者は、セクション 7.2 で説明されているように計算された次世代の鍵を使用して、すべてのトラフィックを送信するものとします (SHALL)。KeyUpdate を受信すると、受信者は受信キーを更新しなければなりません (MUST)。
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.
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. Until receiving a subsequent KeyUpdate from the peer, the sender MUST NOT send another KeyUpdate with request_update set to "update_requested".
request_update フィールドが "update_requested" に設定されている場合、受信者は次のアプリケーション データ レコードを送信する前に、request_update を "update_not_requested" に設定して独自の KeyUpdate を送信しなければなりません (MUST)。このメカニズムにより、どちらの側でも接続全体の更新を強制できますが、サイレント中に複数の KeyUpdate を受信する実装が 1 つの更新で応答することになります。ピアから後続の KeyUpdate を受信するまで、送信者は request_update を「update_requested」に設定して別の KeyUpdate を送信してはなりません (MUST NOT)。
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, including unrelated KeyUpdates, 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」に設定して KeyUpdate を送信してからピアの 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」に設定して独自の KeyUpdate を個別に送信し、それらが送信中に交差する場合、各側も応答を送信し、その結果、各側が 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 メッセージを暗号化しなければなりません (MUST)。さらに、双方は、新しい鍵で暗号化されたメッセージを受け入れる前に、古い鍵を含む KeyUpdate を受信することを強制しなければなりません (MUST)。そうしないと、メッセージ切り捨て攻撃が許可される可能性があります。
With a 128-bit key as in AES-128, rekeying 2^64 times has a high probability of key reuse within a given connection. Note that even if the key repeats, the IV is also independently generated, so the chance of a joint key/IV collision is much lower. To provide an extra margin of security, sending implementations MUST NOT allow the epoch -- and hence the number of key updates -- to exceed 2^48-1. In order to allow this value to be changed later -- for instance for ciphers with more than 128-bit keys -- receiving implementations MUST NOT enforce this rule. If a sending implementation receives a KeyUpdate with request_update set to "update_requested", it MUST NOT send its own KeyUpdate if that would cause it to exceed these limits and SHOULD instead ignore the "update_requested" flag. This may result in an eventual need to terminate the connection when the limits in Section 5.5 are reached.
AES-128 のような 128 ビット キーを使用すると、2^64 回キーを再生成すると、特定の接続内でキーが再利用される可能性が高くなります。キーが繰り返される場合でも、IV も独立して生成されるため、ジョイント キーと IV の衝突の可能性ははるかに低いことに注意してください。追加のセキュリティマージンを提供するために、送信実装はエポック、つまり鍵更新の数が 2^48-1 を超えることを許可してはなりません (MUST NOT)。この値を後で変更できるようにするために (たとえば、128 ビットを超える鍵を持つ暗号の場合)、受信側の実装はこのルールを強制してはなりません (MUST NOT)。送信側実装が request_update が "update_requested" に設定された KeyUpdate を受信した場合、これらの制限を超える場合には独自の KeyUpdate を送信してはなりません (MUST NOT)。代わりに "update_requested" フラグを無視する必要があります (SHOULD)。これにより、セクション 5.5 の制限に達したときに、最終的に接続を終了する必要が生じる可能性があります。
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 E.4).
TLS レコードは型指定されているため、複数の上位レベルのプロトコルを同じレコード層上で多重化できます。このドキュメントでは、handshake、application_data、alert、change_cipher_spec の 4 つのコンテンツ タイプを指定します。change_cipher_spec レコードは、互換性の目的でのみ使用されます (付録 E.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 メッセージが受信される前であれば、いつでも 1 バイト値 0x01 で構成される、change_cipher_spec タイプの暗号化されていないレコードを受信することができ、それ以上の処理を行わずに単純にドロップしなければなりません (MUST)。このレコードは、実装が保護されたレコードを予期しているハンドシェイクの時点で出現する可能性があるため、レコードの保護を解除する前にこの状態を検出する必要があることに注意してください。他のchange_cipher_spec値を受け取る実装、または保護されたchange_cipher_specレコードを受け取る実装は、「unexpected_message」アラートでハンドシェイクを中止しなければなりません(MUST)。最初の 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.
実装は、何らかの拡張によってネゴシエートされない限り、この文書で定義されていないレコード タイプを送信してはなりません (MUST NOT)。TLS 実装が予期しないレコード タイプを受信した場合、「unexpected_message」アラートを発行して接続を終了しなければなりません。新しいレコードのコンテンツ タイプの値は、セクション 11 で説明されているように、IANA によって TLS ContentType レジストリに割り当てられます。
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.
レコード層は、情報ブロックを TLSPlaintext レコードに断片化し、データを 2^14 バイト以下のチャンクで伝送します。メッセージ境界は、基になる ContentType に応じて異なる方法で処理されます。将来のコンテンツ タイプでは、適切なルールを指定する必要があります。これらのルールは、TLS 1.2 で適用されたルールよりも厳格であることに注意してください。
Handshake messages MAY be coalesced into a single TLSPlaintext record or fragmented across several records, provided that:
ハンドシェイク メッセージは、次の場合に限り、単一の TLSPlaintext レコードに結合することも、複数のレコードに断片化することもできます (MAY)。
* 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.
* ハンドシェイク メッセージを他のレコード タイプとインターリーブしてはなりません (MUST NOT)。つまり、ハンドシェイク メッセージが 2 つ以上のレコードに分割されている場合、それらの間に他のレコードがあってはなりません (MUST NOT)。
* 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.
* ハンドシェイク メッセージはキーの変更をまたいではなりません (MUST NOT)。実装では、キー変更の直前のすべてのメッセージがレコード境界と一致していることを検証しなければなりません。そうでない場合は、「unexpected_message」アラートで接続を終了しなければなりません。ClientHello、EndOfEarlyData、ServerHello、Finished、および KeyUpdate メッセージはキー変更の直前に送信される可能性があるため、実装はこれらのメッセージをレコード境界に合わせて送信しなければなりません (MUST)。
Implementations MUST NOT send zero-length fragments of Handshake types, even if those fragments contain padding.
実装では、たとえそれらのフラグメントにパディングが含まれていたとしても、ハンドシェイク タイプの長さ 0 のフラグメントを送信してはなりません (MUST NOT)。
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) はレコード間で断片化してはならず、複数のアラート メッセージを 1 つの TLSPlaintext レコードに結合してはなりません (MUST NOT)。言い換えれば、アラート タイプのレコードには、メッセージが 1 つだけ含まれなければなりません (MUST)。
Application Data messages contain data that is opaque to TLS. Application Data messages are always protected. Zero-length fragments of Application Data (i.e., TLSInnerPlaintext records of type application_data with zero-length content) 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 に対して不透明なデータが含まれています。アプリケーション データ メッセージは常に保護されます。アプリケーション データの長さ 0 のフラグメント (つまり、長さ 0 の内容を持つ application_data タイプの TLSInnerPlaintext レコード) は、トラフィック分析対策として役立つ可能性があるため、送信してもよい(MAY)。アプリケーション データ フラグメントは、複数のレコードに分割したり、単一のレコードに結合したりすることができます。
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.
囲まれたフラグメントを処理するために使用される上位レベルのプロトコル。
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.
最初の ClientHello (つまり、HelloRetryRequest の後に生成されないもの) 以外の TLS 1.3 実装によって生成されるすべてのレコードについては、0x0303 に設定しなければなりません (MUST)。互換性のために 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.
次の 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.
送信中のデータ。この値は透過的であり、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. 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 E.
このドキュメントでは、バージョン 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 をネゴシエートする場合、エンドポイントは付録 E に記載されている手順と要件に従います。
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 とは対照的に、すべての暗号は「Authenticated Encryption with Associated Data」(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.
TLSPlaintext.fragment 値。ハンドシェイクまたはアラート メッセージのバイト エンコーディング、または送信するアプリケーション データの生のバイトが含まれます。
type:
タイプ：
The TLSPlaintext.type value containing the content type of the record.
レコードのコンテンツ タイプを含む 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.
任意の長さのゼロ値バイトの連続が、タイプ フィールドの後の平文に表示される場合があります。これにより、合計がレコード サイズ制限内に収まる限り、送信者は任意の 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.
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 フィールドは常に 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.
次の TLSCiphertext.encrypted_record の長さ (バイト単位)。これは、コンテンツとパディングの長さに、内部コンテンツ タイプの 1 を加え、AEAD アルゴリズムによって追加された拡張を加えたものです。長さは 2^14 + 256 バイトを超えてはなりません。この長さを超えるレコードを受信したエンドポイントは、「record_overflow」アラートを発行して接続を終了しなければなりません。
encrypted_record:
暗号化されたレコード:
The AEAD-encrypted form of the serialized TLSInnerPlaintext structure.
シリアル化された 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. I.e.,
AEAD アルゴリズムは、[RFC5116] のセクション 2.1 で説明されているように、単一のキー、ノンス、平文、および認証チェックに含まれる「追加データ」を入力として受け取ります。キーは client_write_key または server_write_key のいずれかで、ノンスはシーケンス番号と client_write_iv または server_write_iv (セクション 5.3 を参照) から導出され、追加のデータ入力はレコード ヘッダーです。つまり、
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. Since the ciphers might incorporate padding, the amount of overhead could vary with different lengths of plaintext. Symbolically,
AEAD 出力は、AEAD 暗号化操作からの暗号文出力で構成されます。TLSInnerPlaintext.type と送信者によって提供されたパディングが含まれているため、プレーンテキストの長さは、対応する TLSPlaintext.length よりも長くなります。AEAD 出力の長さは通常、平文よりも大きくなりますが、その量は AEAD アルゴリズムによって異なります。暗号にはパディングが組み込まれている場合があるため、平文の長さが異なるとオーバーヘッドの量が変わる可能性があります。象徴的に言えば、
AEADEncrypted =
AEAD-Encrypt(write_key, nonce, additional_data, plaintext)
The encrypted_record field of TLSCiphertext is set to AEADEncrypted.
TLSCiphertext の encrypted_record フィールドは AEADEncrypted に設定されます。
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 オクテットを超える拡張を生成してはなりません (MUST NOT)。TLSCiphertext.length が 2^14 + 256 オクテットより大きいレコードをピアから受信したエンドポイントは、「record_overflow」アラートで接続を終了しなければなりません (MUST)。この制限は、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 に設定されます。特定のトラフィック キーの下で送信される最初のレコードはシーケンス番号 0 を使用しなければなりません (MUST)。
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.7.3) or terminate the connection.
シーケンス番号のサイズは 64 ビットであるため、ラップしないでください。TLS 実装でシーケンス番号をラップする必要がある場合は、キーを再生成するか (セクション 4.7.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) は、8 バイトと AEAD アルゴリズムの 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) は、レコードごとの nonce として使用されます。
Note: This is a different construction from that in TLS 1.2, which specified a partially explicit nonce.
注: これは、部分的に明示的な 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 レコードを生成するとき、実装はパディングを選択してもよい (MAY)。パディングされていないレコードは、パディング長がゼロの単なるレコードです。パディングは、暗号化の前に ContentType フィールドに追加されるゼロ値のバイト文字列です。実装では、暗号化する前にパディング オクテットをすべて 0 に設定しなければなりません。
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.
送信者が希望する場合は、アプリケーション データ レコードに長さ 0 の TLSInnerPlaintext.content を含めることができます。これにより、アクティビティの有無が重要な状況で、妥当なサイズのカバー トラフィックを生成できます。実装は、長さ 0 の TLSInnerPlaintext.content を持つハンドシェイク レコードとアラート レコードを送信してはなりません (MUST NOT)。このようなメッセージを受信した場合、受信側の実装は「unexpected_message」アラートを発行して接続を終了しなければなりません (MUST)。
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 復号化から返される平文に制限しなければなりません (MUST)。受信側の実装がクリアテキスト内にゼロ以外のオクテットを見つけられなかった場合、「unexpected_message」アラートで接続を終了しなければなりません (MUST)。
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 オクテットを超えてはなりません (MUST NOT)。たとえば [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 MUST either close the connection or do a key update as described in Section 4.7.3 prior to reaching these limits. Note that it is not possible to perform a KeyUpdate for early data; therefore, implementations MUST NOT exceed the limits when sending early data. Receiving implementations SHOULD NOT enforce these limits, as future analyses may result in updated values.
特定のキーのセットで安全に暗号化できる平文の量には暗号上の制限があります。[AEAD-LIMITS] は、基礎となるプリミティブ (AES または ChaCha20) に弱点がないという仮定の下で、これらの制限の分析を提供します。実装は、これらの制限に達する前に、接続を閉じるか、セクション 4.7.3 で説明されているようにキーの更新を実行する必要があります。初期のデータに対して KeyUpdate を実行することはできないことに注意してください。したがって、実装は初期データを送信するときに制限を超えてはなりません。今後の分析により値が更新される可能性があるため、受信側の実装ではこれらの制限を強制すべきではありません。
For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encrypted under a given set of keys 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 の場合、Authenticated Encryption (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 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 実装はアプリケーションにデータの終わりを示す必要があります (SHOULD)。
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」アラートで接続を終了しなければなりません(MUST)。構文的には正しいが意味的に無効なメッセージ (p - 1 の DHE シェア、または無効な enum など) を受信したピアは、「illegal_parameter」アラートで接続を終了しなければなりません (MUST)。
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),
general_error(117),
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. This alert MUST be sent with AlertLevel=warning.
このアラートは、送信者がこの接続でこれ以上メッセージを送信しないことを受信者に通知します。閉鎖アラートを受信した後に受信したデータはすべて無視しなければなりません(MUST)。このアラートは、AlertLevel=warning を指定して送信する必要があります。
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 MUST be followed by a "close_notify". This alert generally has AlertLevel=warning. Receiving implementations SHOULD continue to read data from the peer until a "close_notify" is received, though they MAY log or otherwise record them.
このアラートは、送信者がプロトコルの障害とは関係のない何らかの理由でハンドシェイクをキャンセルしていることを受信者に通知します。ハンドシェイクの完了後にユーザーが操作をキャンセルした場合は、「close_notify」を送信して接続を閉じるだけの方が適切です。このアラートの後には「close_notify」が続く必要があります。通常、このアラートには AlertLevel=warning が設定されます。受信実装は、「close_notify」を受信するまでピアからデータを読み取り続ける必要がありますが、データをログに記録するか記録してもよい(MAY)。
Either party MAY initiate a close of its write side of the connection by sending a "close_notify" alert. 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」アラートを送信することによって、接続の書き込み側のクローズを開始してもよい(MAY)。「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」アラートを送信しなければなりません (MUST)。これは接続の読み取り側には影響しません。これは、実装が保留中の書き込みを破棄し、独自の「close_notify」アラートを即時に送信することで「close_notify」に反応する必要があった、TLS 1.3 より前のバージョンの TLS からの変更点であることに注意してください。以前の要件により、読み取り側で切り捨てが発生する可能性があります。双方とも、接続の読み取り側を閉じる前に「close_notify」アラートの受信を待つ必要はありませんが、そうすると切り捨てられる可能性が生じます。
Application protocols MAY choose to flush their send buffers and immediately send a "close_notify" upon receiving a "close_notify", but this allows an attacker to influence the data that the peer receives by delaying the "close_notify" or by delaying the transport-level delivery of the application's packets. These issues can be addressed at the application layer, for instance by ignoring packets received after transmitting the "close_notify".
アプリケーションプロトコルは、「close_notify」を受信すると送信バッファをフラッシュし、すぐに「close_notify」を送信することを選択してもよい[MAY]が、これにより、攻撃者が「close_notify」を遅らせたり、アプリケーションのパケットのトランスポートレベルの配信を遅らせたりすることによって、ピアが受信するデータに影響を与えることが可能になる。これらの問題は、たとえば「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 でのエラー処理は非常に簡単です。エラーが検出されると、検出側はピアにメッセージを送信します。致命的な警告メッセージを送信または受信した場合、双方は直ちに接続を閉じなければなりません (MUST)。
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. Throughout 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)、追加のデータを送受信することなく接続を閉じなければなりません(MUST)。この仕様全体を通して、「接続を終了する」および「ハンドシェイクを中止する」という表現が特定のアラートなしで使用される場合、実装は以下の説明で示されるアラートを送信すべきである(SHOULD)ことを意味します。「X アラートで接続を終了する」および「X アラートでハンドシェイクを中止する」というフレーズは、実装がアラートを送信する場合はアラート X を送信しなければならないことを意味します。このセクションで以下に定義されているすべてのアラートとすべての不明なアラートは、TLS 1.3 の時点で一般的に致命的であると考えられています (セクション 6 を参照)。実装では、アラートの送受信のログ記録を容易にする方法を提供すべきです(SHOULD)。
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.
不適切なメッセージ (例: 間違ったハンドシェイク メッセージ、時期尚早のアプリケーション データなど) を受信しました。このアラートは、適切な実装間の通信では決して観察されるべきではありません。
bad_record_mac:
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.
このアラートは、保護を解除できないレコードを受信した場合に返されます。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.
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」アラート メッセージを受信した場合は、送信者が、利用可能なオプションを指定して許容可能なセキュリティ パラメータのセットをネゴシエートできなかったことを示します。
bad_certificate:
悪い証明書:
A certificate was corrupt, contained signatures that did not verify correctly, etc.
証明書が壊れていた、正しく検証されなかった署名が含まれていた、など。
unsupported_certificate:
unsupported_certificate:
A certificate was of an unsupported type.
証明書のタイプはサポートされていませんでした。
certificate_revoked:
証明書_取り消し:
A certificate was revoked by its signer.
証明書は署名者によって取り消されました。
certificate_expired:
証明書の期限切れ:
A certificate has expired or is not currently valid.
証明書の有効期限が切れているか、現在有効ではありません。
certificate_unknown:
証明書_不明:
Some other (unspecified) issue arose in processing the certificate, rendering it unacceptable.
証明書の処理中に他の (不特定の) 問題が発生し、証明書が受け入れられなくなりました。
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.
ハンドシェイクのフィールドが正しくないか、他のフィールドと矛盾していました。このアラートは、正式なプロトコル構文に準拠しているが、その他の点では正しくないエラーに対して使用されます。
unknown_ca:
不明_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.
有効な証明書チェーンまたは部分チェーンを受信しましたが、CA 証明書が見つからなかったか、既知のトラスト アンカーと一致しなかったため、証明書は受け入れられませんでした。
access_denied:
アクセスが拒否されました：
A valid certificate or PSK was received, but when access control was applied, the sender decided not to proceed with negotiation.
有効な証明書または 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.
一部のフィールドが指定された範囲外であるか、メッセージの長さが正しくないため、メッセージをデコードできませんでした。このアラートは、メッセージが正式なプロトコル構文に準拠していないエラーに対して使用されます。このアラートは、ネットワーク内でメッセージが破損した場合を除き、適切な実装間の通信では決して観察されるべきではありません。
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.
署名を正しく検証できない、または Finished メッセージまたは PSK バインダーを検証できないなど、ハンドシェイク (レコード層ではない) 暗号化操作が失敗しました。
protocol_version:
プロトコルのバージョン:
The protocol version the peer has attempted to negotiate is recognized but not supported (see Appendix E).
ピアがネゴシエートしようとしたプロトコルのバージョンは認識されていますが、サポートされていません (付録 E を参照)。
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.
ピアまたはプロトコルの正確さに関係のない内部エラー (メモリ割り当ての失敗など) により、続行できなくなります。
inappropriate_fallback:
不適切なフォールバック:
Sent by a server in response to an invalid connection retry attempt from a client (see [RFC7507]).
クライアントからの無効な接続再試行に応答してサーバーによって送信されます ([RFC7507] を参照)。
missing_extension:
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.
提供された TLS バージョンまたはその他のネゴシエートされたパラメーターに対して送信が必須の拡張子が含まれていないハンドシェイク メッセージを受信したエンドポイントによって送信されます。
unsupported_extension:
unsupported_extension:
Sent by endpoints receiving any handshake message containing an extension in a ServerHello, HelloRetryRequest, EncryptedExtensions, or Certificate not first offered in the corresponding ClientHello or CertificateRequest.
ServerHello、HelloRetryRequest、EncryptedExtensions、または対応する ClientHello または CertificateRequest で最初に提供されていない証明書の拡張機能を含むハンドシェイク メッセージを受信するエンドポイントによって送信されます。
unrecognized_name:
認識されない名前:
Sent by servers when no server exists identified by the name provided by the client via the "server_name" extension (see [RFC6066]).
"server_name" 拡張子を介してクライアントによって提供された名前によって識別されるサーバーが存在しない場合に、サーバーによって送信されます ([RFC6066] を参照)。
bad_certificate_status_response:
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]).
無効または受け入れられない OCSP 応答が「status_request」拡張機能を介してサーバーから提供されたときに、クライアントによって送信されます ([RFC6066] を参照)。
unknown_psk_identity:
不明_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.
PSK キーの確立が必要であるが、許容可能な PSK ID がクライアントによって提供されない場合に、サーバーによって送信されます。このアラートの送信はオプションです。サーバーは代わりに、単に無効な PSK ID を示すために「decrypt_error」アラートを送信することを選択してもよい(MAY)。
certificate_required:
証明書が必要:
Sent by servers when a client certificate is desired but none was provided by the client.
クライアント証明書が必要であるが、クライアントによって証明書が提供されなかった場合に、サーバーによって送信されます。
general_error:
一般エラー:
Sent to indicate an error condition in cases when either no more specific error is available or the senders wishes to conceal the specific error code. Implementations SHOULD use more specific errors when available.
これ以上具体的なエラーが利用できない場合、または送信者が特定のエラー コードを隠したい場合に、エラー状態を示すために送信されます。実装では、利用可能な場合はより具体的なエラーを使用する必要があります (SHOULD)。
no_application_protocol:
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]).
クライアントの「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 はバイト単位の出力長です。メッセージは、指定されたハンドシェイク メッセージを連結したものです。ハンドシェイク メッセージのタイプと長さのフィールドは含まれますが、レコード層ヘッダーは含まれません。場合によっては、長さ 0 の Context (「」で示される) が HKDF-Expand-Label に渡されることに注意してください。この文書で指定されているラベルはすべて ASCII 文字列であり、末尾の NUL バイトは含まれません。
Any extensions to TLS which use "HKDF-Expand-Label" use the HkdfLabel definition associated with the version of TLS with which they are being used. When used with this specification, that means using HkdfLabel as defined above; when used with DTLS [RFC9147] that means using the version defined in [RFC9147], Section 5.9.
「HKDF-Expand-Label」を使用する TLS の拡張機能は、使用されている TLS のバージョンに関連付けられた HkdfLabel 定義を使用します。この仕様で使用される場合、それは上で定義された HkdfLabel を使用することを意味します。DTLS [RFC9147] で使用する場合、[RFC9147] のセクション 5.9 で定義されているバージョンを使用することを意味します。
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 つの入力シークレットから導出されます。新しいシークレットを追加する一般的なパターンは、Salt を現在のシークレット状態とし、入力キーイング マテリアル (IKM) を追加する新しいシークレットとして HKDF-Extract を使用することです。このバージョンの TLS 1.3 では、2 つの入力シークレットは次のとおりです。
* PSK (a pre-shared key established externally or derived from the resumption_secret value from a previous connection)
* PSK (外部で確立された事前共有キー、または以前の接続の resumption_secret 値から派生した事前共有キー)
* Asymmetric shared secret resulting from the asymmetric key establishment (see Section 7.4)
* 非対称鍵の確立から生じる非対称共有秘密 (セクション 7.4 を参照)
This produces the key schedule shown in the diagram below (Figure 5). In this diagram, the following formatting conventions apply:
これにより、以下の図 (図 5) に示すキー スケジュールが生成されます。この図では、次の書式設定規則が適用されます。
* 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 引数は、入ってくる矢印で示されます。たとえば、Early Secret は client_early_traffic_secret を生成するための Secret です。
* "0" indicates a string of Hash.length bytes set to zero.
* 「0」は、Hash.length バイトの文字列がゼロに設定されていることを示します。
Note: The key derivation labels use the string "master" even though the values are referred to as "main" secrets. This mismatch is a result of renaming the values while retaining compatibility.
注: キー導出ラベルでは、値が「メイン」シークレットとして参照されている場合でも、文字列「マスター」が使用されます。この不一致は、互換性を維持しながら値の名前を変更した結果です。
Note: This does not show all the leaf keys such as the separate AEAD and IV keys but rather the first set of secrets derived from the handshake.
注: これには、個別の AEAD キーや IV キーなどのすべてのリーフ キーが表示されるのではなく、ハンドシェイクから派生した最初のシークレット セットが表示されます。
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_secret
v
Derive-Secret(., "derived", "")
|
asymmetric v
shared --> HKDF-Extract = Handshake Secret
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 = Main 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_secret
|
+-----> Derive-Secret(., "res master",
ClientHello...client Finished)
= resumption_secret
Figure 5: Main TLS 1.3 Key Schedule
図 5: 主要な TLS 1.3 鍵スケジュール
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 の呼び出しごとに異なる Messages 引数が取られる場合があることに注意してください。0-RTT 交換では、4 つの異なるトランスクリプトを使用して Derive-Secret が呼び出されます。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 secret of a previous handshake). The different labels prevent the substitution of one type of PSK for the other.
特定のシークレットが利用できない場合は、ゼロに設定された Hash.length バイトの文字列で構成される 0 の値が使用されます。これはラウンドをスキップすることを意味するものではないため、PSK が使用されていない場合でも、Early Secret は HKDF-Extract(0, 0) になることに注意してください。binding_key の計算の場合、ラベルは外部 PSK (TLS の外部でプロビジョニングされるもの) の場合は「ext binding」、再開 PSK (以前のハンドシェイクの再開シークレットとしてプロビジョニングされるもの) の場合は「res binding」です。ラベルが異なると、あるタイプの 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 を選択するかに応じて、複数の潜在的な Early Secret 値が存在します。クライアントは、潜在的な 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.
与えられたシークレットから導出されるすべての値が計算されたら、そのシークレットは消去されるべきです(SHOULD)。
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.7.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.7.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 とそれに関連するトラフィック キーを削除する必要があります (SHOULD)。
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 category of data is shown in the table below.
[sender]は送信側を表します。データの各カテゴリの Secret の値を次の表に示します。
+====================+=======================================+
| Data Type | Secret |
+====================+=======================================+
| 0-RTT Application | client_early_traffic_secret |
| and EndOfEarlyData | |
+--------------------+---------------------------------------+
| Initial Handshake | [sender]_handshake_traffic_secret |
+--------------------+---------------------------------------+
| Post-Handshake and | [sender]_application_traffic_secret_N |
| Application Data | |
+--------------------+---------------------------------------+
Table 3: Secrets for Traffic Keys
表 3: トラフィック キーの秘密
Alerts are sent with the then-current sending key (or as plaintext if no such key has been established.) 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 [KEYAGREEMENT] 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 [KEYAGREEMENT] 計算が実行されます。ネゴシエートされたキー (Z) は、ビッグエンディアン形式でエンコードすることによってバイト文字列に変換され、素数のサイズまで左にゼロが埋め込まれます。このバイト文字列は、上で指定したキー スケジュールの共有秘密として使用されます。
Note that this construction differs from previous versions of TLS which remove leading zeros.
この構造は、先行ゼロを削除する以前のバージョンの TLS とは異なることに注意してください。
For secp256r1, secp384r1, and secp521r1, ECDH calculations (including key generation and shared secret calculation) are performed according to Sections 5.6.1.2 and 5.7.1.2 of [KEYAGREEMENT] using the Elliptic Curve Cryptography Cofactor Diffie-Hellman Primitive. The shared secret Z is the x-coordinate of the ECDH shared secret elliptic curve point represented as an octet string. Note that the octet string Z as output by the Field-Element-to-Byte String Conversion specified in Appendix C.2 of [KEYAGREEMENT] has constant length for any given field; leading zeros found in this octet string MUST NOT be truncated. See Section 4.3.8.2 for requirements on public-key validation.
secp256r1、secp384r1、および secp521r1 の場合、ECDH 計算 (鍵生成および共有秘密の計算を含む) は、[KEYAGREEMENT] のセクション 5.6.1.2 および 5.7.1.2 に従って、楕円曲線暗号補因子 Diffie-Hellman プリミティブを使用して実行されます。共有秘密 Z は、オクテット文字列として表される ECDH 共有秘密楕円曲線点の x 座標です。[KEYAGREEMENT] の付録 C.2 で指定されているフィールド要素からバイト文字列への変換によって出力されるオクテット文字列 Z は、どのフィールドに対しても一定の長さを持つことに注意してください。このオクテット文字列内の先頭のゼロは切り捨てられてはなりません (MUST NOT)。公開鍵の検証に関する要件については、セクション 4.3.8.2 を参照してください。
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 構造に入れる公開キーは、適切な長さの秘密キー (スカラー入力) と標準の公開基点 (u 座標点入力) に ECDH スカラー乗算関数を適用した結果です。
* 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 共有秘密を計算する必要があります (SHOULD)。[RFC7748] のセクション 6 に記載されているように、実装は、計算された Diffie-Hellman 共有秘密がすべてゼロの値であるかどうかをチェックし、そうであれば中止しなければなりません (MUST)。実装者がこれらの楕円曲線の代替実装を使用する場合、[RFC7748] のセクション 7 で指定されている追加のチェックを実行する必要があります (SHOULD)。
[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_secret or the exporter_secret. Implementations MUST use the exporter_secret unless explicitly specified by the application. The early_exporter_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_secret または exporter_secret のいずれかです。実装では、アプリケーションによって明示的に指定されていない限り、exporter_secret を使用しなければなりません (MUST)。early_exporter_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 からの変更点です。このドキュメントの公開時点では、コンテキストの有無にかかわらず、割り当てられたエクスポーター ラベルは使用されていません。将来の仕様では、同じラベルを持つ空のコンテキストとコンテキストなしの両方を許可するエクスポータの使用を定義してはなりません (MUST NOT)。エクスポーターの新しい使用法では、値が空であっても、すべてのエクスポーターの計算にコンテキストを提供する必要があります (SHOULD)。
Requirements for the format of exporter labels are defined in Section 4 of [RFC5705].
エクスポーターラベルのフォーマットの要件は、[RFC5705] のセクション 4 で定義されています。
As noted in Section 2.3 and Appendix F.5, TLS does not provide inherent replay protections for 0-RTT data. There are two potential threats to be concerned with:
セクション 2.3 および付録 F.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, but 0-RTT adds an additional dimension if clients automatically retransmit rejected 0-RTT data after the completion of a handshake, as an attacker may be able to cause the data to be processed as 0-RTT data on connection 1 and as 1-RTT data on connection 2.
* ネットワーク攻撃者は、クライアントの再試行動作を利用して、サーバーがアプリケーション メッセージの複数のコピーを受信できるようにします。堅牢性を重視するクライアントはリクエストの再試行を試みることでネットワーク エラーに応答するため、この脅威はすでにある程度存在していますが、ハンドシェイクの完了後にクライアントが拒否された 0-RTT データを自動的に再送信する場合、攻撃者がデータを接続 1 では 0-RTT データとして、接続 2 では 1-RTT データとして処理できる可能性があるため、0-RTT によって追加の次元が追加されます。
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 回受け入れられることを保証することで防止できます。サーバーは、このセクションで説明する方法のいずれか、または同等の手段を実装することによって、そのレベルのリプレイ安全性を提供すべきです(SHOULD)。ただし、運用上の問題により、すべての展開がそのレベルの状態を維持するわけではないことは理解されています。したがって、通常の動作では、クライアントはサーバーがこれらのメカニズムのどれを実際に実装しているのかを知りません。したがって、安全に再生できると判断した初期データのみを送信しなければなりません。
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 F.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.
リプレイの直接的な影響に加えて、通常冪等とみなされる操作であっても、多数のリプレイによって悪用される可能性があるクラスの攻撃があります (付録 F.5 で説明するタイミング攻撃、リソース制限の枯渇など)。これらは、すべての 0-RTT ペイロードを限られた回数だけ再生できるようにすることで軽減できます。サーバーは、そのインスタンス (マシン、スレッド、または関連するサービス提供インフラストラクチャ内のその他のエンティティ) が同じ 0-RTT ハンドシェイクに対して 0-RTT を最大 1 回受け入れることを保証しなければなりません (MUST)。これにより、リプレイの数がデプロイメント内のサーバー インスタンスの数に制限されます。このような保証は、最近受信した ClientHello からのデータをローカルに記録し、繰り返しを拒否することによって、または同じまたはより強力な保証を提供するその他の方法によって実現できます。「サーバー インスタンスごとに最大 1 回」の保証は最小要件です。サーバーは、可能な場合には 0-RTT のリプレイをさらに制限すべきです (SHOULD)。
The second class of attack cannot be prevented at the TLS layer and MUST be dealt with by any application (see, for instance, [RFC8470], which provides guidance on the use of HTTP with 0-RTT data). Note that any application whose clients implement any kind of retry behavior already needs to implement some sort of anti-replay defense, including properly handling duplicate application layer requests which arrive on distinct TLS connections.
2 番目のクラスの攻撃は TLS 層では防ぐことができず、アプリケーションによって対処しなければなりません (たとえば、0-RTT データでの HTTP の使用に関するガイダンスを提供する [RFC8470] を参照)。クライアントが何らかの種類の再試行動作を実装するアプリケーションは、別個の 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 not only anti-replay protection, but also forward secrecy once all copies of the PSK from the database entry have been deleted. This mechanism also improves security for PSK usage when PSK is used without an asymmetric key exchange.
チケットが自己完結型ではなくデータベース キーであり、対応する PSK が使用時に削除される場合、PSK を使用して確立された接続は、アンチリプレイ保護だけでなく、データベース エントリからの PSK のすべてのコピーが削除されると前方秘密性も享受します。このメカニズムは、非対称キー交換なしで PSK が使用される場合の 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」を使用してチケットがその時間枠外で再利用されないようにすることができます。
To implement this, when a ClientHello is received, the server first verifies the PSK binder as described in Section 4.3.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.3.11 で説明されているように、まず PSK バインダーを検証します。次に、次のセクションで説明するように Expected_delivery_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_delivery_time がウィンドウ内にある場合、サーバーは一致する ClientHello が記録されているかどうかを確認します。見つかった場合は、「illegal_parameter」アラートでハンドシェイクを中止するか、PSK は受け入れますが 0-RTT を拒否します。一致する ClientHello が見つからない場合は、0-RTT を受け入れ、expected_delivery_time がウィンドウ内にある限り ClientHello を保存します。サーバーは、ブルームフィルターなどの誤検知を伴うデータストアを実装してもよい(MAY)。その場合、サーバーは0-RTTを拒否することで見かけのリプレイに応答しなければならない(MUST)が、ハンドシェイクを中止してはいけない(MUST NOT)。
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.3.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 が含まれている場合、攻撃者はサーバーが検証しないことを前提として、優先度の低い ID に対して異なるバインダー値を持つ複数の ClientHello を作成する可能性があります (セクション 4.3.11 で推奨されているとおり)。つまり、クライアントが 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.
このメカニズムは未処理のチケットをすべて保存する必要がないため、受信した ClientHello メッセージを確実に保存および取得することが難しいため、リプレイ防止防御が弱くなる可能性がありますが、再開率が高く 0-RTT の高い分散システムでの実装が容易になる可能性があります。このようなシステムの多くでは、受信したすべての 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 を拒否する必要があります (SHOULD)。そうしないと、その期間中に最初に送信されたリプレイを受け入れてしまう危険性があります。
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 が受信される可能性があります。その場合、クライアントは 1-RTT で受け入れられ、クライアントの再試行が発生し、その後 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 ハンドシェイクにフォールバックすることができます。これは、セクション 8.2 で説明されている ClientHello ストレージ メカニズムに必要です。そうしないと、サーバーは無制限の数の ClientHello を保存する必要があり、0-RTT に使用できない ClientHello を効率的に拒否できるため、自己完結型の使い捨てチケットにとって有用な最適化です。
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_delivery_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_delivery_time が現在のサーバーの壁時計時間と比較され、一定量以上異なる場合、0-RTT は拒否されますが、1-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_delivery_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] との鍵交換をサポートすべきである (SHOULD)。
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.3.1)
* サポートされているバージョン (「supported_versions」; セクション 4.3.1)
* Cookie ("cookie"; Section 4.3.2)
* Cookie (「Cookie」; セクション 4.3.2)
* Signature Algorithms ("signature_algorithms"; Section 4.3.3)
* 署名アルゴリズム (「signature_algorithms」; セクション 4.3.3)
* Signature Algorithms Certificate ("signature_algorithms_cert"; Section 4.3.3)
* 署名アルゴリズム証明書 (「signature_algorithms_cert」; セクション 4.3.3)
* Supported Groups ("supported_groups"; Section 4.3.7)
* サポートされているグループ (「supported_groups」; セクション 4.3.7)
* Key Share ("key_share"; Section 4.3.8)
* 鍵共有 (「key_share」; セクション 4.3.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.
* 「supported_groups」は、DHE または ECDHE キー交換を使用する ClientHello メッセージに必須です。
* "key_share" is REQUIRED for DHE or ECDHE key exchange.
* DHE または ECDHE 鍵交換には「key_share」が必須です。
* "pre_shared_key" is REQUIRED for PSK key agreement.
* PSK キーの合意には「pre_shared_key」が必須です。
* "psk_key_exchange_modes" is REQUIRED for PSK key agreement.
* PSK キーの合意には「psk_key_exchange_modes」が必須です。
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 list 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」アラートを出してハンドシェイクを中止しなければなりません (MUST)。
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」拡張機能を使用できるアプリケーションでのその拡張子の使用をサポートしなければなりません (MUST)。サーバーは、クライアントに有効な "server_name" 拡張子を送信することを要求してもよい (MAY)。この拡張機能を必要とするサーバーは、「server_name」拡張機能が欠落している ClientHello に対して、「missing_extension」アラートで接続を終了することで応答する必要があります。
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 F.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 を終了せずに新しいクライアントと新しいサーバーの間でトラフィックを渡すミドルボックスは、ハンドシェイクに影響を与えることができません (付録 F.1 を参照)。同時に、デプロイメントは異なる速度で更新されるため、新しいクライアントまたはサーバーは古いパラメータを引き続きサポートしてもよく、これにより古いエンドポイントとの相互運用が可能になります。
For this to work, implementations MUST correctly handle extensible fields:
これが機能するためには、実装は拡張可能なフィールドを正しく処理する必要があります。
* A client sending a ClientHello MUST support all non-GREASE [RFC8701] parameters advertised in it. Otherwise, the server may fail to interoperate by selecting one of those parameters.
* ClientHello を送信するクライアントは、その中でアドバタイズされるすべての非 GREASE [RFC8701] パラメータをサポートしなければなりません (MUST)。そうしないと、サーバーはこれらのパラメータのいずれかを選択しても相互運用に失敗する可能性があります。
* 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 を受信するサーバーは、認識できない暗号スイート、拡張子、およびその他のパラメータをすべて正しく無視しなければなりません (MUST)。そうしないと、新しいクライアントとの相互運用に失敗する可能性があります。TLS 1.3 では、CertificateRequest または NewSessionTicket を受信するクライアントは、認識できない拡張子もすべて無視しなければなりません (MUST)。
* 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 サーバーとして動作し、また、元のサーバーの証明書の検証を含めて、(元のサーバーに対して) 準拠した TLS クライアントとして動作しなければなりません。特に、理解できるパラメータのみを含む独自の ClientHello を生成しなければなりません (MUST)。また、エンドポイントの値を転送するのではなく、新しい ServerHello ランダム値を生成しなければなりません (MUST)。
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 を超えるメッセージを処理してはなりません (MUST NOT)。後続のすべてのトラフィックを変更せずに転送しなければなりません。そうしないと、新しいクライアントやサーバーとの相互運用に失敗する可能性があります。
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.
転送された ClientHello には、ミドルボックスでサポートされていない機能のアドバタイズメントが含まれる場合があるため、応答には、ミドルボックスが認識しない将来の TLS 追加が含まれる可能性があります。これらの追加により、ClientHello を超えるメッセージが任意に変更される可能性があります。特に、ServerHello で送信される値、ServerHello 形式、および TLSCiphertext 形式が変更される可能性があります。
The design of TLS 1.3 was constrained by widely deployed non-compliant TLS middleboxes (see Appendix E.4); however, it does not relax the invariants. Those middleboxes continue to be non-compliant.
TLS 1.3 の設計は、広く導入されている非準拠の TLS ミドルボックスによって制約を受けました (付録 E.4 を参照)。ただし、不変条件は緩和されません。これらのミドルボックスは引き続き非準拠です。
Security issues are discussed throughout this memo, especially in Appendix C, Appendix E, and Appendix F.
セキュリティ問題については、このメモ全体、特に付録 C、付録 E、および付録 F で議論されています。
This document uses several registries that were originally created in [RFC4346] and updated in [RFC8446] and [RFC8447]. The changes between [RFC8446], [RFC8447], and this document are described in Section 11.1. IANA has replaced references to these RFCs with references to this document. The registries and their allocation policies are below:
この文書では、最初に [RFC4346] で作成され、[RFC8446] および [RFC8447] で更新されたいくつかのレジストリを使用します。[RFC8446]、[RFC8447]、およびこの文書の間の変更点はセクション 11.1 で説明されています。IANA は、これらの RFC への参照をこの文書への参照に置き換えました。レジストリとその割り当てポリシーは以下のとおりです。
* 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 暗号スイート レジストリ: 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 these cipher suites.
IANA は、付録 B.4 にリストされている暗号スイートをレジストリに追加しました。「値」列と「説明」列はテーブルから取得されます。これらの暗号スイートでは、「DTLS-OK」列と「推奨」列は両方とも「Y」とマークされています。
* TLS ContentType registry: Future values are allocated via Standards Action [RFC8126].
* TLS ContentType レジストリ: 将来の値は、Standards Action [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 アラート レジストリ: 将来の値は、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 レジストリ: 将来の値は、Standards Action [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 は、このレジストリを更新して、このドキュメントで定義されている値と、「よ」。
* 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.3, with any extension not listed there marked as "-" to indicate that it is not used by TLS 1.3.
* IANA はこのレジストリを更新して、拡張機能が表示される可能性のあるメッセージをリストする「TLS 1.3」列を追加しました。この列は、セクション 4.3 の表から最初に設定されており、そこにリストされていない拡張子には、TLS 1.3 で使用されていないことを示す「-」のマークが付けられています。
This document updates two entries 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." IANA has updated the entry for value 0 to have the name "X509", "Recommended" value "Y", and comment "Was X.509 before TLS 1.3".
この文書は、元々 [RFC6091] で作成され、[RFC8447] で更新された、TLS 証明書タイプ レジストリの 2 つのエントリを更新します。IANA は、値 1 のエントリを更新して、名前が「OpenPGP_RESERVED」、「推奨」値が「N」、コメントが「1.3 より前の TLS バージョンで使用される」というものにしました。IANA は、値 0 のエントリを更新して、名前が「X509」、「推奨」値が「Y」、コメントが「TLS 1.3 以前は X.509 でした」というものにしました。
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 Certificate Status Types レジストリのエントリを更新します。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.3.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.
* TLS SignatureScheme レジストリ: 0 ～ 253 (10 進数) の範囲の最初のバイトを持つ値は、要求仕様 [RFC8126] によって割り当てられます。最初のバイト 254 または 255 (10 進数) の値は、私的使用のために予約されています [RFC8126]。現在割り当てられていない、最初のバイトが 0 ～ 6 の範囲にある値、または 2 番目のバイトが 0 ～ 3 の範囲にある値は、下位互換性のために予約されています。このレジストリには「推奨」列があります。レジストリには、セクション 4.3.3 で説明されている値が初期設定されています。次の値は「推奨」としてマークされています: 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、および ed25519。
* 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".
* TLS PskKeyExchangeMode レジストリ: 0 ～ 253 (10 進数) の範囲の値は、要求される仕様 [RFC8126] によって割り当てられます。値 254 と 255 (10 進数) は私的使用のために予約されています [RFC8126]。このレジストリには「推奨」列があります。レジストリには、最初は psk_ke (0) と psk_dhe_ke (1) が設定されています。どちらも「推奨」とマークされています。
The TLS ExtensionType Values, TLS Cipher Suites, TLS Supported Groups, TLS Exporter Labels, TLS HashAlgorithm, TLS Certificate Types, TLSPskKeyExchangeMode, and TLS SignatureScheme registries have a "Recommended" column. See Section 3 of [RFC9847] for additional information about "Recommended" column values and settings.
TLS ExtensionType Values、TLS Cipher Suites、TLS Supported Groups、TLS Exporter Labels、TLS HashAlgorithm、TLS Certificate Types、TLSPskKeyExchangeMode、および TLS SignatureScheme レジストリには、「推奨」列があります。「推奨」列の値と設定の詳細については、[RFC9847] のセクション 3 を参照してください。
IANA has updated all references to [RFC8446] in the IANA registries with references to this document.
IANA は、IANA レジストリ内の [RFC8446] へのすべての参照を、この文書への参照に更新しました。
IANA has updated the "Recommended" column procedures to match [RFC9847] for the TLS SignatureScheme and PskKeyExchangeMode registries.
IANA は、TLS SignatureScheme および PskKeyExchangeMode レジストリの [RFC9847] に一致するように「推奨」列の手順を更新しました。
IANA has renamed the "extended_master_secret" value in the TLS ExtensionType Values registry to "extended_main_secret".
IANA は、TLS ExtensionType Values レジストリの「extended_master_secret」値の名前を「extended_main_secret」に変更しました。
IANA has created a value for the "general_error" alert in the TLS Alerts registry with the value given in Section 6.
IANA は、セクション 6 で指定された値を使用して、TLS アラート レジストリに「general_error」アラートの値を作成しました。
IANA has added references to this document for the status_request and supported_groups entries in the TLS ExtensionType Values registry.
IANA は、TLS ExtensionType Values レジストリの status_request およびsupported_groups エントリについて、このドキュメントへの参照を追加しました。
IANA has updated the TLS ExtensionType value in the "TLS 1.3" column for cached_info to "CH, EE".
IANA は、cached_info の「TLS 1.3」列の TLS ExtensionType 値を「CH、EE」に更新しました。
[GCM] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC", NIST SP
800-38D, DOI 10.6028/NIST.SP.800-38D, November 2007,
<https://doi.org/10.6028/NIST.SP.800-38D>.
[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,
<https://doi.org/10.6028/nist.sp.800-56ar3>.
[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>.
[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>.
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, May 2002,
<https://www.rfc-editor.org/info/rfc3279>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[RFC8701] Benjamin, D., "Applying Generate Random Extensions And
Sustain Extensibility (GREASE) to TLS Extensibility",
RFC 8701, DOI 10.17487/RFC8701, January 2020,
<https://www.rfc-editor.org/info/rfc8701>.
[RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>.
[SHS] "Secure hash standard", National Institute of Standards
and Technology (U.S.), DOI 10.6028/nist.fips.180-4, 2015,
<https://doi.org/10.6028/nist.fips.180-4>.
[X690] ITU-T, "Information technology - ASN.1 encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, February 2021,
<https://www.itu.int/rec/T-REC-X.690-202102-I/en>.
[AEAD-LIMITS]
Luykx, A. and K. Paterson, "Limits on Authenticated
Encryption Use in TLS", August 2017,
<https://eprint.iacr.org/2024/051>.
[BBFGKZ16] Bhargavan, K., Brzuska, C., Fournet, C., Green, M.,
Kohlweiss, M., and S. Zanella-Beguelin, "Downgrade
Resilience in Key-Exchange Protocols", IEEE, 2016 IEEE
Symposium on Security and Privacy (SP) pp. 506-525,
DOI 10.1109/sp.2016.37, May 2016,
<https://doi.org/10.1109/sp.2016.37>.
[BBK17] Bhargavan, K., Blanchet, B., and N. Kobeissi, "Verified
Models and Reference Implementations for the TLS 1.3
Standard Candidate", IEEE, 2017 IEEE Symposium on Security
and Privacy (SP) pp. 483-502, DOI 10.1109/sp.2017.26, May
2017, <https://doi.org/10.1109/sp.2017.26>.
[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) 2017, December 2016,
<https://eprint.iacr.org/2016/1178>.
[Ben17a] Benjamin, D., "Presentation before the TLS WG at IETF
100", IETF 100 Proceedings, November 2017,
<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://mailarchive.ietf.org/arch/msg/tls/
i9blmvG2BEPf1s1OJkenHknRw9c/>.
[Blei98] Bleichenbacher, D., "Chosen Ciphertext Attacks against
Protocols Based on RSA Encryption Standard PKCS #1",
Proceedings of CRYPTO '98, 1998,
<https://link.springer.com/chapter/10.1007/bfb0055716>.
[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>.
[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>.
[CCG16] Cohn-Gordon, K., Cremers, C., and L. Garratt, "On Post-
compromise Security", IEEE, 2016 IEEE 29th Computer
Security Foundations Symposium (CSF) pp. 164-178,
DOI 10.1109/csf.2016.19, June 2016,
<https://doi.org/10.1109/csf.2016.19>.
[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", ACM, Proceedings of the
2016 ACM SIGSAC Conference on Computer and Communications
Security pp. 468-479, DOI 10.1145/2976749.2978395, October
2016, <https://doi.org/10.1145/2976749.2978395>.
[CHHSV17] Cremers, C., Horvat, M., Hoyland, J., van der Merwe, T.,
and S. Scott, "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://mailarchive.ietf.org/arch/msg/tls/crdSCgiW-
94z2joulYJtuA52E9E/>.
[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", IEEE, 2016 IEEE
Symposium on Security and Privacy (SP) pp. 470-485,
DOI 10.1109/sp.2016.35, May 2016,
<https://doi.org/10.1109/sp.2016.35>.
[CK01] Canetti, R. and H. Krawczyk, "Analysis of Key-Exchange
Protocols and Their Use for Building Secure Channels",
Springer Berlin Heidelberg, Lecture Notes in Computer
Science pp. 453-474, DOI 10.1007/3-540-44987-6_28,
ISBN ["9783540420705", "9783540449874"], 2001,
<https://doi.org/10.1007/3-540-44987-6_28>.
[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", Springer International Publishing,
Lecture Notes in Computer Science pp. 143-163,
DOI 10.1007/978-3-319-08506-7_8, ISBN ["9783319085050",
"9783319085067"], 2014,
<https://doi.org/10.1007/978-3-319-08506-7_8>.
[DFGS15] Dowling, B., Fischlin, M., Guenther, F., and D. Stebila,
"A Cryptographic Analysis of the TLS 1.3 draft-10 Full and
Pre-shared Key Handshake Protocol", Proceedings of ACM CCS
2015, October 2015, <https://eprint.iacr.org/2015/914>.
[DFGS16] Dowling, B., Fischlin, M., Guenther, F., and D. Stebila,
"A Cryptographic Analysis of the TLS 1.3 draft-10 Full and
Pre-shared Key Handshake Protocol", TRON 2016, February
2016, <https://eprint.iacr.org/2016/081>.
[DH76] Diffie, W. and M. Hellman, "New directions in
cryptography", Institute of Electrical and Electronics
Engineers (IEEE), IEEE Transactions on Information
Theory vol. 22, no. 6, pp. 644-654,
DOI 10.1109/tit.1976.1055638, November 1976,
<https://doi.org/10.1109/tit.1976.1055638>.
[DOW92] Diffie, W., Van Oorschot, P., and M. Wiener,
"Authentication and authenticated key exchanges", Springer
Science and Business Media LLC, Designs, Codes and
Cryptography vol. 2, no. 2, pp. 107-125,
DOI 10.1007/bf00124891, June 1992,
<https://doi.org/10.1007/bf00124891>.
[DSA-1571-1]
Weimer, F., "[SECURITY] [DSA 1571-1] New openssl packages
fix predictable random number generator", message to the
debian-security-announce mailing list, May 2008,
<https://www.debian.org/security/2008/dsa-1571>.
[DSS] "Digital Signature Standard (DSS)", National Institute of
Standards and Technology (U.S.),
DOI 10.6028/nist.fips.186-5, February 2023,
<https://doi.org/10.6028/nist.fips.186-5>.
[ECDP] Chen, L., Moody, D., Regenscheid, A., Robinson, A., and K.
Randall, "Recommendations for Discrete Logarithm-based
Cryptography:: Elliptic Curve Domain Parameters", National
Institute of Standards and Technology,
DOI 10.6028/nist.sp.800-186, February 2023,
<https://doi.org/10.6028/nist.sp.800-186>.
[FETCH] WHATWG, "Fetch", WHATWG Living Standard,
<https://fetch.spec.whatwg.org/>. Commit snapshot:
https://fetch.spec.whatwg.org/commit-
snapshots/4775fcb48042c8411df497c0b7cf167b4240004f/
[FG17] Fischlin, M. and F. Guenther, "Replay Attacks on Zero
Round-Trip Time: The Case of the TLS 1.3 Handshake
Candidates", Proceedings of Euro S&P 2017, April 2017,
<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 (Oakland) 2016,
DOI 10.1109/SP.2016.34, 2016,
<http://ieeexplore.ieee.org/document/7546517/>.
[FW15] Weimer, F., "Factoring RSA Keys With TLS Perfect Forward
Secrecy", Red Hat Blog, 2 September 2015,
<https://www.redhat.com/en/blog/factoring-rsa-keys-tls-
perfect-forward-secrecy>.
[HCJC16] Husák, M., Čermák, M., Jirsík, T., and P. Čeleda, "HTTPS
traffic analysis and client identification using passive
SSL/TLS fingerprinting", Springer Science and Business
Media LLC, EURASIP Journal on Information Security vol.
2016, no. 1, DOI 10.1186/s13635-016-0030-7, February 2016,
<https://doi.org/10.1186/s13635-016-0030-7>.
[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,
2015, <https://www.usenix.org/conference/woot15/workshop-
program/presentation/hlauschek>.
[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", ACM, Proceedings of the 22nd ACM SIGSAC
Conference on Computer and Communications Security pp.
1185-1196, DOI 10.1145/2810103.2813657, October 2015,
<https://doi.org/10.1145/2810103.2813657>.
[Kraw10] Krawczyk, H., "Cryptographic Extraction and Key
Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010,
2010, <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>.
[KW16] Krawczyk, H. and H. Wee, "The OPTLS Protocol and TLS 1.3",
Proceedings of Euro S&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", IEEE, 2016
IEEE Symposium on Security and Privacy (SP) pp. 486-505,
DOI 10.1109/sp.2016.36, May 2016,
<https://doi.org/10.1109/sp.2016.36>.
[Mac17] MacCarthaigh, C., "Security Review of TLS1.3 0-RTT", May
2017, <https://github.com/tlswg/tls13-spec/issues/1001>.
[MM24] Moustafa, M., Sethi, M., and T. Aura, "Misbinding Raw
Public Keys to Identities in TLS", arxiv:2411.09770, 29
September 2025, <https://arxiv.org/pdf/2411.09770>.
[PS18] Patton, C. and T. Shrimpton, "Partially specified
channels: The TLS 1.3 record layer without elision", 2018,
<https://eprint.iacr.org/2018/634>.
[PSK-FINISHED]
Cremers, C., Horvat, M., van der Merwe, T., and S. Scott,
"Revision 10: possible attack if client authentication is
allowed during PSK", message to the TLS mailing list, 31
October 2015, <https://mailarchive.ietf.org/arch/msg/tls/
TugB5ddJu3nYg7chcyeIyUqWSbA/>.
[REKEY] Abdalla, M. and M. Bellare, "Increasing the Lifetime of a
Key: A Comparative Analysis of the Security of Re-keying
Techniques", Springer Berlin Heidelberg, Lecture Notes in
Computer Science pp. 546-559,
DOI 10.1007/3-540-44448-3_42, ISBN ["9783540414049",
"9783540444480"], 2000,
<https://doi.org/10.1007/3-540-44448-3_42>.
[Res17a] Rescorla, E., "Preliminary data on Firefox TLS 1.3
Middlebox experiment", message to the TLS mailing list, 5
December 2017, <https://mailarchive.ietf.org/arch/msg/tls/
RBp0X-OWNuWXugFJRV7c_hIU0dI/>.
[Res17b] Rescorla, E., "More compatibility measurement results",
message to the TLS mailing list, 22 December 2017,
<https://mailarchive.ietf.org/arch/msg/tls/6pGGT-
wm5vSkacMFPEPvFMEnj-M/>.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, DOI 10.17487/RFC2246, January 1999,
<https://www.rfc-editor.org/info/rfc2246>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
2010, <https://www.rfc-editor.org/info/rfc5763>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,
DOI 10.17487/RFC7465, February 2015,
<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>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
Trammell, B., Huitema, C., and D. Borkmann,
"Confidentiality in the Face of Pervasive Surveillance: A
Threat Model and Problem Statement", RFC 7624,
DOI 10.17487/RFC7624, August 2015,
<https://www.rfc-editor.org/info/rfc7624>.
[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>.
[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>.
[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>.
[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>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[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>.
[RFC8448] Thomson, M., "Example Handshake Traces for TLS 1.3",
RFC 8448, DOI 10.17487/RFC8448, January 2019,
<https://www.rfc-editor.org/info/rfc8448>.
[RFC8449] Thomson, M., "Record Size Limit Extension for TLS",
RFC 8449, DOI 10.17487/RFC8449, August 2018,
<https://www.rfc-editor.org/info/rfc8449>.
[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, <https://www.rfc-editor.org/info/rfc8470>.
[RFC8773] Housley, R., "TLS 1.3 Extension for Certificate-Based
Authentication with an External Pre-Shared Key", RFC 8773,
DOI 10.17487/RFC8773, March 2020,
<https://www.rfc-editor.org/info/rfc8773>.
[RFC8844] Thomson, M. and E. Rescorla, "Unknown Key-Share Attacks on
Uses of TLS with the Session Description Protocol (SDP)",
RFC 8844, DOI 10.17487/RFC8844, January 2021,
<https://www.rfc-editor.org/info/rfc8844>.
[RFC8870] Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F.
Andreasen, "Encrypted Key Transport for DTLS and Secure
RTP", RFC 8870, DOI 10.17487/RFC8870, January 2021,
<https://www.rfc-editor.org/info/rfc8870>.
[RFC8879] Ghedini, A. and V. Vasiliev, "TLS Certificate
Compression", RFC 8879, DOI 10.17487/RFC8879, December
2020, <https://www.rfc-editor.org/info/rfc8879>.
[RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N.,
and C. Wood, "Randomness Improvements for Security
Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020,
<https://www.rfc-editor.org/info/rfc8937>.
[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/info/rfc9001>.
[RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
June 2022, <https://www.rfc-editor.org/info/rfc9112>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/info/rfc9147>.
[RFC9149] Pauly, T., Schinazi, D., and C.A. Wood, "TLS Ticket
Requests", RFC 9149, DOI 10.17487/RFC9149, April 2022,
<https://www.rfc-editor.org/info/rfc9149>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, <https://www.rfc-editor.org/info/rfc9162>.
[RFC9257] Housley, R., Hoyland, J., Sethi, M., and C. A. Wood,
"Guidance for External Pre-Shared Key (PSK) Usage in TLS",
RFC 9257, DOI 10.17487/RFC9257, July 2022,
<https://www.rfc-editor.org/info/rfc9257>.
[RFC9258] Benjamin, D. and C. A. Wood, "Importing External Pre-
Shared Keys (PSKs) for TLS 1.3", RFC 9258,
DOI 10.17487/RFC9258, July 2022,
<https://www.rfc-editor.org/info/rfc9258>.
[RFC9261] Sullivan, N., "Exported Authenticators in TLS", RFC 9261,
DOI 10.17487/RFC9261, July 2022,
<https://www.rfc-editor.org/info/rfc9261>.
[RFC9345] Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla,
"Delegated Credentials for TLS and DTLS", RFC 9345,
DOI 10.17487/RFC9345, July 2023,
<https://www.rfc-editor.org/info/rfc9345>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/info/rfc9525>.
[RFC9847] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 9847, DOI 10.17487/RFC9847, December 2025,
<https://www.rfc-editor.org/info/rfc9847>.
[RFC9849] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", RFC 9849, DOI 10.17487/RFC9849,
March 2026, <https://www.rfc-editor.org/info/rfc9849>.
[RFC9963] Benjamin, D. and A. Popov, "Legacy RSASSA-PKCS1-v1_5 Code
Points for TLS 1.3", RFC 9963, DOI 10.17487/RFC9963, April
2026, <https://www.rfc-editor.org/info/rfc9963>.
[RSA] Rivest, R., Shamir, A., and L. Adleman, "A method for
obtaining digital signatures and public-key
cryptosystems", Association for Computing Machinery (ACM),
Communications of the ACM vol. 21, no. 2, pp. 120-126,
DOI 10.1145/359340.359342, February 1978,
<https://doi.org/10.1145/359340.359342>.
[Selfie] Drucker, N. and S. Gueron, "Selfie: reflections on TLS 1.3
with PSK", 2019, <https://eprint.iacr.org/2019/347>.
[SIGMA] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to
Authenticated Diffie-Hellman and Its Use in the IKE
Protocols", Springer Berlin Heidelberg, Lecture Notes in
Computer Science pp. 400-425,
DOI 10.1007/978-3-540-45146-4_24, ISBN ["9783540406747",
"9783540451464"], 2003,
<https://doi.org/10.1007/978-3-540-45146-4_24>.
[SLOTH] Bhargavan, K. and G. Leurent, "Transcript Collision
Attacks: Breaking Authentication in TLS, IKE, and SSH",
Internet Society, Proceedings 2016 Network and Distributed
System Security Symposium, DOI 10.14722/ndss.2016.23418,
2016, <https://doi.org/10.14722/ndss.2016.23418>.
[SSL2] Hickman, K. E., "The SSL Protocol", 9 February 1995,
<https://datatracker.ietf.org/doc/html/draft-hickman-
netscape-ssl-00>.
[TIMING] Boneh, D. and D. Brumley, "Remote Timing Attacks Are
Practical", 12th USENIX Security Symposium (USENIX
Security 03), 2003, <https://www.usenix.org/
conference/12th-usenix-security-symposium/remote-timing-
attacks-are-practical>.
[X501] ITU-T, "Information Technology - Open Systems
Interconnection - The Directory: Models",
ITU-T Recommendation X.501, ISO/IEC 9594-2:2020, October
2019, <https://www.itu.int/rec/T-REC-X.501-201910-I/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.
上記のような遷移では、クライアントは、ServerHello 後のメッセージから派生したアラートを平文で、または初期のデータ キーを使用して送信する可能性があることに注意してください。クライアントがそのようなアラートを送信する必要がある場合、可能であれば最初にハンドシェイク キーのキーを再作成する必要があります (SHOULD)。
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 | | Cert-based 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),
(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),
general_error(117),
no_application_protocol(120),
(255)
} AlertDescription;
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; /* 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;
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<7..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, 9261 */
status_request(5), /* RFC 6066, 9846 */
supported_groups(10), /* RFC 7919, 9846 */
signature_algorithms(13), /* RFC 9846 */
use_srtp(14), /* RFC 5764 */
heartbeat(15), /* RFC 6520 */
application_layer_protocol_negotiation(16), /* RFC 7301 */
client_certificate_type(19), /* RFC 7250 */
server_certificate_type(20), /* RFC 7250 */
padding(21), /* RFC 7685 */
compress_certificate(27), /* RFC 8879 */
record_size_limit(28), /* RFC 8449 */
delegated_credential(34), /* RFC 9345 */
supported_ekt_ciphers(39), /* RFC 8870 */
pre_shared_key(41), /* RFC 9846 */
early_data(42), /* RFC 9846 */
supported_versions(43), /* RFC 9846 */
cookie(44), /* RFC 9846 */
psk_key_exchange_modes(45), /* RFC 9846 */
certificate_authorities(47), /* RFC 9846 */
oid_filters(48), /* RFC 9846 */
post_handshake_auth(49), /* RFC 9846 */
signature_algorithms_cert(50), /* RFC 9846 */
key_share(51), /* RFC 9846 */
transparency_info(52), /* RFC 9162 */
external_id_hash(55), /* RFC 8844 */
external_session_id(56), /* RFC 8844 */
quic_transport_parameters(57), /* RFC 9001 */
ticket_request(58), /* RFC 9149 */
ech_outer_extensions(64768), /* RFC 9849 */
encrypted_client_hello(65037), /* RFC 9849 */
(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<0..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-1>;
} NewSessionTicket;
struct {} EndOfEarlyData;
enum {
update_not_requested(0), update_requested(1), (255)
} KeyUpdateRequest;
struct {
KeyUpdateRequest request_update;
} KeyUpdate;
A 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;
+===========+=======================================================+
| Component | Contents |
+===========+=======================================================+
| TLS | The string "TLS" |
+-----------+-------------------------------------------------------+
| AEAD | The AEAD algorithm used for record protection |
+-----------+-------------------------------------------------------+
| HASH | The hash algorithm used with HKDF and |
| | Transcript-Hash |
+-----------+-------------------------------------------------------+
| VALUE | The two byte ID assigned for this cipher |
| | suite |
+-----------+-------------------------------------------------------+
Table 4: Cipher Suite Name Structure
表 4: 暗号スイート名の構造
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} |
+------------------------------+-------------+
Table 5: Cipher Suite List
表 5: 暗号スイートのリスト
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. [RFC8448] provides test vectors for TLS 1.3 handshakes.
TLS プロトコルでは、多くの一般的なセキュリティ上の間違いを防ぐことはできません。この付録では、実装者を支援するためのいくつかの推奨事項を提供します。[RFC8448] は、TLS 1.3 ハンドシェイクのテスト ベクトルを提供します。
TLS requires a cryptographically secure pseudorandom number generator (CSPRNG). A performant and appropriately secure CSPRNG is provided by most operating systems or can be sourced from a cryptographic library. 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) が必要です。パフォーマンスが高く、適切に安全な CSPRNG は、ほとんどのオペレーティング システムによって提供されるか、暗号化ライブラリから入手できます。新しい CSPRNG 実装を作成するよりも、既存の 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] and [DSA-1571-1].
TLS は、(1) ClientHello および ServerHello のパブリック ランダム値などのパブリック プロトコル フィールドでランダム値を使用し、(2) キーマテリアルを生成します。CSPRNG が適切に機能している場合、その出力から CSPRNG の状態を判断することは不可能であるため、セキュリティ上の問題は発生しません。ただし、壊れた CSPRNG では、[CHECKOWAY] および [DSA-1571-1] に記載されているように、攻撃者がパブリック出力を使用して CSPRNG の内部状態を判断し、それによって鍵マテリアルを予測することが可能になる可能性があります。
Implementations can provide extra security against this form of attack by using separate CSPRNGs to generate public and private values.
実装では、個別の CSPRNG を使用してパブリック値とプライベート値を生成することで、この形式の攻撃に対する追加のセキュリティを提供できます。
[RFC8937] describes a way for security protocol implementations to augment their (pseudo)random number generators using a long-term private key and a deterministic signature function. This improves randomness from broken or otherwise subverted random number generators.
[RFC8937] では、セキュリティ プロトコルの実装が、長期秘密鍵と決定論的署名関数を使用して (擬似) 乱数生成器を強化する方法について説明しています。これにより、壊れた、または破壊された乱数生成器によるランダム性が向上します。
Implementations are responsible for verifying the integrity of certificates and should generally support certificate revocation messages; see Section 4.5.1.1. 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.
実装は証明書の整合性を検証する責任があり、通常は証明書失効メッセージをサポートする必要があります。セクション4.5.1.1を参照してください。アプリケーション プロファイルに特定の指示がない限り、証明書は常に検証され、信頼できる認証局 (CA) による適切な署名が保証される必要があります。トラストアンカーの選択と追加は、非常に慎重に行う必要があります。ユーザーは、証明書とトラスト アンカーに関する情報を表示できる必要があります。アプリケーションは、最小および最大の鍵サイズを強制する必要があります(SHOULD)。たとえば、2048 ビット RSA または 224 ビット ECDSA よりも弱いキーまたは署名を含む認証パスは、安全なアプリケーションには適していません。
Note that it is common practice in some protocols to use the same certificate in both client and server modes. This setting has not been extensively analyzed, and it is the responsibility of the higher-level protocol to ensure there is no ambiguity in this case about the higher-level semantics.
一部のプロトコルでは、クライアント モードとサーバー モードの両方で同じ証明書を使用することが一般的であることに注意してください。この設定は広範に分析されていないため、この場合、上位レベルのセマンティクスに関してあいまいさがないようにするのは上位レベルのプロトコルの責任です。
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. Certificate compression as defined in [RFC8879] can be used to reduce the risk of fragmentation.
* 複数の TLS レコードに断片化されたハンドシェイク メッセージを正しく処理していますか (セクション 5.1 を参照)。いくつかの小さなフラグメントに分割された ClientHello のような特殊なケースを正しく処理できますか?最大フラグメント サイズを超えるハンドシェイク メッセージをフラグメント化しますか?特に、Certificate および CertificateRequest ハンドシェイク メッセージは、断片化が必要になるほど大きくなる可能性があります。[RFC8879] で定義されている証明書圧縮を使用すると、断片化のリスクを軽減できます。
* Do you ignore the TLS record layer version number in all unencrypted TLS records (see Appendix E)?
* すべての暗号化されていない TLS レコードの TLS レコード層のバージョン番号を無視しますか (付録 E を参照)。
* 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 E)?
* SSL、RC4、EXPORT 暗号、および MD5 (「signature_algorithms」拡張子による) のすべてのサポートが、TLS 1.3 以降をサポートするすべての可能な構成から完全に削除され、これらの廃止された機能を使用しようとすると正常に失敗することを確認しましたか (付録 E を参照)。
* 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.5.1)?
* サーバーがクライアント証明書を要求したが、適切な証明書が利用できない場合、メッセージ全体を省略するのではなく、空の証明書メッセージを正しく送信しますか (セクション 4.5.1 を参照)。
* 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.2.2), hello extensions (Section 4.3), named groups (Section 4.3.7), key shares (Section 4.3.8), supported versions (Section 4.3.1), and signature algorithms (Section 4.3.3) in the ClientHello?
* ClientHello 内の認識されない暗号スイート (セクション 4.2.2)、hello 拡張機能 (セクション 4.3)、名前付きグループ (セクション 4.3.7)、キー共有 (セクション 4.3.8)、サポートされているバージョン (セクション 4.3.1)、および署名アルゴリズム (セクション 4.3.3) を適切に無視していますか?
* As a server, do you send a HelloRetryRequest to clients which support a compatible asymmetric key exchange group but do not predict it in the "key_share" extension? As a client, do you correctly handle a HelloRetryRequest from the server?
* サーバーとして、互換性のある非対称鍵交換グループをサポートしているが、「key_share」拡張機能でそれを予測していないクライアントに HelloRetryRequest を送信しますか?クライアントとして、サーバーからの HelloRetryRequest を正しく処理していますか?
Cryptographic details:
暗号化の詳細:
* What countermeasures do you use to prevent timing attacks [TIMING]?
* タイミング攻撃[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.3.8.1)?
* TLS クライアントは、サーバーから送信された Diffie-Hellman パラメータが受け入れられるかどうかをチェックしていますか (セクション 4.3.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]. Note that purely deterministic Elliptic Curve Cryptography (ECC) signatures such as deterministic ECDSA and EdDSA may be vulnerable to certain side-channel and fault injection attacks in easily accessible Internet of Things (IoT) devices.
* Diffie-Hellman プライベート値、ECDSA の「k」パラメータ、およびその他のセキュリティ上重要な値を生成するときに、強力で、最も重要なことに、適切にシードされた乱数生成器 (付録 C.1 を参照) を使用していますか?実装では、[RFC6979] で指定されている「決定論的 ECDSA」を実装することが推奨されます。決定論的 ECDSA や EdDSA などの純粋に決定論的楕円曲線暗号 (ECC) 署名は、簡単にアクセスできるモノのインターネット (IoT) デバイスにおける特定のサイドチャネル攻撃やフォールト インジェクション攻撃に対して脆弱である可能性があることに注意してください。
* Do you zero-pad Diffie-Hellman public key values and shared secrets to the group size (see Section 4.3.8.1 and Section 7.4.1)?
* Diffie-Hellman 公開鍵の値と共有秘密をグループ サイズに合わせてゼロ埋めしますか (セクション 4.3.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 [RFC9112] 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 [RFC9112] を使用する Web ブラウザは、サーバーに対して 6 つの接続を開く可能性があります。サーバーは接続ごとに新しいチケットを発行すべきです(SHOULD)。これにより、クライアントは新しい接続を作成するときに常に新しいチケットを使用できるようになります。
Offering a ticket to a server additionally allows the server to correlate different connections. This is possible independent of ticket reuse. Client applications SHOULD NOT offer tickets across connections that are meant to be uncorrelated. For example, [FETCH] defines network partition keys to separate cache lookups in web browsers.
さらに、サーバーにチケットを提供すると、サーバーはさまざまな接続を関連付けることができます。これはチケットの再利用とは関係なく可能です。クライアント アプリケーションは、無相関であることが意図されている接続間でチケットを提供すべきではありません。たとえば、[FETCH] は、Web ブラウザでのキャッシュ ルックアップを分離するネットワーク パーティション キーを定義します。
It is RECOMMENDED that the labels for external identities be selected so that they do not provide additional information about the identity of the user. For instance, if the label includes an email address, then this trivially identifies the user to a passive attacker, unlike the client's Certificate, which is encrypted. There are a number of potential ways to avoid this risk, including (1) using random identity labels, (2) pre-encrypting the identity under a key known to the server, or (3) using Encrypted Client Hello [RFC9849].
外部アイデンティティのラベルは、ユーザーのアイデンティティに関する追加情報を提供しないように選択することが推奨されます。たとえば、ラベルに電子メール アドレスが含まれている場合、暗号化されているクライアントの証明書とは異なり、受動的な攻撃者に対してユーザーが簡単に識別されてしまいます。このリスクを回避するには、(1) ランダムな ID ラベルを使用する、(2) サーバーに既知のキーで ID を事前暗号化する、または (3) Encrypted Client Hello [RFC9849] を使用するなど、多くの方法が考えられます。
If an external PSK identity is used for multiple connections, then it will generally be possible for an external observer to track clients and/or servers across connections. Use of Encrypted Client Hello [RFC9849] can mitigate this risk, as can mechanisms external to TLS that rotate or encrypt the PSK identity.
外部 PSK ID が複数の接続に使用される場合、通常、外部オブザーバーが接続全体でクライアントやサーバーを追跡することが可能になります。Encrypted Client Hello [RFC9849] を使用すると、PSK ID をローテーションまたは暗号化する TLS 外部のメカニズムと同様に、このリスクを軽減できます。
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 an 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 を使用してはなりません (MUST NOT)。
To align with the names used this document, the following terms from [RFC5246] are renamed:
この文書で使用されている名前に合わせるために、[RFC5246] の次の用語の名前が変更されています。
* The master secret, computed in Section 8.1 of [RFC5246], is renamed to the main secret. It is referred to as main_secret in formulas and structures, instead of master_secret. However, the label parameter to the PRF function is left unchanged for compatibility.
* [RFC5246] のセクション 8.1 で計算されたマスター シークレットは、メイン シークレットに名前変更されます。式や構造では、master_secret ではなく main_secret と呼ばれます。ただし、PRF 関数の label パラメータは互換性のために変更されません。
* The premaster secret is renamed to the preliminary secret. It is referred to as preliminary_secret in formulas and structures, instead of pre_master_secret.
* プレマスター シークレットの名前が予備シークレットに変更されます。式や構造では、pre_master_secret ではなく、preliminary_secret と呼ばれます。
* The PreMasterSecret and EncryptedPreMasterSecret structures, defined in Section 7.4.7.1 of [RFC5246], are renamed to PreliminarySecret and EncryptedPreliminarySecret, respectively.
* [RFC5246] のセクション 7.4.7.1 で定義されている PreMasterSecret 構造と EncryptedPreMasterSecret 構造は、それぞれ PreliminarySecret と EncryptedPreliminarySecret に名前が変更されます。
Correspondingly, the extension defined in [RFC7627] is renamed to the "Extended Main Secret" extension. The extension code point is renamed to "extended_main_secret". The label parameter to the PRF function in Section 4 of [RFC7627] is left unchanged for compatibility.
これに対応して、[RFC7627] で定義されている拡張機能は「Extended Main Secret」拡張機能に名前が変更されます。拡張コード ポイントの名前が「extended_main_secret」に変更されます。[RFC7627] のセクション 4 にある PRF 関数の label パラメータは、互換性のために変更されません。
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). 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 の値は、すべての実装で無視されなければなりません (MUST)。TLSCiphertext.legacy_record_version の値は保護解除用の追加データに含まれますが、それ以外の場合は無視してもよいし、固定定数値と一致するか検証してもよいです。バージョン ネゴシエーションは、ハンドシェイク バージョン (ClientHello.legacy_version および ServerHello.legacy_version、および ClientHello、HelloRetryRequest、および ServerHello の「supported_versions」拡張機能) のみを使用して実行されます。古いエンドポイントとの相互運用性を最大限に高めるために、TLS 1.0 ～ 1.2 の使用をネゴシエートする実装では、レコード層のバージョン番号を、ServerHello とそれ以降のすべてのレコードのネゴシエートされたバージョンに設定する必要があります (SHOULD)。
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.5.1.2).
以前の非標準的な動作や誤って設定された展開との互換性を最大限に高めるために、すべての実装は、以前の TLS バージョンのハンドシェイクを処理する場合でも、この文書の期待に基づいた認証パスの検証をサポートすべきです (セクション 4.5.1.2 を参照)。
TLS 1.2 and prior supported an "Extended Main Secret" [RFC7627] extension which digested large parts of the handshake transcript into the secret and derived keys. Note this extension was renamed in Appendix D. 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 Main Secret extension in their APIs whenever TLS 1.3 is used.
TLS 1.2 以前は、ハンドシェイク トランスクリプトの大部分を秘密キーと派生キーにダイジェストする「Extended Main Secret」[RFC7627] 拡張機能をサポートしていました。この拡張機能は付録 D で名前が変更されたことに注意してください。TLS 1.3 は常にサーバーの Finished までのトランスクリプト内でハッシュするため、TLS 1.3 とそれ以前のバージョンの両方をサポートする実装では、TLS 1.3 が使用されるときは常に API で Extended Main Secret 拡張機能の使用を示す必要があります (SHOULD)。
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 で応答します。クライアントがこのバージョンの使用に同意すると、ネゴシエートされたプロトコルに応じてネゴシエーションが続行されます。再開のためにチケットを使用するクライアントは、以前にネゴシエートされたバージョンを使用して接続を開始する必要があります (SHOULD)。
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 E.3.
0-RTT データは古いサーバーと互換性がないため、サーバーが TLS 1.3 をサポートしているという知識なしに送信すべきではないことに注意してください。付録 E.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」アラートでハンドシェイクを中止しなければなりません (MUST)。
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 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.3.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.3.1 で説明されているように、その拡張子を使用してネゴシエートしなければなりません (MUST)。「supported_versions」拡張子が存在しない場合、サーバーは最低限の ClientHello.legacy_version と TLS 1.2 をネゴシエートしなければなりません (MUST)。たとえば、サーバーが TLS 1.0、1.1、および 1.2 をサポートし、legacy_version が TLS 1.0 の場合、サーバーは TLS 1.0 ServerHello を続行します。"supported_versions" 拡張子が存在せず、サーバーが ClientHello.legacy_version より大きいバージョンのみをサポートする場合、サーバーは "protocol_version" アラートでハンドシェイクを中止しなければなりません (MUST)。
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 バージョンを受け取りますが、その値は常に無視されなければなりません (MUST)。
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 を受信した場合、接続に失敗しなければなりません (MUST)。その後、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 の均一で安定した展開を確保する必要があります (SHOULD)。
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.2.2.
* セクション 4.2.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 暗号スイートが利用可能な場合はそれを優先する必要があります (SHOULD)。
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 2.0 [SSL2], SSL 3.0 [RFC6101], TLS 1.0 [RFC2246], and TLS 1.1 [RFC4346] are considered insufficient for the reasons enumerated in [RFC6176], [RFC7568], and [RFC8996] and they MUST NOT be negotiated for any reason.
SSL 2.0 [SSL2]、SSL 3.0 [RFC6101]、TLS 1.0 [RFC2246]、および TLS 1.1 [RFC4346] のセキュリティは、[RFC6176]、[RFC7568]、および [RFC8996] に列挙されている理由により不十分であると考えられており、いかなる理由でもネゴシエートしてはなりません (MUST NOT)。
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 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 use 0x0303 for the ClientHello.legacy_version and ServerHello.legacy_version. Implementations receiving Hello messages with other version numbers MUST abort the handshake as described in Section 4.2.2 and Section 4.2.3.
実装では、ClientHello.legacy_version と ServerHello.legacy_version に 0x0303 を使用する必要があります。他のバージョン番号の Hello メッセージを受信する実装は、セクション 4.2.2 およびセクション 4.2.3 で説明されているようにハンドシェイクを中止しなければなりません (MUST)。
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 未満のレコードを送信してはなりません (MUST NOT)。実装は、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 main secret) from which a set of working keys can be derived. Note that when early data is in use, secrets are also derived from the early secret. These enjoy somewhat weaker properties than those derived from the main secret, as detailed below.
* 一連の作業キーを導出できる一連の「セッション キー」(メイン シークレットから派生したさまざまなシークレット)。初期のデータが使用されている場合、シークレットも初期のシークレットから派生することに注意してください。これらは、以下で詳しく説明するように、主要な秘密から派生したものよりも若干弱い特性を享受します。
* A set of cryptographic parameters (algorithms, etc.).
* 暗号化パラメーター (アルゴリズムなど) のセット。
* The identities of the communicating parties.
* 通信当事者の ID。
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 asymmetric key exchange 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 (and all material that could be used to recreate the session key) has been erased. In particular, private keys corresponding to key shares, shared secrets, and keys derived in the TLS key schedule other than binder_key, resumption_secret, and PSKs derived from the resumption_secret also need to be erased. The forward secrecy property is not satisfied when PSK is used in the "psk_ke" PskKeyExchangeMode. Failing to erase keys or secrets intended to be ephemeral or connection-specific in effect creates additional long-term keys that must be protected. Compromise of those long-term keys (even after the handshake is complete) can result in loss of protection for the connection's traffic.
ハンドシェイク完了後に長期鍵マテリアル (この場合、証明書ベースの認証モードの署名鍵、または非対称鍵交換モードの PSK の外部/再開 PSK) が侵害された場合でも、セッション鍵自体 (およびセッション鍵の再作成に使用できるすべてのマテリアル) が消去されている限り、セッション鍵のセキュリティーは侵害されません ([DOW92] を参照)。特に、鍵共有、共有秘密、および binding_key、resumption_secret、および resumption_secret から派生した PSK 以外の TLS 鍵スケジュールで派生した鍵に対応する秘密鍵も消去する必要があります。PSK が「psk_ke」PskKeyExchangeMode で使用されている場合、Forward Secrecy プロパティは満たされません。一時的または接続固有であることを意図したキーまたはシークレットの消去に失敗すると、実質的に保護する必要がある追加の長期キーが作成されます。これらの長期キーが侵害されると (ハンドシェイクが完了した後でも)、接続トラフィックの保護が失われる可能性があります。
Key Compromise Impersonation (KCI) resistance:
主要な侵害偽装 (KCI) に対する耐性:
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.
証明書を使用した相互認証された接続では、1 つのアクターの長期秘密が侵害されても、その接続におけるピアのそのアクターの認証が破られるべきではありません ([HGFS15] を参照)。たとえば、クライアントの署名キーが侵害された場合、その後のハンドシェイクでそのクライアントに対して任意のサーバーになりすますことはできません。
Protection of endpoint identities:
エンドポイント ID の保護:
The server's identity (certificate) should be protected against passive attackers. The client's identity (certificate) should be protected against both passive and active attackers. This property does not hold for cipher suites without confidentiality; while this specification does not define any such cipher suites, other documents may do so.
サーバーの ID (証明書) は、受動的攻撃者から保護される必要があります。クライアントの ID (証明書) は、受動的攻撃者と能動的攻撃者の両方から保護される必要があります。この性質は、機密性のない暗号スイートには当てはまりません。この仕様ではそのような暗号スイートは定義されていませんが、他の文書では定義されている可能性があります。
Informally, the signature-based modes of TLS 1.3 provide for the establishment of a unique, secret, shared key established by an asymmetric 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 asymmetric keys are used for each connection, then the output keys are forward secret.
非公式には、TLS 1.3 の署名ベース モードは、非対称キー交換によって確立され、ハンドシェイク トランスクリプト上のサーバーの署名によって認証される一意の秘密の共有キーの確立を提供します。また、MAC によってサーバーの ID に関連付けられます。クライアントが証明書によって認証されている場合、ハンドシェイク記録にも署名し、両方の ID に関連付けられた MAC を提供します。[SIGMA] は、このタイプの鍵交換プロトコルの設計と分析について説明しています。新しい非対称キーが接続ごとに使用される場合、出力キーは前方秘密になります。
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 asymmetric key establishment is used, these session keys will also be forward secret. The resumption PSK has been designed so that the resumption 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 は、長期共有シークレットから短期セッション キーの接続ごとの一意のセットにブートストラップします。この秘密は、以前のハンドシェイクで確立された可能性があります。非対称キー確立による PSK が使用される場合、これらのセッション キーも前方秘密になります。再開 PSK は、接続 N によって計算され、接続 N+1 の形成に必要な再開秘密が、接続 N によって使用されるトラフィック キーから分離されるように設計されており、これにより、接続間に前方秘密が提供されます。さらに、複数のチケットが同じ接続上で確立されている場合、それらは異なるキーに関連付けられているため、1 つのチケットに関連付けられた PSK が侵害されても、他のチケットに関連付けられた PSK で確立された接続の侵害にはつながりません。このプロパティは、チケットが自己暗号化されている場合ではなく、チケットがデータベースに保存されている (したがって削除できる) 場合に最も興味深いです。
Forward secrecy limits the effect of key leakage in one direction (compromise of a key at time T2 does not compromise some key at time T1 where T1 < T2). Protection in the other direction (compromise at time T1 does not compromise keys at time T2) can be achieved by rerunning an asymmetric key establishment. If a long-term authentication key has been compromised, a full handshake with asymmetric key establishment gives protection against passive attackers. If the resumption_secret has been compromised, a resumption handshake with asymmetric key establishment gives protection against passive attackers and a full handshake with asymmetric key establishment gives protection against active attackers. If a traffic secret has been compromised, any handshake with asymmetric key establishment gives protection against active attackers. Using the terms in [RFC7624], forward secrecy without rerunning asymmetric key establishment does not stop an attacker from doing static key exfiltration. After key exfiltration of application_traffic_secret_N, an attacker can, e.g., passively eavesdrop on all future data sent on the connection including data encrypted with application_traffic_secret_N+1, application_traffic_secret_N+2, etc. Frequently rerunning asymmetric key establishment forces an attacker to do dynamic key exfiltration (or content exfiltration).
Forward Secrecy は、一方向のキー漏洩の影響を制限します (時間 T2 でのキーの侵害は、時間 T1 (T1 < T2) での一部のキーの侵害にはなりません)。逆方向の保護 (時間 T1 での侵害が時間 T2 での鍵の侵害にならない) は、非対称鍵の確立を再実行することで実現できます。長期認証キーが侵害された場合、非対称キーの確立によるフル ハンドシェイクにより、受動的な攻撃者から保護されます。resumption_secret が侵害された場合、非対称キーの確立を伴う再開ハンドシェイクは受動的な攻撃者に対する保護を提供し、非対称キーの確立を伴う完全なハンドシェイクは能動的な攻撃者に対する保護を提供します。トラフィック秘密が侵害された場合、非対称キーの確立によるハンドシェイクにより、積極的な攻撃者から保護されます。[RFC7624] の用語を使用すると、非対称鍵の確立を再実行しない前方秘匿性は、攻撃者による静的鍵の漏洩を阻止しません。application_traffic_secret_N のキーの漏洩後、攻撃者は、たとえば、application_traffic_secret_N+1、application_traffic_secret_N+2 などで暗号化されたデータを含む、接続上で送信される今後のすべてのデータを受動的に盗聴する可能性があります。非対称キーの確立を頻繁に再実行すると、攻撃者は動的なキーの漏洩 (またはコンテンツの漏洩) を実行することになります。
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 (if established via a NewSessionTicket message) and the current session. This binding transitively includes the original handshake transcript, because that transcript is digested into the values which produce the resumption secret. This requires that both the KDF used to produce the resumption secret and the MAC used to compute the binder be collision resistant. See Appendix F.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 が確立されたセッション (NewSessionTicket メッセージによって確立された場合) と現在のセッションの間のバインディングを形成します。このバインディングには、元のハンドシェイク トランスクリプトが推移的に含まれます。これは、そのトランスクリプトが再開シークレットを生成する値に消化されるためです。これには、再開シークレットの生成に使用される KDF と、バインダーの計算に使用される MAC の両方が衝突耐性がある必要があります。詳細については、付録 F.1.1 を参照してください。注: バインダーは、他の PSK からのバインダー値をカバーしていませんが、それらは完成した MAC に含まれています。
Note: This specification does not currently permit the server to send a CertificateRequest 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. In the absence of some other specification to the contrary, implementations MUST NOT combine external PSKs with certificate-based authentication of either the client or server. [RFC8773] provides an extension to permit this, but has not received the level of analysis as this specification.
注: この仕様では現在、サーバーが非証明書ベースのハンドシェイク (PSK など) で CertificateRequest メッセージを送信することを許可していません。将来この制限が緩和された場合、クライアントの署名はサーバーの証明書を直接カバーしなくなります。ただし、PSK が NewSessionTicket を通じて確立された場合、クライアントの署名は PSK バインダーを通じてサーバーの証明書を推移的にカバーします。[PSK-FINISHED] は、サーバーの証明書にバインドされない構造に対する具体的な攻撃について説明しています ([Kraw16] も参照)。クライアントが 2 つの異なるエンドポイントと同じ PSK/キー ID ペアを共有する可能性がある場合、証明書ベースのクライアント認証を使用するのは安全ではありません。これとは反対の仕様が他にない場合、実装は外部 PSK をクライアントまたはサーバーの証明書ベースの認証と組み合わせてはなりません (MUST NOT)。[RFC8773] はこれを可能にする拡張を提供していますが、この仕様のようなレベルの分析は受けていません。
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.2.3 allows the detection of downgrade to previous TLS versions. See [BBFGKZ16] for more details on TLS 1.3 and downgrade.
すべてのハンドシェイク モードで、Finished MAC (および存在する場合は署名) はダウングレード攻撃を防止します。さらに、セクション 4.2.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.
クライアントとサーバーが共有キーを確立するのに十分な情報を交換するとすぐに、ハンドシェイクの残りの部分が暗号化されるため、たとえ計算された共有キーが認証されていなくても、受動的な攻撃者から保護されます。サーバーはクライアントの前に認証を行うため、クライアントは、サーバーに対して認証する場合、認証されたサーバーに対してのみその ID を明らかにすることができます。長さによる ID に関する情報の漏洩を避けるために、実装ではハンドシェイク中に提供されたレコード パディング メカニズムを使用する必要があることに注意してください。クライアントが提案した PSK ID は暗号化されず、サーバーが選択した PSK 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 での HKDF の使用方法の理論的根拠は [KW16] にあります。このドキュメント全体を通じて、HKDF-Extract の各アプリケーションの後に、1 つ以上の HKDF-Expand の呼び出しが続きます。この順序は常に従う必要があります (このドキュメントの将来の改訂も含みます)。特に、HKDF-Expand を間に挟まずに、HKDF-Extract の出力を HKDF-Extract の別のアプリケーションへの入力として使用すべきではありません (SHOULD NOT)。キーやラベルによって区別されている限り、同じ入力の一部に対する 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_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_secret の生成) では、HKDF-Expand のアプリケーションが衝突耐性がある必要があります。つまり、同じ値を出力する HKDF-Expand への 2 つの異なる入力を見つけることは不可能であるはずです。これには、基礎となるハッシュ関数が衝突耐性があり、HKDF-Expand からの出力長が少なくとも 256 ビット (または衝突の発見を防ぐためにハッシュ関数に必要な長さ) であることが必要です。
A client that has sent certificate-based 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 データと同様のセキュリティ プロパティを提供します。ただし、0-RTT 暗号化キーが完全な前方機密性を提供しないことと、サーバーが潜在的に不当な量の状態を保持せずにハンドシェイクの一意性 (非再生可能性) を保証できないという 2 つの例外があります。リプレイへの露出を制限するメカニズムについては、セクション 8 を参照してください。
The exporter_secret and early_exporter_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_secret, followed by each inner values as soon as it is known that it will not be needed again.
exporter_secret とearly_exporter_secret はトラフィック キーから独立して派生するため、これらのキーで暗号化されたトラフィックのセキュリティに対する脅威にはなりません。ただし、これらのシークレットはエクスポーター値の計算に使用できるため、できるだけ早く消去する必要があります。エクスポータ ラベルの合計セットがわかっている場合、実装はそれらすべてのラベルについてエクスポータ計算の内部 Derive-Secret ステージを事前に計算し、[early_]exporter_secret を消去し、その後、再度必要でないことがわかったらすぐに各内部値を消去する必要があります (SHOULD)。
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 backwards 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 抵抗とは対照的です。
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.7.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.7.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 の場合が一般的です)、大量の暗号解析を防ぐために、シーケンス番号と、トラフィック キーとともに導出される接続ごとの秘密の初期化ベクトルを混合することによって、ノンスが形成されます。この構造の分析については [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] で説明されているシリアル ジェネレーターの構造に従っており、キー再生成により、キー再生成を行わない場合よりも多くの暗号化に鍵を使用できることが示されています。これは、擬似乱数関数 (PRF) としての HKDF-Expand-Label 関数のセキュリティに依存しています。さらに、この関数が真に一方向である限り、キーの変更前からトラフィック キーを計算することはできません (前方秘密保持)。
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 asymmetric key exchange.
TLS は、接続のトラフィック秘密が侵害された後にその接続上で通信されるデータに対してセキュリティを提供しません。つまり、TLS は、トラフィック秘密に関して侵害後のセキュリティ/将来の秘密/後方秘密を提供しません。実際、トラフィック シークレットを知った攻撃者は、その接続上で将来のすべてのトラフィック シークレットを計算できます。このような保証を必要とするシステムは、新たなハンドシェイクを実行し、非対称鍵交換による新しい接続を確立する必要があります。
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 to reorder them with respect to other messages (e.g., moving a delete to after a create).
* 攻撃者は、0-RTT メッセージを保存および再生して、他のメッセージとの順序を変更することができます (例: 削除を作成の後に移動するなど)。
* Amplifying existing information leaks caused by side effects like caching. An attacker could learn information about the content of a 0-RTT message by replaying it to some cache node that has not cached some resource of interest, and then using a separate connection to check whether that resource has been added to the cache. This could be repeated with different cache nodes as often as the 0-RTT message is replayable.
* キャッシュなどの副作用によって引き起こされる既存の情報漏洩を拡大します。攻撃者は、対象のリソースをキャッシュしていないキャッシュ ノードに 0-RTT メッセージを再生し、別の接続を使用してそのリソースがキャッシュに追加されているかどうかを確認することで、0-RTT メッセージの内容に関する情報を知る可能性があります。これは、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 ハンドシェイクにフォールバックします。アプリケーション層プロトコルがこの設定でデータを再送信する場合、攻撃者は元のクラスタ (データをすぐに処理する) と、アプリケーション層の再生時に 1-RTT にフォールバックしてデータを処理する別のクラスタの両方に ClientHello を送信することにより、メッセージの重複を誘発する可能性があります。この攻撃の規模は、クライアントがトランザクションを再試行するかどうかによって制限されるため、限られた量の複製のみが許可され、各コピーはサーバーで新しい接続として表示されます。
If implemented correctly, the mechanisms described in Section 8.1 and Section 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 データを使用してはなりません (MUST NOT)。このプロファイルでは、どのメッセージやインタラクションが 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 (送信または受信のいずれか) を有効にしてはなりません (MUST NOT)。また、アプリケーションから指示がない限り、サーバーによって拒否された場合に 0-RTT データを自動的に再送信してはなりません (MUST NOT)。サーバー側アプリケーションは、ある種のアプリケーション トラフィックの 0-RTT データに対する特別な処理を実装することを希望する場合があります (接続の中止、アプリケーション層でのデータの再送信の要求、ハンドシェイクが完了するまで処理の遅延など)。アプリケーションがこの種の処理を実装できるようにするために、TLS 実装は、ハンドシェイクが完了したかどうかをアプリケーションが判断する方法を提供しなければなりません (MUST)。
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.
さらに、初期のエクスポータは、サーバーからクライアントへの暗号化キーを生成するために使用すべきではありません（SHOULD NOT）。これは、それらのキーの再利用を必要とするためです。これは、初期のアプリケーション トラフィック キーをクライアントからサーバーの方向にのみ使用するのと同様です。
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 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 を再利用しないことで、クロスプロトコル関連の出力からの安全性を確保できます。
External PSKs in TLS are designed to be known to exactly one client and one server. However, as noted in [RFC9257], there are use cases where PSKs are shared between more than two entities. In such scenarios, in addition to the expected security weakness where a compromised group member can impersonate any other member, a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways [Selfie]. [RFC9257] provides recommendations for external PSK usage, including the use of external PSK importers as defined in [RFC9258], that prevent such malicious rerouting of messages.
TLS の外部 PSK は、1 つのクライアントと 1 つのサーバーにのみ認識されるように設計されています。ただし、[RFC9257] に記載されているように、PSK が 3 つ以上のエンティティ間で共有されるユースケースもあります。このようなシナリオでは、侵害されたグループ メンバーが他のメンバーになりすますことができるという予想されるセキュリティ上の弱点に加えて、悪意のある非メンバーが誠実なグループ メンバー間のハンドシェイクを再ルーティングして、意図しない方法で接続する可能性があります [Selfie]。[RFC9257] は、[RFC9258] で定義されている外部 PSK インポーターの使用を含む、このような悪意のあるメッセージの再ルーティングを防止する外部 PSK の使用に関する推奨事項を提供しています。
When TLS 1.3 is used with self-signed certificates without useful identities (as in DTLS-SRTP [RFC5763]) or raw public keys [RFC7250] for peer authentication, it may be vulnerable to misbinding attacks [MM24]. This risk can be mitigated by using the "external_id_hash" extension [RFC8844] or, if only the server is being authenticated, by the server verifying that the "server_name" extension matches its expected identity.
TLS 1.3 が、有効な ID (DTLS-SRTP [RFC5763] など) やピア認証用の生の公開鍵 [RFC7250] のない自己署名証明書とともに使用される場合、ミスバインディング攻撃 [MM24] に対して脆弱になる可能性があります。このリスクは、「external_id_hash」拡張子 [RFC8844] を使用することによって、またはサーバーのみが認証されている場合は、「server_name」拡張子が期待される ID と一致することをサーバーが検証することによって軽減できます。
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 ビットが設定されていない証明書内のキーを使用した署名の受け入れをクライアントが拒否することに依存しており、多くのクライアントはこの制限を強制しません。
Martin Abadi
University of California, Santa Cruz
abadi@cs.ucsc.edu
Christopher Allen
(co-editor of TLS 1.0)
Alacrity Ventures
ChristopherA@AlacrityManagement.com
Nimrod Aviram
Tel Aviv University
nimrod.aviram@gmail.com
Richard Barnes
Cisco
rlb@ipv.sx
Steven M. Bellovin
Columbia University
smb@cs.columbia.edu
David Benjamin
Google
davidben@google.com
Benjamin Beurdouche
INRIA & Microsoft Research
benjamin.beurdouche@ens.fr
Karthikeyan Bhargavan
(editor of RFC 7627)
INRIA
karthikeyan.bhargavan@inria.fr
Simon Blake-Wilson
(co-author of RFC 4492)
BCI
sblakewilson@bcisse.com
Nelson Bolyard
(co-author of RFC 4492)
Sun Microsystems, Inc.
nelson@bolyard.com
Ran Canetti
IBM
canetti@watson.ibm.com
Matt Caswell
OpenSSL
matt@openssl.org
Stephen Checkoway
University of Illinois at Chicago
sfc@uic.edu
Pete Chown
Skygate Technology Ltd
pc@skygate.co.uk
Katriel Cohn-Gordon
University of Oxford
me@katriel.co.uk
Cas Cremers
University of Oxford
cas.cremers@cs.ox.ac.uk
Antoine Delignat-Lavaud
(co-author of RFC 7627)
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
Roelof DuToit
Symantec Corporation
roelof_dutoit@symantec.com
Taher Elgamal
Securify
taher@securify.com
Pasi Eronen
Nokia
pasi.eronen@nokia.com
Cedric Fournet
Microsoft
fournet@microsoft.com
Anil Gangolli
anil@busybuddha.org
David M. Garrett
dave@nulldereference.com
Illya Gerasymchuk
Independent
illya@iluxonchik.me
Alessandro Ghedini
Cloudflare Inc.
alessandro@cloudflare.com
Daniel Kahn Gillmor
ACLU
dkg@fifthhorseman.net
Matthew Green
Johns Hopkins University
mgreen@cs.jhu.edu
Jens Guballa
ETAS
jens.guballa@etas.com
Felix Guenther
TU Darmstadt
mail@felixguenther.info
Vipul Gupta
(co-author of RFC 4492)
Sun Microsystems Laboratories
vipul.gupta@sun.com
Chris Hawk
(co-author of RFC 4492)
Corriente Networks LLC
chris@corriente.net
Kipp Hickman
Alfred Hoenes
David Hopwood
Independent Consultant
david.hopwood@blueyonder.co.uk
Marko Horvat
MPI-SWS
mhorvat@mpi-sws.org
Jonathan Hoyland
Royal Holloway, University of London
jonathan.hoyland@gmail.com
Subodh Iyengar
Facebook
subodh@fb.com
Benjamin Kaduk
Akamai Technologies
kaduk@mit.edu
Hubert Kario
Red Hat Inc.
hkario@redhat.com
Phil Karlton
(co-author of SSL 3.0)
Leon Klingele
Independent
mail@leonklingele.de
Paul Kocher
(co-author of SSL 3.0)
Cryptography Research
paul@cryptography.com
Hugo Krawczyk
IBM
hugokraw@us.ibm.com
Adam Langley
(co-author of RFC 7627)
Google
agl@google.com
Olivier Levillain
ANSSI
olivier.levillain@ssi.gouv.fr
Xiaoyin Liu
University of North Carolina at Chapel Hill
xiaoyin.l@outlook.com
Ilari Liusvaara
Independent
ilariliusvaara@welho.com
Atul Luykx
K.U. Leuven
atul.luykx@kuleuven.be
Colm MacCarthaigh
Amazon Web Services
colm@allcosts.net
Carl Mehner
USAA
carl.mehner@usaa.com
Jan Mikkelsen
Transactionware
janm@transactionware.com
Bodo Moeller
(co-author of RFC 4492)
Google
bodo@acm.org
Kyle Nekritz
Facebook
knekritz@fb.com
Erik Nygren
Akamai Technologies
erik+ietf@nygren.org
Magnus Nystrom
Microsoft
mnystrom@microsoft.com
Kazuho Oku
DeNA Co., Ltd.
kazuhooku@gmail.com
Kenny Paterson
Royal Holloway, University of London
kenny.paterson@rhul.ac.uk
Christopher Patton
University of Florida
cjpatton@ufl.edu
Alfredo Pironti
(co-author of RFC 7627)
INRIA
alfredo.pironti@inria.fr
Andrei Popov
Microsoft
andrei.popov@microsoft.com
John Preuß Mattsson
Ericsson
john.mattsson@ericsson.com
Marsh Ray
(co-author of RFC 7627)
Microsoft
maray@microsoft.com
Robert Relyea
Netscape Communications
relyea@netscape.com
Kyle Rose
Akamai Technologies
krose@krose.org
Jim Roskind
Amazon
jroskind@amazon.com
Michael Sabin
Joe Salowey
Tableau Software
joe@salowey.net
Rich Salz
Akamai
rsalz@akamai.com
David Schinazi
Apple Inc.
dschinazi@apple.com
Sam Scott
Royal Holloway, University of London
me@samjs.co.uk
Mohit Sethi
Aalto University
mohit@iki.fi
Thomas Shrimpton
University of Florida
teshrim@ufl.edu
Dan Simon
Microsoft, Inc.
dansimon@microsoft.com
Brian Smith
Independent
brian@briansmith.org
Ben Smyth
Ampersand
www.bensmyth.com
Brian Sniffen
Akamai Technologies
ietf@bts.evenmere.org
Nick Sullivan
Cloudflare Inc.
nick@cloudflare.com
Bjoern Tackmann
University of California, San Diego
btackmann@eng.ucsd.edu
Tim Taubert
Mozilla
ttaubert@mozilla.com
Martin Thomson
Mozilla
mt@mozilla.com
Hannes Tschofenig
Arm Limited
Hannes.Tschofenig@arm.com
Sean Turner
sn3rd
sean@sn3rd.com
Steven Valdez
Google
svaldez@google.com
Filippo Valsorda
Cloudflare Inc.
filippo@cloudflare.com
Thyla van der Merwe
Royal Holloway, University of London
tjvdmerwe@gmail.com
Victor Vasiliev
Google
vasilvv@google.com
Loganaden Velvindron
cyberstorm.mu
logan@cyberstorm.mu
Hoeteck Wee
Ecole Normale Superieure, Paris
hoeteck@alum.mit.edu
Tom Weinstein
David Wong
NCC Group
david.wong@nccgroup.trust
Christopher A. Wood
Apple Inc.
cawood@apple.com
Tim Wright
Vodafone
timothy.wright@vodafone.com
Peter Wu
Independent
peter@lekensteyn.nl
Kazu Yamamoto
Internet Initiative Japan Inc.
kazu@iij.ad.jp
Eric Rescorla
Independent
Email: ekr@rtfm.com