Internet Engineering Task Force (IETF) E. Rescorla
Request for Comments: 8446 Mozilla
Obsoletes: 5077, 5246, 6961 2018年8月
Updates: 5705, 6066
Category: Standards Track
ISSN: 2070-1721
Transport Layer Security (TLS) プロトコル バージョン 1.3
概要
本文書は、Transport Layer Security (TLS) プロトコルのバージョン
1.3を規定します。TLSにより、クライアント/サーバーアプリケーションは、
盗聴、改ざん、およびメッセージ偽造を防止するように設計された方法で、
インターネット上で通信できます。
本文書はRFC 5705および6066を更新し、RFC 5077、5246、および
6961を廃止します。本文書はまた、TLS 1.2実装に対する新しい要件も
規定します。
このメモの位置づけ
これはインターネット標準化過程の文書です。
本文書はInternet Engineering Task Force (IETF)の成果物です。
IETFコミュニティの合意を表しています。公開レビューを受けており、
Internet Engineering Steering Group (IESG)により公開が承認されています。
インターネット標準に関する詳細情報は、RFC 7841のSection 2で
入手できます。
本文書の現在の状態、正誤表、およびフィードバックの提供方法に関する
情報は、以下で入手できます。
https://www.rfc-editor.org/info/rfc8446.
Rescorla Standards Track [Page 1]
RFC 8446 TLS 2018年8月
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
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.
Rescorla Standards Track [Page 2]
RFC 8446 TLS 2018年8月
目次
1. はじめに ....................................................6
1.1. 表記規則および用語 ....................................7
1.2. TLS 1.2からの主な差分 .................................8
1.3. TLS 1.2に影響する更新 ..................................9
2. プロトコル概要 ..............................................10
2.1. 不正なDHE共有値 .......................................14
2.2. 再開および事前共有鍵 (PSK) ............................15
2.3. 0-RTTデータ ............................................17
3. プレゼンテーション言語 ......................................19
3.1. 基本ブロックサイズ ....................................19
3.2. その他 .................................................20
3.3. 数値 ...................................................20
3.4. ベクトル ...............................................20
3.5. 列挙型 .................................................21
3.6. 構成型 .................................................22
3.7. 定数 ...................................................23
3.8. バリアント .............................................23
4. ハンドシェイクプロトコル ....................................24
4.1. 鍵交換メッセージ .......................................25
4.1.1. 暗号ネゴシエーション ..........................26
4.1.2. Client Hello .....................................27
4.1.3. Server Hello .....................................31
4.1.4. Hello Retry Request .............................33
4.2. 拡張 ...................................................35
4.2.1. Supported Versions ...............................39
4.2.2. Cookie ...........................................40
4.2.3. Signature Algorithms .............................41
4.2.4. Certificate Authorities ..........................45
4.2.5. OID Filters ......................................45
4.2.6. ハンドシェイク後クライアント認証 ...............47
4.2.7. Supported Groups .................................47
4.2.8. Key Share ........................................48
4.2.9. Pre-Shared Key Exchange Modes ....................51
4.2.10. Early Data Indication ...........................52
4.2.11. Pre-Shared Key Extension ........................55
4.3. サーバーパラメーター ...................................59
4.3.1. Encrypted Extensions .............................60
4.3.2. Certificate Request ..............................60
4.4. 認証メッセージ .........................................61
4.4.1. トランスクリプトハッシュ .......................63
4.4.2. Certificate ......................................64
4.4.3. Certificate Verify ...............................69
4.4.4. Finished .........................................71
4.5. End of Early Data .......................................72
Rescorla Standards Track [Page 3]
RFC 8446 TLS 2018年8月
4.6. ハンドシェイク後メッセージ .............................73
4.6.1. New Session Ticket Message .......................73
4.6.2. ハンドシェイク後認証 ............................75
4.6.3. 鍵および初期化ベクトルの更新 ...................76
5. レコードプロトコル ..........................................77
5.1. レコード層 ..............................................78
5.2. レコードペイロード保護 .................................80
5.3. レコードごとのノンス ...................................82
5.4. レコードパディング .....................................83
5.5. 鍵使用の制限 ...........................................84
6. アラートプロトコル .........................................85
6.1. 終了アラート ...........................................87
6.2. エラーアラート .........................................88
7. 暗号計算 ...................................................90
7.1. 鍵スケジュール .........................................91
7.2. トラフィックシークレットの更新 .........................94
7.3. トラフィック鍵の計算 ...................................95
7.4. (EC)DHE共有シークレット計算 ...........................95
7.4.1. 有限体Diffie-Hellman .............................95
7.4.2. 楕円曲線Diffie-Hellman ...........................96
7.5. Exporters ...............................................97
8. 0-RTTとリプレイ対策 ........................................98
8.1. 単回使用チケット .......................................99
8.2. Client Helloの記録 ......................................99
8.3. 新鮮性チェック .........................................101
9. 適合要件 ...................................................102
9.1. 実装必須の暗号スイート .................................102
9.2. 実装必須の拡張 .........................................103
9.3. プロトコル不変条件 .....................................104
10. セキュリティ考慮事項 .....................................106
11. IANA考慮事項 ..............................................106
12. 参考文献 ..................................................109
12.1. 規範的参考文献 .......................................109
12.2. 参考情報 .............................................112
Appendix A. 状態機械 ..........................................120
A.1. クライアント ............................................120
A.2. サーバー ................................................121
Appendix B. プロトコルデータ構造および定数値 .................122
B.1. レコード層 ..............................................122
B.2. アラートメッセージ .....................................123
B.3. ハンドシェイクプロトコル ...............................124
B.3.1. 鍵交換メッセージ ...................................125
B.3.2. サーバーパラメーターメッセージ .....................131
B.3.3. 認証メッセージ .....................................132
B.3.4. チケット確立 .......................................132
B.3.5. 鍵の更新 ...........................................133
B.4. 暗号スイート ...........................................133
Rescorla Standards Track [Page 4]
RFC 8446 TLS 2018年8月
Appendix C. 実装上の注意 .......................................134
C.1. 乱数生成とシード .......................................134
C.2. 証明書および認証 .......................................135
C.3. 実装上の落とし穴 .......................................135
C.4. クライアント追跡の防止 .................................137
C.5. 未認証動作 .............................................137
Appendix D. 後方互換性 .........................................138
D.1. 古いサーバーとのネゴシエーション .......................139
D.2. 古いクライアントとのネゴシエーション ...................139
D.3. 0-RTT後方互換性 ........................................140
D.4. ミドルボックス互換モード ...............................140
D.5. 後方互換性に関するセキュリティ制限 .....................141
Appendix E. セキュリティ特性の概要 ...........................142
E.1. ハンドシェイク .........................................142
E.1.1. 鍵導出およびHKDF ...................................145
E.1.2. クライアント認証 ...................................146
E.1.3. 0-RTT ...............................................146
E.1.4. Exporterの独立性 ...................................146
E.1.5. 侵害後セキュリティ .................................146
E.1.6. 外部参照 ...........................................147
E.2. レコード層 .............................................147
E.2.1. 外部参照 ...........................................148
E.3. トラフィック解析 .......................................148
E.4. サイドチャネル攻撃 .....................................149
E.5. 0-RTTに対するリプレイ攻撃 ..............................150
E.5.1. リプレイおよびExporters ............................151
E.6. PSKアイデンティティの露出 ..............................152
E.7. PSKの共有 ..............................................152
E.8. 静的RSAへの攻撃 ........................................152
貢献者 .........................................................153
著者の連絡先 ...................................................160
Rescorla Standards Track [Page 5]
RFC 8446 TLS 2018年8月
1. はじめに
TLSの第一の目的は、通信する2つのピア間に安全なチャネルを提供する
ことです。下位のトランスポートに求められる唯一の要件は、信頼性が
あり、順序どおりのデータストリームであることです。具体的には、
安全なチャネルは次の特性を提供する必要があります。
- 認証: チャネルのサーバー側は常に認証されます。クライアント側の
認証は任意です。認証は、非対称暗号（例: RSA
[RSA]、Elliptic Curve Digital Signature Algorithm (ECDSA)
[ECDSA]、またはEdwards-Curve Digital Signature Algorithm (EdDSA)
[RFC8032]）または対称な事前共有鍵 (PSK) を介して行えます。
- 機密性: 確立後にチャネル上で送信されるデータは、エンドポイント
にのみ可視です。TLSは送信するデータの長さを隠しませんが、
エンドポイントは長さを曖昧にし、トラフィック解析手法に対する
保護を改善するためにTLSレコードをパディングできます。
- 完全性: 確立後にチャネル上で送信されるデータは、攻撃者が検出
されずに変更することはできません。
これらの特性は、[RFC3552]で説明されているように、ネットワークを
完全に制御する攻撃者に直面しても成立する必要があります。関連する
セキュリティ特性のより完全な記述については、Appendix Eを参照して
ください。
TLSは2つの主要コンポーネントで構成されます。
- 通信当事者を認証し、暗号モードおよびパラメーターを交渉し、
共有鍵材料を確立するハンドシェイクプロトコル（Section 4）。
ハンドシェイクプロトコルは改ざんに耐えるように設計されています。
能動的攻撃者が、接続が攻撃下になかった場合とは異なる
パラメーターをピアに交渉させることはできないべきです。
- ハンドシェイクプロトコルによって確立されたパラメーターを用いて、
通信ピア間のトラフィックを保護するレコードプロトコル
（Section 5）。レコードプロトコルはトラフィックを一連の
レコードに分割し、それぞれがトラフィック鍵を使用して独立に
保護されます。
Rescorla Standards Track [Page 6]
RFC 8446 TLS 2018年8月
TLSはアプリケーションプロトコルから独立しています。上位レベルの
プロトコルは透過的にTLSの上に重ねることができます。ただし、TLS
標準は、プロトコルがTLSでどのようにセキュリティを追加するかを
規定しません。TLSハンドシェイクを開始する方法、および交換される
認証証明書を解釈する方法は、TLS上で動作するプロトコルの設計者
および実装者の判断に委ねられます。
本文書はTLSバージョン1.3を定義します。TLS 1.3は以前のバージョンと
直接互換ではありませんが、TLSのすべてのバージョンはバージョン
付け機構を組み込んでおり、クライアントとサーバーは双方のピアが
サポートする共通バージョンを相互運用可能に交渉できます。
本文書は、バージョン1.2 [RFC5246]を含むTLSの以前の
バージョンを置き換え、廃止します。また、[RFC5077]で定義された
TLSチケット機構を廃止し、Section 2.2で定義される機構で置き換え
ます。TLS 1.3は鍵の導出方法を変更するため、Section 7.5で説明
されるように[RFC5705]を更新します。また、Online Certificate
Status Protocol (OCSP)メッセージの搬送方法も変更するため、
Section 4.4.2.1で説明されるように[RFC6066]を更新し、
[RFC6961]を廃止します。
1.1. 表記規則および用語
本文書におけるキーワード「MUST」、「MUST NOT」、「REQUIRED」、
「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、
「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すように
すべて大文字で現れる場合に限り、BCP 14 [RFC2119] [RFC8174]で
説明されているとおりに解釈されます。
次の用語が使用されます。
client: TLS接続を開始するエンドポイント。
connection: 2つのエンドポイント間のトランスポート層接続。
endpoint: 接続のクライアントまたはサーバーのいずれか。
handshake: TLS内での後続の相互作用のパラメーターを確立する、
クライアントとサーバー間の初期ネゴシエーション。
peer: エンドポイント。特定のエンドポイントについて論じる場合、
「peer」は議論の主対象ではないエンドポイントを指します。
Rescorla Standards Track [Page 7]
RFC 8446 TLS 2018年8月
receiver: レコードを受信するエンドポイント。
sender: レコードを送信するエンドポイント。
server: TLS接続を開始しなかったエンドポイント。
1.2. TLS 1.2からの主な差分
以下は、TLS 1.2とTLS 1.3の主な機能差分の一覧です。網羅を意図
したものではなく、小さな差分は多数あります。
- サポートされる対称暗号アルゴリズムの一覧から、レガシーと
見なされるすべてのアルゴリズムが取り除かれました。残っている
ものはすべてAuthenticated Encryption with Associated Data
(AEAD)アルゴリズムです。暗号スイートの概念は、認証および
鍵交換機構を、レコード保護アルゴリズム（秘密鍵長を含む）と、
鍵導出関数およびハンドシェイクメッセージ認証コード (MAC) の
両方で使用されるハッシュから分離するように変更されました。
- ゼロラウンドトリップ時間 (0-RTT) モードが追加され、一部の
アプリケーションデータについて接続確立時の1ラウンドトリップ
を節約します。ただし、特定のセキュリティ特性を犠牲にします。
- 静的RSAおよびDiffie-Hellman暗号スイートは削除されました。
現在、すべての公開鍵ベースの鍵交換機構はforward secrecyを
提供します。
- ServerHello以後のすべてのハンドシェイクメッセージは暗号化
されるようになりました。新たに導入されたEncryptedExtensions
メッセージにより、以前はServerHello内で平文送信されていた
さまざまな拡張も、機密性保護を受けられるようになりました。
- 鍵導出関数が再設計されました。新しい設計は、改善された鍵分離
特性により、暗号研究者による解析を容易にします。HMAC-based
Extract-and-Expand Key Derivation Function (HKDF) が基盤
プリミティブとして使用されます。
- ハンドシェイク状態機械は大幅に再構成され、より一貫したものに
なり、ChangeCipherSpecなどの不要なメッセージ（ミドルボックス
互換性のために必要な場合を除く）が削除されました。
- 楕円曲線アルゴリズムは基本仕様に含まれるようになり、EdDSAなど
の新しい署名アルゴリズムも含まれます。TLS 1.3では、各曲線の
単一の点形式を採用するため、点形式ネゴシエーションが削除され
ました。
Rescorla Standards Track [Page 8]
RFC 8446 TLS 2018年8月
- その他の暗号上の改善も行われました。これには、RSAパディングを
RSA Probabilistic Signature Scheme (RSASSA-PSS) の使用へ変更
したこと、および圧縮、Digital Signature Algorithm (DSA)、
カスタムEphemeral Diffie-Hellman (DHE) グループの削除が含まれ
ます。
- TLS 1.2のバージョンネゴシエーション機構は、拡張内のバージョン
一覧を優先する形で非推奨になりました。これにより、バージョン
ネゴシエーションを誤って実装した既存サーバーとの互換性が向上
します。
- 以前のTLSバージョンにおける、サーバー側状態あり/なしの
セッション再開およびPSKベースの暗号スイートは、単一の新しい
PSK交換で置き換えられました。
- 必要に応じて、参照はRFCの更新版を指すように更新されています
（例: RFC 3280ではなくRFC 5280）。
1.3. TLS 1.2に影響する更新
本文書は、TLS 1.3もサポートする実装に限らず、TLS 1.2の実装に
任意で影響するいくつかの変更を定義します。
- Section 4.1.3で、バージョンダウングレード保護機構が説明されます。
- Section 4.2.3で、RSASSA-PSS署名方式が定義されます。
- "supported_versions" ClientHello拡張を使用して、
ClientHelloのlegacy_versionフィールドより優先して、使用する
TLSのバージョンを交渉できます。
- "signature_algorithms_cert"拡張により、クライアントはX.509
証明書で検証可能な署名アルゴリズムを示すことができます。
さらに、本文書は以前のTLSバージョンに対する一部の適合要件を
明確化します。Section 9.3を参照してください。
Rescorla Standards Track [Page 9]
RFC 8446 TLS 2018年8月
2. プロトコル概要
安全なチャネルで使用される暗号パラメーターは、TLSハンドシェイク
プロトコルによって生成されます。TLSのこのサブプロトコルは、
クライアントとサーバーが最初に通信するときに使用されます。
ハンドシェイクプロトコルにより、ピアはプロトコルバージョンを
交渉し、暗号アルゴリズムを選択し、任意で互いを認証し、共有
秘密鍵材料を確立できます。ハンドシェイクが完了すると、ピアは
確立された鍵を使用してアプリケーション層トラフィックを保護します。
ハンドシェイクの失敗またはその他のプロトコルエラーは、接続の終了
を引き起こし、任意でその前にアラートメッセージ（Section 6）が
送信されます。
TLSは3つの基本的な鍵交換モードをサポートします。
- (EC)DHE（有限体または楕円曲線上のDiffie-Hellman）
- PSKのみ
- PSKと(EC)DHE
Rescorla Standards Track [Page 10]
RFC 8446 TLS 2018年8月
下のFigure 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]
+ 直前に示されたメッセージで送信される注目すべき
拡張を示します。
* 常に送信されるとは限らない、任意または状況依存の
メッセージ/拡張を示します。
{} [sender]_handshake_traffic_secretから
導出された鍵を使用して保護されるメッセージを示します。
[] [sender]_application_traffic_secret_Nから
導出された鍵を使用して保護されるメッセージを示します。
Figure 1: 完全TLSハンドシェイクのメッセージフロー
ハンドシェイクは、（上の図で示される）3つのフェーズを持つものと
考えられます。
- 鍵交換: 共有鍵材料を確立し、暗号パラメーターを選択します。
このフェーズ以後のすべては暗号化されます。
- サーバーパラメーター: その他のハンドシェイクパラメーター
（クライアントが認証されるかどうか、アプリケーション層
プロトコルのサポートなど）を確立します。
Rescorla Standards Track [Page 11]
RFC 8446 TLS 2018年8月
- 認証: サーバー（および任意でクライアント）を認証し、鍵確認と
ハンドシェイク完全性を提供します。
鍵交換フェーズでは、クライアントはClientHello（Section 4.1.2）
メッセージを送信します。これはランダムノンス
(ClientHello.random)、提示するプロトコルバージョン、対称暗号/
HKDFハッシュの組の一覧、Diffie-Hellman鍵共有の集合（"key_share"
（Section 4.2.8）拡張内）、事前共有鍵ラベルの集合
（"pre_shared_key"（Section 4.2.11）拡張内）、またはその両方、
そして場合により追加の拡張を含みます。ミドルボックス互換性のため、
追加のフィールドおよび/またはメッセージが存在することもあります。
サーバーはClientHelloを処理し、接続に適した暗号パラメーターを
決定します。次に、自身のServerHello（Section 4.1.3）で応答し、
交渉された接続パラメーターを示します。ClientHelloとServerHelloの
組み合わせが共有鍵を決定します。(EC)DHE鍵確立が使用される場合、
ServerHelloはサーバーの一時Diffie-Hellman共有値を含む
"key_share"拡張を含みます。サーバーの共有値は、クライアントの
共有値のいずれかと同じグループでなければなりません (MUST)。
PSK鍵確立が使用される場合、ServerHelloはクライアントが提示した
PSKのどれが選択されたかを示す"pre_shared_key"拡張を含みます。
実装は(EC)DHEとPSKを併用でき、その場合は両方の拡張が供給される
ことに注意してください。
次に、サーバーはServer Parametersを確立するために2つのメッセージ
を送信します。
EncryptedExtensions: 暗号パラメーターを決定するために必要では
ないClientHello拡張への応答。ただし、個々の証明書に固有のもの
は除きます。[Section 4.3.1]
CertificateRequest: 証明書ベースのクライアント認証が望まれる場合、
その証明書に対して望まれるパラメーター。クライアント認証が
望まれない場合、このメッセージは省略されます。
[Section 4.3.2]
Rescorla Standards Track [Page 12]
RFC 8446 TLS 2018年8月
最後に、クライアントとサーバーはAuthenticationメッセージを交換
します。TLSは、証明書ベースの認証が必要なときは毎回同じ
メッセージ集合を使用します。（PSKベースの認証は鍵交換の副作用
として発生します。）具体的には次のとおりです。
Certificate: エンドポイントの証明書および証明書ごとの拡張。
サーバーが証明書で認証しない場合はサーバーによって省略され、
サーバーがCertificateRequestを送信しなかった場合（したがって、
クライアントが証明書で認証すべきでないことを示す場合）は
クライアントによって省略されます。raw public keys [RFC7250]
またはcached information拡張 [RFC7924] が使用されている場合、
このメッセージは証明書ではなく、サーバーの長期鍵に対応する
何らかの別の値を含むことに注意してください。[Section 4.4.2]
CertificateVerify: Certificateメッセージ内の公開鍵に対応する秘密鍵を
用いた、ハンドシェイク全体に対する署名。エンドポイントが証明書
を介して認証しない場合、このメッセージは省略されます。
[Section 4.4.3]
Finished: ハンドシェイク全体に対するMAC (Message Authentication
Code)。このメッセージは鍵確認を提供し、エンドポイントの
アイデンティティを交換された鍵に結び付け、PSKモードでは
ハンドシェイクも認証します。[Section 4.4.4]
サーバーのメッセージを受信すると、クライアントは自身の
Authenticationメッセージ、すなわちCertificateおよび
CertificateVerify（要求された場合）、そしてFinishedで応答します。
この時点でハンドシェイクは完了し、クライアントとサーバーは
レコード層が認証付き暗号化で保護されたアプリケーション層データを
交換するために必要な鍵材料を導出します。Section 2.3で規定される
場合を除き、Application DataはFinishedメッセージの送信前に送信
してはなりません (MUST NOT)。サーバーはクライアントのAuthentication
メッセージを受信する前にApplication Dataを送信してもよいものの、
その時点で送信されるデータは当然ながら未認証ピアに送信されている
ことに注意してください。
Rescorla Standards Track [Page 13]
RFC 8446 TLS 2018年8月
2.1. 不正なDHE共有値
クライアントが十分な"key_share"拡張を提供していない場合（例:
サーバーに受け入れられない、またはサポートされていないDHEまたは
ECDHEグループのみを含む場合）、サーバーはHelloRetryRequestで
不一致を訂正し、クライアントはFigure 2に示すように適切な
"key_share"拡張でハンドシェイクを再開始する必要があります。共通の
暗号パラメーターを交渉できない場合、サーバーは適切なアラートで
ハンドシェイクを中止しなければなりません (MUST)。
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: パラメーター不一致を伴う完全ハンドシェイクの
メッセージフロー
注: ハンドシェイクトランスクリプトには、最初のClientHello/
HelloRetryRequest交換が組み込まれます。新しいClientHelloで
リセットされるわけではありません。
TLSでは、以下のセクションで説明されるように、基本ハンドシェイク
のいくつかの最適化されたバリアントも許可されます。
Rescorla Standards Track [Page 14]
RFC 8446 TLS 2018年8月
2.2. 再開および事前共有鍵 (PSK)
TLS PSKは帯域外で確立できますが、PSKは以前の接続で確立され、
その後新しい接続を確立するために使用されることもあります
（「セッション再開」またはPSKによる「再開」）。ハンドシェイクが
完了すると、サーバーはクライアントに、最初のハンドシェイクから
導出された一意の鍵に対応するPSKアイデンティティを送信できます
（Section 4.6.1を参照）。クライアントは、その後の
ハンドシェイクでそのPSKアイデンティティを使用して、関連するPSKの
使用を交渉できます。サーバーがPSKを受け入れる場合、新しい接続の
セキュリティコンテキストは元の接続に暗号学的に結び付けられ、
最初のハンドシェイクから導出された鍵が、完全なハンドシェイクの
代わりに暗号状態をブートストラップするために使用されます。
TLS 1.2以前では、この機能は「セッションID」および「セッション
チケット」[RFC5077]によって提供されていました。TLS 1.3では両方の
機構が廃止されます。
PSKは、共有鍵と組み合わせてforward secrecyを提供するために
(EC)DHE鍵交換とともに使用できます。または、アプリケーション
データのforward secrecyを失うという代償を払って、単独で使用
することもできます。
Rescorla Standards Track [Page 15]
RFC 8446 TLS 2018年8月
Figure 3は、最初のハンドシェイクでPSKを確立し、2回目の
ハンドシェイクでそれを使用する一対のハンドシェイクを示します。
Client Server
Initial Handshake:
ClientHello
+ key_share -------->
ServerHello
+ key_share
{EncryptedExtensions}
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}
{Finished}
<-------- [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished} -------->
<-------- [NewSessionTicket]
[Application Data] <-------> [Application Data]
Subsequent Handshake:
ClientHello
+ key_share*
+ pre_shared_key -------->
ServerHello
+ pre_shared_key
+ key_share*
{EncryptedExtensions}
{Finished}
<-------- [Application Data*]
{Finished} -------->
[Application Data] <-------> [Application Data]
Figure 3: 再開およびPSKのメッセージフロー
サーバーはPSKを介して認証しているため、Certificateまたは
CertificateVerifyメッセージを送信しません。クライアントがPSKに
よる再開を提示するときは、必要に応じてサーバーが再開を拒否して
完全ハンドシェイクにフォールバックできるように、"key_share"拡張も
サーバーに供給すべきです (SHOULD)。サーバーは"pre_shared_key"拡張
で応答してPSK鍵確立の使用を交渉し、（ここに示すように）
"key_share"拡張で応答して(EC)DHE鍵確立を行い、forward secrecyを
提供できます。
Rescorla Standards Track [Page 16]
RFC 8446 TLS 2018年8月
PSKが帯域外でプロビジョニングされる場合、PSKアイデンティティおよび
PSKとともに使用するKDFハッシュアルゴリズムもプロビジョニング
されなければなりません (MUST)。
注: 帯域外でプロビジョニングされた事前共有シークレットを使用する
場合、[RFC4086]で論じられているように、鍵生成時に十分な
エントロピーを使用することが重要な考慮事項です。パスワードや
その他の低エントロピー源から共有シークレットを導出することは
安全ではありません。低エントロピーのシークレット、または
パスワードは、PSKバインダーに基づく辞書攻撃の対象となります。
規定されたPSK認証は、Diffie-Hellman鍵確立と併用される場合で
あっても、強力なパスワードベースの認証付き鍵交換ではありません。
具体的には、ハンドシェイクを観測できる攻撃者がパスワード/
事前共有鍵に対して総当たり攻撃を行うことを防ぎません。
2.3. 0-RTTデータ
クライアントとサーバーがPSK（外部から取得したもの、または以前の
ハンドシェイクを介して取得したもの）を共有している場合、TLS 1.3は
クライアントが最初のフライトでデータを送信すること（「early data」）
を許可します。クライアントはPSKを使用してサーバーを認証し、
early dataを暗号化します。
Figure 4に示すように、0-RTTデータは最初のフライトで1-RTT
ハンドシェイクに追加されるだけです。ハンドシェイクの残りは、
PSK再開を伴う1-RTTハンドシェイクと同じメッセージを使用します。
Rescorla Standards Track [Page 17]
RFC 8446 TLS 2018年8月
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]
+ 直前に示されたメッセージで送信される注目すべき
拡張を示します。
* 常に送信されるとは限らない、任意または状況依存の
メッセージ/拡張を示します。
() client_early_traffic_secretから導出された鍵を
使用して保護されるメッセージを示します。
{} [sender]_handshake_traffic_secretから
導出された鍵を使用して保護されるメッセージを示します。
[] [sender]_application_traffic_secret_Nから
導出された鍵を使用して保護されるメッセージを示します。
Figure 4: 0-RTTハンドシェイクのメッセージフロー
Rescorla Standards Track [Page 18]
RFC 8446 TLS 2018年8月
重要な注記: 0-RTTデータのセキュリティ特性は、他の種類のTLSデータ
よりも弱いものです。具体的には次のとおりです。
1. このデータは、提示されたPSKを用いて導出された鍵のみによって
暗号化されるため、forward secretではありません。
2. 接続間での非リプレイの保証はありません。通常のTLS 1.3
1-RTTデータに対するリプレイ保護はサーバーのRandom値によって
提供されますが、0-RTTデータはServerHelloに依存しないため、
保証は弱くなります。これは、データがTLSクライアント認証に
よって、またはアプリケーションプロトコル内で認証される場合に
特に関連します。同じ警告はearly_exporter_master_secretの
任意の使用にも適用されます。
0-RTTデータは接続内で複製できず（すなわち、サーバーは同じ接続に
ついて同じデータを2回処理しません）、攻撃者が0-RTTデータを1-RTT
データであるかのように見せることもできません（異なる鍵で保護
されているため）。Appendix E.5には潜在的な攻撃の説明が含まれ、
Section 8では、サーバーがリプレイの影響を制限するために使用
できる機構を説明します。
3. プレゼンテーション言語
本文書は、外部表現におけるデータの形式を扱います。以下の非常に
基本的で、やや緩く定義されたプレゼンテーション構文が使用されます。
3.1. 基本ブロックサイズ
すべてのデータ項目の表現は明示的に規定されます。基本データ
ブロックサイズは1バイト（すなわち8ビット）です。複数バイトの
データ項目は、左から右、上から下の順にバイトを連結したものです。
バイトストリームから、複数バイト項目（以下の例では数値）は、
（C表記を用いて）次のように形成されます。
value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
... | byte[n-1];
複数バイト値に対するこのバイト順序は、一般的なネットワーク
バイトオーダー、すなわちビッグエンディアン形式です。
Rescorla Standards Track [Page 19]
RFC 8446 TLS 2018年8月
3.2. その他
コメントは"/*"で始まり、"*/"で終わります。
任意の構成要素は、それらを"[[ ]]"（二重角括弧）で囲むことにより
示されます。
解釈されないデータを含む1バイトエンティティは、opaque型です。
既存の型Tに対する型エイリアスT'は次のように定義されます。
T T';
3.3. 数値
基本的な数値データ型は符号なしバイト (uint8) です。より大きい
すべての数値データ型は、Section 3.1で説明されたように連結された
固定長のバイト列から構成され、同じく符号なしです。次の数値型が
事前定義されています。
uint8 uint16[2];
uint8 uint24[3];
uint8 uint32[4];
uint8 uint64[8];
ここおよび本仕様の他の箇所におけるすべての値は、ネットワーク
バイト（ビッグエンディアン）順で送信されます。16進バイト
01 02 03 04で表されるuint32は、10進値16909060に相当します。
3.4. ベクトル
ベクトル（1次元配列）は、同種データ要素のストリームです。
ベクトルのサイズは文書化時に規定される場合もあれば、実行時まで
未規定のままにされる場合もあります。いずれの場合も、長さは
ベクトル内の要素数ではなく、バイト数を宣言します。型Tの固定長
ベクトルである新しい型T'を規定する構文は次のとおりです。
T T'[n];
ここで、T'はデータストリーム内でnバイトを占め、nはTのサイズの
倍数です。ベクトルの長さはエンコードされたストリームには含まれ
ません。
Rescorla Standards Track [Page 20]
RFC 8446 TLS 2018年8月
次の例では、Datumはプロトコルが解釈しない連続する3バイトとして
定義され、一方Dataは連続する3つのDatumであり、合計9バイトを
消費します。
opaque Datum[3]; /* 解釈されない3バイト */
Datum Data[9]; /* 連続する3つの3バイトベクトル */
可変長ベクトルは、<floor..ceiling>表記を用いて、有効な長さの
範囲を両端を含めて指定することで定義されます。これらがエンコード
されるとき、実際の長さがベクトルの内容に先行してバイトストリーム
内に置かれます。長さは、ベクトルの指定された最大（ceiling）長を
保持するために必要なだけのバイト数を消費する数値形式になります。
実際の長さフィールドがゼロである可変長ベクトルは、空ベクトルと
呼ばれます。
T T'<floor..ceiling>;
次の例では、"mandatory"はopaque型の300から400バイトを含まなければ
ならないベクトルです。空にはできません。実際の長さフィールドは
2バイト、すなわちuint16を消費し、これは値400を表すのに十分です
（Section 3.3を参照）。同様に、"longer"は最大800バイトのデータ、
または400個のuint16要素を表すことができ、空でもかまいません。
そのエンコードには、2バイトの実際の長さフィールドがベクトルに
前置されて含まれます。エンコードされたベクトルの長さは、単一の
要素の長さの正確な倍数でなければなりません（例: uint16の
17バイトベクトルは不正です）。
opaque mandatory<300..400>;
/* 長さフィールドは2バイト、空にはできない */
uint16 longer<0..800>;
/* 0から400個の16ビット符号なし整数 */
3.5. 列挙型
"enum"または"enumerated"と呼ばれる追加の疎なデータ型が利用可能
です。各定義は異なる型です。同じ型の列挙型同士のみが代入または
比較できます。次の例で示すように、列挙型のすべての要素には値を
割り当てなければなりません。列挙型の要素には順序がないため、
任意の一意の値を任意の順序で割り当てることができます。
enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
プロトコルの将来の拡張または追加により、新しい値が定義される
可能性があります。フィールドの定義が別途述べない限り、実装は
未知の値を解析し、無視できる必要があります。
Rescorla Standards Track [Page 21]
RFC 8446 TLS 2018年8月
列挙型は、最大の定義済み序数値が必要とするだけの空間を
バイトストリーム内で占めます。次の定義では、Color型のフィールドを
搬送するために1バイトが使用されます。
enum { red(3), blue(5), white(7) } Color;
不要な要素を定義せずに幅の定義を強制するため、関連付けられた
タグを持たない値を任意で指定できます。
次の例では、Tasteはデータストリーム内で2バイトを消費しますが、
現在のプロトコルバージョンでは1、2、または4の値のみを取り得ます。
enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
列挙の要素名は定義された型の内部でスコープ化されます。最初の
例では、列挙の2番目の要素への完全修飾参照はColor.blueになります。
代入先が十分に指定されている場合、このような修飾は不要です。
Color color = Color.blue; /* 過剰指定だが正当 */
Color color = blue; /* 正しい、型は暗黙 */
列挙型に割り当てられる名前は一意である必要はありません。数値は、
同じ名前が適用される範囲を記述できます。値は、その範囲における
最小値および最大値を両端を含めて含み、2つのピリオド文字で区切られ
ます。これは主に、空間の領域を予約するために有用です。
enum { sad(0), meh(1..254), happy(255) } Mood;
3.6. 構成型
利便性のため、プリミティブ型から構造型を構成できます。各仕様は、
新しい一意の型を宣言します。定義に使用される構文はCの構文に
よく似ています。
struct {
T1 f1;
T2 f2;
...
Tn fn;
} T;
標準のベクトル構文を使用して、固定長および可変長のベクトル
フィールドが許可されます。バリアント例（Section 3.8）の構造体
V1およびV2はこれを示しています。
Rescorla Standards Track [Page 22]
RFC 8446 TLS 2018年8月
構造体内のフィールドは、列挙型で利用できるものとよく似た構文で、
型名を用いて修飾できます。たとえば、T.f2は前の宣言の2番目の
フィールドを指します。
3.7. 定数
フィールドおよび変数には、次のように"="を使用して固定値を代入
できます。
struct {
T1 f1 = 8; /* T.f1は常に8でなければならない */
T2 f2;
} T;
3.8. バリアント
定義された構造体は、環境内で利用可能な何らかの知識に基づく
バリアントを持つことができます。セレクターは、その構造体が定義
する可能なバリアントを定義する列挙型でなければなりません。
以下のselectの各アームは、そのバリアントのフィールドの型と任意の
フィールドラベルを指定します。バリアントが実行時にどのような
機構で選択されるかは、プレゼンテーション言語では規定されません。
struct {
T1 f1;
T2 f2;
....
Tn fn;
select (E) {
case e1: Te1 [[fe1]];
case e2: Te2 [[fe2]];
....
case en: Ten [[fen]];
};
} Tv;
Rescorla Standards Track [Page 23]
RFC 8446 TLS 2018年8月
例:
enum { apple(0), orange(1) } VariantTag;
struct {
uint16 number;
opaque string<0..10>; /* 可変長 */
} V1;
struct {
uint32 number;
opaque string[10]; /* 固定長 */
} V2;
struct {
VariantTag type;
select (VariantRecord.type) {
case apple: V1;
case orange: V2;
};
} VariantRecord;
4. ハンドシェイクプロトコル
ハンドシェイクプロトコルは、接続のセキュリティパラメーターを
交渉するために使用されます。ハンドシェイクメッセージはTLS
レコード層に供給され、そこで現在のアクティブな接続状態により
規定されるとおり、1つ以上のTLSPlaintextまたはTLSCiphertext構造に
カプセル化され、処理および送信されます。
Rescorla Standards Track [Page 24]
RFC 8446 TLS 2018年8月
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; /* ハンドシェイク種別 */
uint24 length; /* メッセージ内の残りバイト数 */
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;
プロトコルメッセージは、Section 4.4.1で定義され、Section 2の図に
示される順序で送信されなければなりません (MUST)。予期しない順序で
ハンドシェイクメッセージを受信したピアは、"unexpected_message"
アラートでハンドシェイクを中止しなければなりません (MUST)。
新しいハンドシェイクメッセージ種別は、Section 11で説明される
ようにIANAによって割り当てられます。
4.1. 鍵交換メッセージ
鍵交換メッセージは、クライアントおよびサーバーのセキュリティ能力
を決定し、共有シークレットを確立するために使用されます。これには、
ハンドシェイクの残りとデータを保護するために使用される
トラフィック鍵が含まれます。
Rescorla Standards Track [Page 25]
RFC 8446 TLS 2018年8月
4.1.1. 暗号ネゴシエーション
TLSでは、暗号ネゴシエーションは、クライアントがClientHelloで次の
4つの選択肢集合を提示することによって進行します。
- クライアントがサポートするAEADアルゴリズム/HKDFハッシュの組を
示す暗号スイートの一覧。
- クライアントがサポートする(EC)DHEグループを示す
"supported_groups"（Section 4.2.7）拡張、およびこれらのグループの
一部または全部に対する(EC)DHE共有値を含む"key_share"
（Section 4.2.8）拡張。
- クライアントが受け入れ可能な署名アルゴリズムを示す
"signature_algorithms"（Section 4.2.3）拡張。
証明書固有の署名アルゴリズムを示すために、
"signature_algorithms_cert"拡張（Section 4.2.3）も追加できます。
- クライアントが知っている対称鍵アイデンティティの一覧を含む
"pre_shared_key"（Section 4.2.11）拡張、およびPSKとともに使用
できる鍵交換モードを示す"psk_key_exchange_modes"
（Section 4.2.9）拡張。
サーバーがPSKを選択しない場合、これらの最初の3つの選択肢は完全に
直交しています。サーバーは暗号スイート、鍵確立のための(EC)DHE
グループおよび鍵共有値、ならびにクライアントに自身を認証するため
の署名アルゴリズム/証明書ペアを独立に選択します。受信した
"supported_groups"とサーバーがサポートするグループの間に重なりが
ない場合、サーバーは"handshake_failure"または
"insufficient_security"アラートでハンドシェイクを中止しなければ
なりません (MUST)。
サーバーがPSKを選択する場合、クライアントの
"psk_key_exchange_modes"拡張で示された集合から鍵確立モードも選択
しなければなりません (MUST)（現時点では、PSK単独または(EC)DHEとの
併用）。PSKが(EC)DHEなしで使用できる場合、前段落で論じた非PSKの
場合と異なり、"supported_groups"パラメーターの不一致は致命的で
ある必要がないことに注意してください。
サーバーが(EC)DHEグループを選択し、クライアントが初期ClientHelloで
互換性のある"key_share"拡張を提示しなかった場合、サーバーは
HelloRetryRequest（Section 4.1.4）メッセージで応答しなければなり
ません (MUST)。
Rescorla Standards Track [Page 26]
RFC 8446 TLS 2018年8月
サーバーがパラメーターを正常に選択し、HelloRetryRequestを必要と
しない場合、選択されたパラメーターをServerHelloで次のように示します。
- PSKが使用されている場合、サーバーは選択された鍵を示す
"pre_shared_key"拡張を送信します。
- (EC)DHEが使用されている場合、サーバーは"key_share"拡張も提供
します。PSKが使用されていない場合、(EC)DHEおよび証明書ベース
の認証が常に使用されます。
- 証明書を介して認証する場合、サーバーはCertificate
（Section 4.4.2）およびCertificateVerify（Section 4.4.3）
メッセージを送信します。本文書で定義されるTLS 1.3では、PSK
または証明書のいずれかが常に使用されますが、両方は使用され
ません。将来の文書で、それらを併用する方法が定義される可能性
があります。
サーバーがサポートされるパラメーター集合を交渉できない場合
（すなわち、クライアントとサーバーのパラメーター間に重なりがない
場合）、"handshake_failure"または"insufficient_security"の致命的
アラートでハンドシェイクを中止しなければなりません (MUST)
（Section 6を参照）。
4.1.2. Client Hello
クライアントが最初にサーバーに接続するとき、最初のTLSメッセージ
としてClientHelloを送信することが要求されます (REQUIRED)。
サーバーがClientHelloに対してHelloRetryRequestで応答した場合にも、
クライアントはClientHelloを送信します。その場合、クライアントは
次の場合を除き、変更なしで同じClientHelloを送信しなければなりま
せん (MUST)。
- HelloRetryRequestで"key_share"拡張が供給された場合、共有値の一覧
を、示されたグループからの単一のKeyShareEntryを含む一覧に
置き換えます。
- "early_data"拡張（Section 4.2.10）が存在していた場合、それを削除
します。HelloRetryRequest後のearly dataは許可されません。
- HelloRetryRequestで提供された場合、"cookie"拡張を含めます。
Rescorla Standards Track [Page 27]
RFC 8446 TLS 2018年8月
- 存在する場合は"pre_shared_key"拡張を更新し、
"obfuscated_ticket_age"およびbinder値を再計算し、（任意で）
サーバーが示した暗号スイートと互換性のないPSKを削除します。
- "padding"拡張 [RFC7685] を任意で追加、削除、または長さを変更
します。
- 将来定義され、HelloRetryRequest内に存在する拡張によって許可
される可能性のあるその他の変更。
TLS 1.3は再ネゴシエーションを禁止するため、サーバーがTLS 1.3を
交渉済みで、その他の時点でClientHelloを受信した場合、
"unexpected_message"アラートで接続を終了しなければなりません
(MUST)。
サーバーが以前のTLSバージョンでTLS接続を確立し、再ネゴシエーション
中にTLS 1.3 ClientHelloを受信した場合、以前のプロトコルバージョン
を保持しなければなりません (MUST)。特に、TLS 1.3を交渉しては
なりません (MUST NOT)。
このメッセージの構造:
uint16 ProtocolVersion;
opaque Random[32];
uint8 CipherSuite[2]; /* Cryptographic suite selector */
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id<0..32>;
CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>;
} ClientHello;
Rescorla Standards Track [Page 28]
RFC 8446 TLS 2018年8月
legacy_version: 以前のTLSバージョンでは、このフィールドはバージョン
ネゴシエーションに使用され、クライアントがサポートする最高の
バージョン番号を表していました。経験上、多くのサーバーは
バージョンネゴシエーションを適切に実装しておらず、「version
intolerance」を引き起こしていました。これは、サーバーがサポート
するより高いバージョン番号を持つ、他の点では受け入れ可能な
ClientHelloを拒否するものです。TLS 1.3では、クライアントは
"supported_versions"拡張（Section 4.2.1）でバージョンの希望を
示し、legacy_versionフィールドはTLS 1.2のバージョン番号である
0x0303に設定されなければなりません (MUST)。TLS 1.3 ClientHelloは、
legacy_versionが0x0303であり、supported_versions拡張が存在し、
その中で0x0304が示された最高バージョンであるものとして識別
されます。（後方互換性の詳細についてはAppendix Dを参照。）
random: 安全な乱数生成器によって生成される32バイト。追加情報に
ついてはAppendix Cを参照してください。
legacy_session_id: TLS 1.3より前のTLSバージョンは「セッション再開」
機能をサポートしていましたが、このバージョンでは事前共有鍵と
統合されています（Section 2.2を参照）。pre-TLS 1.3サーバーに
よって設定されたキャッシュ済みセッションIDを持つクライアントは、
このフィールドをその値に設定すべきです (SHOULD)。互換モード
（Appendix D.4を参照）では、このフィールドは空であってはならず
(MUST)、pre-TLS 1.3セッションを提示しないクライアントは新しい
32バイト値を生成しなければなりません (MUST)。この値はランダムで
ある必要はありませんが、実装が特定の値に固定化すること（いわゆる
ossification）を避けるため、予測困難であるべきです (SHOULD)。
それ以外の場合は、ゼロ長ベクトル（すなわち、値がゼロの単一
バイト長フィールド）として設定されなければなりません (MUST)。
cipher_suites: クライアントがサポートする対称暗号の選択肢の一覧。
具体的には、レコード保護アルゴリズム（秘密鍵長を含む）および
HKDFで使用されるハッシュで、クライアントの優先順の降順です。
値はAppendix B.4で定義されています。一覧にサーバーが認識しない、
サポートしない、または使用を望まない暗号スイートが含まれる場合、
サーバーはそれらの暗号スイートを無視し、残りを通常どおり処理
しなければなりません (MUST)。クライアントがPSK鍵確立を試みて
いる場合、PSKに関連付けられたHashを示す暗号スイートを少なくとも
1つ広告すべきです (SHOULD)。
Rescorla Standards Track [Page 29]
RFC 8446 TLS 2018年8月
legacy_compression_methods: 1.3より前のTLSバージョンは圧縮を
サポートしており、サポートされる圧縮方式の一覧がこのフィールド
で送信されていました。すべてのTLS 1.3 ClientHelloについて、
このベクトルは正確に1バイトを含み、以前のTLSバージョンにおける
"null"圧縮方式に対応するゼロに設定されなければなりません
(MUST)。TLS 1.3 ClientHelloがこのフィールドに他の値を含んで
受信された場合、サーバーは"illegal_parameter"アラートで
ハンドシェイクを中止しなければなりません (MUST)。TLS 1.3
サーバーは、他の圧縮方式を含むTLS 1.2以前のClientHelloを受信
する可能性があり、（そのような以前のバージョンを交渉する場合）
適切な以前のTLSバージョンの手順に従わなければならないことに
注意してください (MUST)。
extensions: クライアントは、extensionsフィールドにデータを送信
することで、サーバーに拡張機能を要求します。実際の"Extension"
形式はSection 4.2で定義されます。TLS 1.3では、以前のTLS
バージョンとのClientHello互換性を維持するため、機能が拡張へ
移動されており、特定の拡張の使用が必須です。サーバーは認識
しない拡張を無視しなければなりません (MUST)。
TLSのすべてのバージョンでは、extensionsフィールドが任意で
compression_methodsフィールドに続くことを許可しています。
TLS 1.3 ClientHelloメッセージは常に拡張を含みます（少なくとも
"supported_versions"。そうでなければTLS 1.2 ClientHelloメッセージ
として解釈されます）。ただし、TLS 1.3サーバーは以前のTLSバージョン
からの、extensionsフィールドを持たないClientHelloメッセージを受信
する可能性があります。拡張の存在は、ClientHelloの末尾で
compression_methodsフィールドに続くバイトがあるかどうかを判定する
ことで検出できます。この任意データ検出方法は、可変長フィールドを
持つ通常のTLSの方法とは異なりますが、拡張が定義される前のTLSとの
互換性のために使用されることに注意してください。TLS 1.3サーバーは
最初にこのチェックを行い、"supported_versions"拡張が存在する場合
にのみTLS 1.3の交渉を試みる必要があります。1.3より前のTLS
バージョンを交渉する場合、サーバーはメッセージが
legacy_compression_methodsの後にデータを含まないか、または後続
データを持たない有効なextensionsブロックを含むかを確認しなければ
なりません (MUST)。そうでない場合、"decode_error"アラートで
ハンドシェイクを中止しなければなりません (MUST)。
クライアントが拡張を使用して追加機能を要求し、この機能がサーバー
によって提供されない場合、クライアントはハンドシェイクを中止して
もよいです (MAY)。
ClientHelloメッセージを送信した後、クライアントはServerHelloまたは
HelloRetryRequestメッセージを待ちます。early dataが使用される場合、
クライアントは次のハンドシェイクメッセージを待っている間にearly
Application Data（Section 2.3）を送信してもよいです。
Rescorla Standards Track [Page 30]
RFC 8446 TLS 2018年8月
4.1.3. Server Hello
サーバーは、ClientHelloに基づいて受け入れ可能なハンドシェイク
パラメーター集合を交渉できる場合、ハンドシェイクを進めるために
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;
legacy_version: 以前のTLSバージョンでは、このフィールドはバージョン
ネゴシエーションに使用され、接続で選択されたバージョン番号を
表していました。残念ながら、一部のミドルボックスは新しい値を
提示されると失敗します。TLS 1.3では、TLSサーバーは
"supported_versions"拡張（Section 4.2.1）を使用して自身の
バージョンを示し、legacy_versionフィールドはTLS 1.2のバージョン
番号である0x0303に設定されなければなりません (MUST)。
（後方互換性の詳細についてはAppendix Dを参照。）
random: 安全な乱数生成器によって生成される32バイト。追加情報に
ついてはAppendix Cを参照してください。TLS 1.2またはTLS 1.1を
交渉する場合、最後の8バイトは後述のとおり上書きされなければ
なりません (MUST) が、残りのバイトはランダムでなければなりません
(MUST)。この構造はサーバーによって生成され、ClientHello.random
とは独立に生成されなければなりません (MUST)。
legacy_session_id_echo: クライアントのlegacy_session_idフィールドの
内容。クライアントの値が、サーバーが再開しないことを選択した
キャッシュ済みpre-TLS 1.3セッションに対応していたとしても、
このフィールドはエコーされることに注意してください。
ClientHelloで送信したものと一致しないlegacy_session_id_echo
フィールドを受信したクライアントは、"illegal_parameter"アラート
でハンドシェイクを中止しなければなりません (MUST)。
cipher_suite: ClientHello.cipher_suites内の一覧からサーバーが選択した
単一の暗号スイート。提示していない暗号スイートを受信した
クライアントは、"illegal_parameter"アラートでハンドシェイクを
中止しなければなりません (MUST)。
legacy_compression_method: 値0でなければならない単一バイト (MUST)。
Rescorla Standards Track [Page 31]
RFC 8446 TLS 2018年8月
extensions: 拡張の一覧。ServerHelloは、暗号コンテキストを確立し、
プロトコルバージョンを交渉するために必要な拡張のみを含まなけれ
ばなりません (MUST)。すべてのTLS 1.3 ServerHelloメッセージは
"supported_versions"拡張を含まなければなりません (MUST)。現在の
ServerHelloメッセージは、さらに"pre_shared_key"拡張または
"key_share"拡張、またはその両方（PSKと(EC)DHE鍵確立を併用する
場合）を含みます。その他の拡張（Section 4.2を参照）は、
EncryptedExtensionsメッセージで別途送信されます。
ミドルボックスとの後方互換性のため（Appendix D.4を参照）、
HelloRetryRequestメッセージはServerHelloと同じ構造を使用しますが、
Randomは"HelloRetryRequest"のSHA-256の特別な値に設定されます。
CF 21 AD 74 E5 9A 61 11 BE 1D 8C 02 1E 65 B8 91
C2 A2 11 16 7A BB 8C 5E 07 9E 09 E2 C8 A8 33 9C
typeがserver_helloであるメッセージを受信した場合、実装は最初に
Random値を調べ、それがこの値に一致する場合はSection 4.1.4で説明
されるように処理しなければなりません (MUST)。
TLS 1.3には、サーバーのrandom値に埋め込まれたダウングレード保護
機構があります。TLS 1.3サーバーがClientHelloへの応答として
TLS 1.2以下を交渉する場合、ServerHello内のRandom値の最後の
8バイトを特別に設定しなければなりません (MUST)。
TLS 1.2を交渉する場合、TLS 1.3サーバーはRandom値の最後の8バイトを
次のバイト列に設定しなければなりません (MUST)。
44 4F 57 4E 47 52 44 01
TLS 1.1以下を交渉する場合、TLS 1.3サーバーは、またTLS 1.2サーバーは
すべきものとして (SHOULD)、ServerHello.Random値の最後の8バイトを
次のバイト列に設定しなければなりません (MUST)。
44 4F 57 4E 47 52 44 00
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は両方の
random値に対する署名を含むため、一時暗号が使用されている限り、
Rescorla Standards Track [Page 32]
RFC 8446 TLS 2018年8月
能動的攻撃者が検出されずにrandom値を変更することはできません。
これは静的RSAが使用されている場合にはダウングレード保護を提供
しません。
注: これは[RFC5246]からの変更であるため、実際には多くのTLS 1.2
クライアントおよびサーバーは上記のとおりには動作しません。
TLS 1.2以前で再ネゴシエーションを行っているレガシーTLSクライアント
が、再ネゴシエーション中にTLS 1.3 ServerHelloを受信した場合、
"protocol_version"アラートでハンドシェイクを中止しなければなり
ません (MUST)。TLS 1.3が交渉されている場合、再ネゴシエーションは
可能ではないことに注意してください。
4.1.4. Hello Retry Request
サーバーは、受け入れ可能なパラメーター集合を見つけられるものの、
ClientHelloがハンドシェイクを進めるために十分な情報を含まない場合、
ClientHelloメッセージへの応答としてこのメッセージを送信します。
Section 4.1.3で論じたように、HelloRetryRequestはServerHello
メッセージと同じ形式を持ち、legacy_version、
legacy_session_id_echo、cipher_suite、および
legacy_compression_methodフィールドは同じ意味を持ちます。ただし、
利便性のため、本文書では"HelloRetryRequest"をあたかも独立した
メッセージであるかのように扱います。
サーバーの拡張は"supported_versions"を含まなければなりません
(MUST)。さらに、クライアントが正しいClientHelloペアを生成するため
に必要な最小限の拡張集合を含むべきです (SHOULD)。ServerHelloと
同様に、HelloRetryRequestは、任意の"cookie"（Section 4.2.2を参照）
拡張を除き、クライアントのClientHelloで最初に提示されていない
拡張を含んではなりません (MUST NOT)。
HelloRetryRequestを受信すると、クライアントはSection 4.1.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"アラートでハンドシェイクを
中止しなければなりません (MUST)。
Rescorla Standards Track [Page 33]
RFC 8446 TLS 2018年8月
それ以外の場合、クライアントはHelloRetryRequest内のすべての拡張を
処理し、2回目の更新されたClientHelloを送信しなければなりません
(MUST)。本仕様で定義されるHelloRetryRequest拡張は次のとおりです。
- supported_versions（Section 4.2.1を参照）
- cookie（Section 4.2.2を参照）
- key_share（Section 4.2.8を参照）
提示していない暗号スイートを受信したクライアントは、ハンドシェイク
を中止しなければなりません (MUST)。サーバーは、適合する更新済み
ClientHelloを受信するときに同じ暗号スイートを交渉することを保証
しなければなりません (MUST)（サーバーがネゴシエーションの最初の
手順として暗号スイートを選択する場合、これは自動的に起こります）。
ServerHelloを受信すると、クライアントはServerHelloで供給された
暗号スイートがHelloRetryRequest内のものと同じであることを確認し、
そうでない場合は"illegal_parameter"アラートでハンドシェイクを中止
しなければなりません (MUST)。
加えて、更新されたClientHelloにおいて、クライアントは選択された
暗号スイートのハッシュ以外に関連付けられた事前共有鍵を提示すべき
ではありません (SHOULD NOT)。これにより、クライアントは2回目の
ClientHelloで複数のハッシュに対する部分ハッシュトランスクリプトを
計算せずに済みます。
HelloRetryRequestの"supported_versions"拡張内のselected_versionの値は
ServerHelloで保持されなければならず (MUST)、その値が変更された
場合、クライアントは"illegal_parameter"アラートでハンドシェイクを
中止しなければなりません (MUST)。
Rescorla Standards Track [Page 34]
RFC 8446 TLS 2018年8月
4.2. 拡張
多くのTLSメッセージは、タグ長値でエンコードされた拡張構造を含みます。
struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
enum {
server_name(0), /* RFC 6066 */
max_fragment_length(1), /* RFC 6066 */
status_request(5), /* RFC 6066 */
supported_groups(10), /* RFC 8422, 7919 */
signature_algorithms(13), /* RFC 8446 */
use_srtp(14), /* RFC 5764 */
heartbeat(15), /* RFC 6520 */
application_layer_protocol_negotiation(16), /* RFC 7301 */
signed_certificate_timestamp(18), /* RFC 6962 */
client_certificate_type(19), /* RFC 7250 */
server_certificate_type(20), /* RFC 7250 */
padding(21), /* RFC 7685 */
pre_shared_key(41), /* RFC 8446 */
early_data(42), /* RFC 8446 */
supported_versions(43), /* RFC 8446 */
cookie(44), /* RFC 8446 */
psk_key_exchange_modes(45), /* RFC 8446 */
certificate_authorities(47), /* RFC 8446 */
oid_filters(48), /* RFC 8446 */
post_handshake_auth(49), /* RFC 8446 */
signature_algorithms_cert(50), /* RFC 8446 */
key_share(51), /* RFC 8446 */
(65535)
} ExtensionType;
Rescorla Standards Track [Page 35]
RFC 8446 TLS 2018年8月
ここで:
- "extension_type"は特定の拡張種別を識別します。
- "extension_data"は特定の拡張種別に固有の情報を含みます。
拡張種別の一覧は、Section 11で説明されるようにIANAによって管理
されます。
拡張は一般に要求/応答方式で構造化されますが、一部の拡張は対応する
応答を持たない単なる表示です。クライアントはClientHelloメッセージ
で拡張要求を送信し、サーバーはServerHello、EncryptedExtensions、
HelloRetryRequest、およびCertificateメッセージで拡張応答を送信
します。サーバーはCertificateRequestメッセージで拡張要求を送信し、
クライアントはCertificateメッセージで応答してもよいです (MAY)。
サーバーはNewSessionTicketで未要求の拡張を送信してもよいですが
(MAY)、クライアントはこれらに直接応答しません。
実装は、HelloRetryRequest内の"cookie"拡張を除き、リモート
エンドポイントが対応する拡張要求を送信していない場合、拡張応答を
送信してはなりません (MUST NOT)。そのような拡張を受信した場合、
エンドポイントは"unsupported_extension"アラートでハンドシェイクを
中止しなければなりません (MUST)。
下の表は、特定の拡張が現れ得るメッセージを示します。次の表記を
使用します: CH (ClientHello)、SH (ServerHello)、EE
(EncryptedExtensions)、CT (Certificate)、CR (CertificateRequest)、
NST (NewSessionTicket)、およびHRR (HelloRetryRequest)。実装が認識
する拡張を、その拡張が現れるものとして規定されていないメッセージ
内で受信した場合、"illegal_parameter"アラートでハンドシェイクを
中止しなければなりません (MUST)。
Rescorla Standards Track [Page 36]
RFC 8446 TLS 2018年8月
+--------------------------------------------------+-------------+
| Extension | TLS 1.3 |
+--------------------------------------------------+-------------+
| server_name [RFC6066] | CH, EE |
| | |
| max_fragment_length [RFC6066] | CH, EE |
| | |
| status_request [RFC6066] | CH, CR, CT |
| | |
| supported_groups [RFC7919] | CH, EE |
| | |
| signature_algorithms (RFC 8446) | CH, CR |
| | |
| use_srtp [RFC5764] | CH, EE |
| | |
| heartbeat [RFC6520] | CH, EE |
| | |
| application_layer_protocol_negotiation [RFC7301] | CH, EE |
| | |
| signed_certificate_timestamp [RFC6962] | CH, CR, CT |
| | |
| client_certificate_type [RFC7250] | CH, EE |
| | |
| server_certificate_type [RFC7250] | CH, EE |
| | |
| padding [RFC7685] | CH |
| | |
| key_share (RFC 8446) | CH, SH, HRR |
| | |
| pre_shared_key (RFC 8446) | CH, SH |
| | |
| psk_key_exchange_modes (RFC 8446) | CH |
| | |
| early_data (RFC 8446) | CH, EE, NST |
| | |
| cookie (RFC 8446) | CH, HRR |
| | |
| supported_versions (RFC 8446) | CH, SH, HRR |
| | |
| certificate_authorities (RFC 8446) | CH, CR |
| | |
| oid_filters (RFC 8446) | CR |
| | |
| post_handshake_auth (RFC 8446) | CH |
| | |
| signature_algorithms_cert (RFC 8446) | CH, CR |
+--------------------------------------------------+-------------+
Rescorla Standards Track [Page 37]
RFC 8446 TLS 2018年8月
異なる種別の複数の拡張が存在する場合、拡張は任意の順序で現れても
よいですが (MAY)、ClientHello内で最後の拡張でなければならない
(MUST) "pre_shared_key"（Section 4.2.11）は例外です
（ただし、ServerHello extensionsブロック内ではどこに現れても
かまいません）。特定のextensionブロックには、同じ種別の拡張が
複数存在してはなりません (MUST NOT)。
TLS 1.3では、TLS 1.2とは異なり、resumption-PSKモードであっても、
拡張はハンドシェイクごとに交渉されます。ただし、0-RTTパラメーター
は以前のハンドシェイクで交渉されたものです。不一致があると0-RTTの
拒否が必要になる可能性があります（Section 4.2.10を参照）。
このプロトコルでは、新しい機能と既存機能の間に微妙な（または
微妙ではない）相互作用が生じる可能性があり、それによって全体的な
セキュリティが大きく低下する可能性があります。新しい拡張を設計する
ときは、次の考慮事項を考慮に入れるべきです。
- サーバーが拡張に同意しない場合の中には、エラー条件
（例: ハンドシェイクを継続できない）であるものもあれば、
特定の機能のサポートを単に拒否するものであるものもあります。
一般に、前者にはエラーアラートを使用し、後者にはサーバーの
拡張応答内のフィールドを使用すべきです。
- 拡張は、可能な限り、ハンドシェイクメッセージの操作によって
特定の機能の使用（または不使用）を強制する攻撃を防ぐように
設計されるべきです。この原則は、その機能がセキュリティ問題を
引き起こすと考えられるかどうかにかかわらず従うべきです。
多くの場合、拡張フィールドがFinishedメッセージハッシュへの
入力に含まれるという事実で十分ですが、その拡張がハンドシェイク
フェーズで送信されるメッセージの意味を変更する場合は、極めて
慎重な注意が必要です。設計者および実装者は、ハンドシェイクが
認証されるまで、能動的攻撃者がメッセージを変更し、拡張を挿入、
削除、または置換できるという事実を認識しておくべきです。
Rescorla Standards Track [Page 38]
RFC 8446 TLS 2018年8月
4.2.1. Supported Versions
struct {
select (Handshake.msg_type) {
case client_hello:
ProtocolVersion versions<2..254>;
case server_hello: /* and HelloRetryRequest */
ProtocolVersion selected_version;
};
} SupportedVersions;
"supported_versions"拡張は、クライアントがサポートするTLSの
バージョンを示すため、およびサーバーが使用しているバージョンを
示すために使用されます。この拡張は、サポートされるバージョンの
一覧を優先順で含み、最も優先されるバージョンが最初に置かれます。
本仕様の実装は、交渉する準備があるTLSのすべてのバージョンを含む
ClientHelloでこの拡張を送信しなければなりません (MUST)
（本仕様では、最低限0x0304を意味しますが、以前のTLSバージョンの
交渉を許可する場合、それらも存在しなければなりません (MUST)）。
この拡張が存在しない場合、本仕様に準拠し、TLS 1.2もサポートする
サーバーは、ClientHello.legacy_versionが0x0304以降であっても、
[RFC5246]で規定されるとおりTLS 1.2以前を交渉しなければなり
ません (MUST)。サーバーは、legacy_versionが0x0304以降の
ClientHelloを受信した場合、ハンドシェイクを中止してもよいです
(MAY)。
この拡張がClientHelloに存在する場合、サーバーはバージョン
ネゴシエーションにClientHello.legacy_version値を使用してはならず
(MUST NOT)、クライアントの希望を決定するために"supported_versions"
拡張のみを使用しなければなりません (MUST)。サーバーはその拡張に
存在するTLSのバージョンのみを選択しなければならず (MUST)、その
拡張内に存在する未知のバージョンはすべて無視しなければなりません
(MUST)。この機構により、一方が疎な範囲をサポートする場合、TLS 1.2
より前のバージョンを交渉することが可能になる点に注意してください。
以前のTLSバージョンをサポートすることを選択するTLS 1.3の実装は、
TLS 1.2をサポートすべきです (SHOULD)。サーバーは、この拡張を含む
もののバージョン一覧に0x0304を含まないClientHelloを受信する準備が
できていなければなりません (MUST)。
TLS 1.3より前のTLSバージョンを交渉するサーバーは、
ServerHello.versionを設定しなければならず (MUST)、
"supported_versions"拡張を送信してはなりません (MUST NOT)。
TLS 1.3を交渉するサーバーは、選択されたバージョン値 (0x0304) を
含む"supported_versions"拡張を送信して応答しなければなりません
(MUST)。ServerHello.legacy_versionフィールドを0x0303 (TLS 1.2) に
設定しなければなりません (MUST)。クライアントは、ServerHelloの
残りを処理する前にこの拡張を確認しなければなりません (MUST)
（ただし、拡張を読み取るためにはServerHelloを解析する必要があり
Rescorla Standards Track [Page 39]
RFC 8446 TLS 2018年8月
ます）。この拡張が存在する場合、クライアントは
ServerHello.legacy_version値を無視しなければならず (MUST)、
選択されたバージョンを決定するために"supported_versions"拡張のみを
使用しなければなりません (MUST)。ServerHello内の
"supported_versions"拡張がクライアントによって提示されていない
バージョンを含む場合、またはTLS 1.3より前のバージョンを含む場合、
クライアントは"illegal_parameter"アラートでハンドシェイクを中止
しなければなりません (MUST)。
4.2.2. Cookie
struct {
opaque cookie<1..2^16-1>;
} Cookie;
Cookieは主に2つの目的を果たします。
- サーバーが、クライアントに見かけ上のネットワークアドレスへの
到達可能性を証明させることを可能にします（したがってDoS保護の
一手段を提供します）。これは主に、非接続指向トランスポートに
有用です（この例については[RFC6347]を参照）。
- サーバーが状態をクライアントにオフロードできるようにし、状態を
保存せずにHelloRetryRequestを送信できるようにします。サーバーは、
ClientHelloのハッシュをHelloRetryRequest cookie内に格納する
ことで、これを実現できます（何らかの適切な完全性保護
アルゴリズムで保護されます）。
HelloRetryRequestを送信するとき、サーバーはクライアントに"cookie"
拡張を提供してもよいです (MAY)（これは、送信できる拡張は
ClientHelloに現れるものだけであるという通常の規則の例外です）。
新しいClientHelloを送信するとき、クライアントはHelloRetryRequestで
受信した拡張の内容を、新しいClientHello内の"cookie"拡張へコピー
しなければなりません (MUST)。クライアントは、後続接続の初期
ClientHelloでcookieを使用してはなりません (MUST NOT)。
サーバーがステートレスに動作している場合、最初と2回目のClientHello
の間で、保護されていないchange_cipher_spec型のレコードを受信する
可能性があります（Section 5を参照）。サーバーは状態を保存して
いないため、これは最初に受信したメッセージであるかのように見え
ます。ステートレスに動作するサーバーは、これらのレコードを無視
しなければなりません (MUST)。
Rescorla Standards Track [Page 40]
RFC 8446 TLS 2018年8月
4.2.3. Signature Algorithms
TLS 1.3は、デジタル署名で使用できる署名アルゴリズムを示すための
2つの拡張を提供します。"signature_algorithms_cert"拡張は証明書内の
署名に適用され、TLS 1.2で最初に登場した"signature_algorithms"拡張は
CertificateVerifyメッセージ内の署名に適用されます。証明書内にある
鍵も、それらが使用される署名アルゴリズムに適した型でなければなり
ません (MUST)。これは、以下で説明するように、RSA鍵およびPSS署名に
特有の問題です。"signature_algorithms_cert"拡張が存在しない場合、
"signature_algorithms"拡張は証明書内に現れる署名にも適用されます。
サーバーが証明書を介して自身を認証することを望むクライアントは、
"signature_algorithms"拡張を送信しなければなりません (MUST)。
サーバーが証明書を介して認証しており、クライアントが
"signature_algorithms"拡張を送信していない場合、サーバーは
"missing_extension"アラートでハンドシェイクを中止しなければなり
ません (MUST)（Section 9.2を参照）。
"signature_algorithms_cert"拡張は、証明書用とTLS自体用で異なる
アルゴリズム集合をサポートする実装が、その能力を明確に通知できる
ように追加されました。TLS 1.2実装もこの拡張を処理すべきです
(SHOULD)。両方の場合で同じポリシーを持つ実装は、
"signature_algorithms_cert"拡張を省略してもよいです (MAY)。
Rescorla Standards Track [Page 41]
RFC 8446 TLS 2018年8月
これらの拡張の"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;
注: このenumは"SignatureScheme"と名付けられています。これは、
TLS 1.2にすでに"SignatureAlgorithm"型が存在し、本型がそれを置き
換えるためです。本文全体では「署名アルゴリズム」という用語を使用
します。
Rescorla Standards Track [Page 42]
RFC 8446 TLS 2018年8月
各SignatureScheme値は、クライアントが検証する意思のある単一の
署名アルゴリズムを列挙します。値は優先度の降順で示されます。
署名アルゴリズムは、ダイジェストではなく任意長メッセージを入力と
することに注意してください。従来ダイジェストに対して動作する
アルゴリズムは、TLSではまず指定されたハッシュアルゴリズムで入力を
ハッシュし、その後通常どおり処理を進めるように定義されるべきです。
上に列挙したコードポイントグループには、次の意味があります。
RSASSA-PKCS1-v1_5 algorithms: [RFC8017]のRSASSA-PKCS1-v1_5を、
[SHS]で定義される対応するハッシュアルゴリズムとともに使用する
署名アルゴリズムを示します。これらの値は、証明書内に現れる署名
（Section 4.4.2.2を参照）のみを指し、署名付きTLSハンドシェイク
メッセージでの使用は定義されていません。ただし、TLS 1.2との後方
互換性のため、"signature_algorithms"および
"signature_algorithms_cert"内に現れてもよいです (MAY)。
ECDSA algorithms: [ECDSA]を使用し、ANSI X9.62 [ECDSA]および
FIPS 186-4 [DSS]で定義される対応する曲線、ならびに[SHS]で
定義される対応するハッシュアルゴリズムを用いる署名アルゴリズムを
示します。署名はDERエンコードされた[X690] ECDSA-Sig-Value
構造として表現されます。
RSASSA-PSS RSAE algorithms: mask generation function 1とともに
RSASSA-PSS [RFC8017]を使用する署名アルゴリズムを示します。
mask generation functionで使用されるダイジェストと署名対象の
ダイジェストは、どちらも[SHS]で定義される対応するハッシュ
アルゴリズムです。Saltの長さはダイジェストアルゴリズムの出力長に
等しくなければなりません (MUST)。公開鍵がX.509証明書で搬送される
場合、rsaEncryption OID [RFC5280]を使用しなければなりません
(MUST)。
EdDSA algorithms: [RFC8032]またはその後継で定義されるEdDSAを使用する
署名アルゴリズムを示します。これらは"PureEdDSA"アルゴリズムに
対応し、"prehash"バリアントではないことに注意してください。
RSASSA-PSS PSS algorithms: mask generation function 1とともに
RSASSA-PSS [RFC8017]を使用する署名アルゴリズムを示します。
mask generation functionで使用されるダイジェストと署名対象の
ダイジェストは、どちらも[SHS]で定義される対応するハッシュ
アルゴリズムです。Saltの長さはダイジェストアルゴリズムの長さに
等しくなければなりません (MUST)。公開鍵がX.509証明書で搬送される
場合、RSASSA-PSS OID [RFC5756]を使用しなければなりません
(MUST)。証明書署名で使用される場合、アルゴリズムパラメーターは
DERエンコードされなければなりません (MUST)。対応する公開鍵の
パラメーターが存在する場合、署名内のパラメーターは公開鍵内の
ものと同一でなければなりません (MUST)。
Rescorla Standards Track [Page 43]
RFC 8446 TLS 2018年8月
Legacy algorithms: 既知の弱点を持つアルゴリズム、具体的にはこの文脈で
(1) RSASSA-PKCS1-v1_5を用いるRSA、または(2) ECDSAとともに使用される
SHA-1を使用するため、非推奨になりつつあるアルゴリズムを示します。
これらの値は、証明書内に現れる署名（Section 4.4.2.2を参照）
のみを指し、署名付きTLSハンドシェイクメッセージでの使用は定義
されていません。ただし、TLS 1.2との後方互換性のため、
"signature_algorithms"および"signature_algorithms_cert"内に現れても
よいです (MAY)。エンドポイントはこれらのアルゴリズムを交渉すべき
ではありません (SHOULD NOT) が、後方互換性のみを目的としてそうする
ことは許可されます。これらの値を提示するクライアントは、それらを
最低優先度として列挙しなければなりません (MUST)
（SignatureSchemeList内で他のすべてのアルゴリズムの後に列挙）。
TLS 1.3サーバーは、それなしでは有効な証明書チェーンを生成できない
場合を除き、SHA-1で署名された証明書を提示してはなりません
(MUST NOT)（Section 4.4.2.2を参照）。
自己署名証明書、またはトラストアンカーである証明書の署名は、
証明パスを開始するものであるため、検証されません
（[RFC5280], Section 3.2を参照）。証明パスを開始する証明書は、
"signature_algorithms"拡張でサポートされると広告されていない
署名アルゴリズムを使用してもよいです (MAY)。
TLS 1.2ではこの拡張が異なる形で定義されていることに注意して
ください。TLS 1.2を交渉する意思のあるTLS 1.3実装は、そのバージョンを
交渉するとき、[RFC5246]の要件に従って動作しなければなりません
(MUST)。特に:
- TLS 1.2 ClientHelloはこの拡張を省略してもよいです (MAY)。
- TLS 1.2では、この拡張はハッシュ/署名ペアを含んでいました。
ペアは2オクテットでエンコードされるため、SignatureScheme値は
TLS 1.2のエンコードと整合するように割り当てられています。一部の
レガシーペアは未割り当てのままです。これらのアルゴリズムは
TLS 1.3時点で非推奨です。いかなる実装も、これらを提示または交渉
してはなりません (MUST NOT)。特に、MD5 [SLOTH]、SHA-224、
およびDSAは使用してはなりません (MUST NOT)。
- ECDSA署名方式は、TLS 1.2のECDSAハッシュ/署名ペアと整合します。
ただし、古い意味論では署名曲線が制約されていませんでした。
TLS 1.2が交渉された場合、実装は"supported_groups"拡張で広告した
任意の曲線を使用する署名を受け入れる準備ができていなければなり
ません (MUST)。
- TLS 1.3で必須であるRSASSA-PSSのサポートを広告する実装は、
TLS 1.2が交渉された場合でも、その方式を使用する署名を受け入れる
準備ができていなければなりません (MUST)。TLS 1.2では、RSASSA-PSSは
RSA暗号スイートとともに使用されます。
Rescorla Standards Track [Page 44]
RFC 8446 TLS 2018年8月
4.2.4. Certificate Authorities
"certificate_authorities"拡張は、エンドポイントがサポートし、受信側
エンドポイントが証明書選択を導くために使用すべき (SHOULD) 認証局
(CA) を示すために使用されます。
"certificate_authorities"拡張の本体は、CertificateAuthoritiesExtension
構造で構成されます。
opaque DistinguishedName<1..2^16-1>;
struct {
DistinguishedName authorities<3..2^16-1>;
} CertificateAuthoritiesExtension;
authorities: DERエンコードされた[X690]形式で表される、受け入れ可能な
認証局の識別名 [X501] の一覧。これらの識別名は、トラスト
アンカーまたは下位CAに対する望ましい識別名を指定します。
したがって、このメッセージは既知のトラストアンカーだけでなく、
望ましい認可空間を記述するためにも使用できます。
クライアントはClientHelloメッセージ内で"certificate_authorities"拡張を
送信してもよいです (MAY)。サーバーはCertificateRequestメッセージ内で
それを送信してもよいです (MAY)。
類似の目的を果たすものの、より複雑な"trusted_ca_keys"拡張
[RFC6066]は、TLS 1.3では使用されません（ただし、以前のTLSバージョンを
提示するクライアントからのClientHelloメッセージには現れる場合が
あります）。
4.2.5. OID Filters
"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;
Rescorla Standards Track [Page 45]
RFC 8446 TLS 2018年8月
filters: DERエンコードされた[X690]形式で表される、許可値と
ともに示された証明書拡張OID [RFC5280] の一覧。一部の証明書拡張
OIDは複数の値を許可します（例: Extended Key Usage）。サーバーが
空でないfilters一覧を含めている場合、応答に含まれるクライアント
証明書は、クライアントが認識する指定された拡張OIDをすべて含まな
ければなりません (MUST)。クライアントが認識する各拡張OIDについて、
指定された値はすべてクライアント証明書内に存在しなければなり
ません (MUST)（ただし、証明書が他の値も持っていてもよいです
(MAY)）。ただし、クライアントは認識しない証明書拡張OIDを無視し、
スキップしなければなりません (MUST)。クライアントが要求された
証明書拡張OIDの一部を無視し、その要求を満たさない証明書を供給した
場合、サーバーは裁量により、クライアント認証なしで接続を継続する
か、"unsupported_certificate"アラートでハンドシェイクを中止しても
よいです (MAY)。任意のOIDはfilters一覧内に複数回現れてはなりません
(MUST NOT)。
PKIX RFCは、さまざまな証明書拡張OIDおよび対応する値型を定義して
います。型によっては、一致する証明書拡張値が必ずしもビット単位で
等しいとは限りません。TLS実装は、証明書拡張OIDを使用した証明書選択を
行うためにPKIライブラリに依存することが期待されます。
本文書は、[RFC5280]で定義される2つの標準証明書拡張について、
一致規則を定義します。
- 証明書内のKey Usage拡張は、要求内で主張されるすべてのkey usage
ビットがKey Usage証明書拡張でも主張されている場合、その要求に
一致します。
- 証明書内のExtended Key Usage拡張は、要求内に存在するすべての
key purpose OIDがExtended Key Usage証明書拡張にも見つかる場合、
その要求に一致します。特別なanyExtendedKeyUsage OIDは要求内で
使用してはなりません (MUST NOT)。
別個の仕様が、他の証明書拡張に対する一致規則を定義してもよいです。
Rescorla Standards Track [Page 46]
RFC 8446 TLS 2018年8月
4.2.6. Post-Handshake Client Authentication
"post_handshake_auth"拡張は、クライアントがハンドシェイク後認証
（Section 4.6.2）を実行する意思があることを示すために使用されます。
サーバーは、この拡張を提示しないクライアントに対して、ハンドシェイク
後のCertificateRequestを送信してはなりません (MUST NOT)。サーバーは
この拡張を送信してはなりません (MUST NOT)。
struct {} PostHandshakeAuth;
"post_handshake_auth"拡張の"extension_data"フィールドは長さ0です。
4.2.7. Supported Groups
クライアントによって送信される場合、"supported_groups"拡張は、鍵交換
のためにクライアントがサポートする名前付きグループを、最も優先
されるものから最も優先されないものの順に示します。
注: TLS 1.3より前のTLSバージョンでは、この拡張は"elliptic_curves"と
名付けられ、楕円曲線グループのみを含んでいました。[RFC8422]および
[RFC7919]を参照してください。この拡張はECDSA曲線を交渉するためにも
使用されていました。署名アルゴリズムは現在、独立に交渉されます
（Section 4.2.3を参照）。
この拡張の"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;
Rescorla Standards Track [Page 47]
RFC 8446 TLS 2018年8月
Elliptic Curve Groups (ECDHE): FIPS 186-4 [DSS]または[RFC7748]の
いずれかで定義される、対応する名前付き曲線のサポートを示します。
0xFE00から0xFEFFまでの値はPrivate Use [RFC8126]のために予約
されています。
Finite Field Groups (DHE): [RFC7919]で定義される、対応する有限体
グループのサポートを示します。0x01FCから0x01FFまでの値はPrivate
Useのために予約されています。
named_group_list内の項目は、送信者の優先順（最も優先される選択肢が
先頭）に従って並べられます。
TLS 1.3以降、サーバーは"supported_groups"拡張をクライアントに送信する
ことが許可されています。クライアントはハンドシェイクが正常に完了
する前に"supported_groups"内で見つかる情報に基づいて動作してはなり
ません (MUST NOT) が、正常に完了したハンドシェイクから得た情報を、
後続接続で"key_share"拡張に使用するグループを変更するために使用しても
よいです (MAY)。サーバーが"key_share"拡張内のグループより優先する
グループを持つが、それでもClientHelloを受け入れる意思がある場合、
クライアントの自身の優先順位に関する見方を更新するために
"supported_groups"を送信すべきです (SHOULD)。この拡張は、現在
クライアントによってサポートされているかどうかにかかわらず、
サーバーがサポートするすべてのグループを含むべきです (SHOULD)。
4.2.8. Key Share
"key_share"拡張は、エンドポイントの暗号パラメーターを含みます。
クライアントは、追加のラウンドトリップを犠牲にして、サーバーに
グループ選択を要求するため、空のclient_sharesベクトルを送信しても
よいです (MAY)（Section 4.1.4を参照）。
struct {
NamedGroup group;
opaque key_exchange<1..2^16-1>;
} KeyShareEntry;
group: 交換される鍵の名前付きグループ。
key_exchange: 鍵交換情報。このフィールドの内容は、指定されたグループ
およびその対応する定義によって決定されます。Finite Field
Diffie-Hellman [DH76]パラメーターはSection 4.2.8.1で説明され、
Elliptic Curve Diffie-HellmanパラメーターはSection 4.2.8.2で
説明されます。
Rescorla Standards Track [Page 48]
RFC 8446 TLS 2018年8月
ClientHelloメッセージでは、この拡張の"extension_data"フィールドは
"KeyShareClientHello"値を含みます。
struct {
KeyShareEntry client_shares<0..2^16-1>;
} KeyShareClientHello;
client_shares: クライアントの優先度の降順で提示されるKeyShareEntry値の
一覧。
クライアントがHelloRetryRequestを要求している場合、このベクトルは空で
あってもよいです (MAY)。各KeyShareEntry値は"supported_groups"拡張で
提示されたグループに対応しなければならず (MUST)、同じ順序で現れなけれ
ばなりません (MUST)。ただし、値は"supported_groups"拡張の非連続な
部分集合であってもよく (MAY)、最も優先されるグループを省略しても
よいです (MAY)。このような状況は、最も優先されるグループが新しく、
それらに対する鍵共有を事前生成することが効率的になるほど十分多くの
場所でサポートされる可能性が低い場合に生じ得ます。
クライアントは、提示しているサポートグループ数と同じ数だけ
KeyShareEntry値を提示できます。それぞれは単一の鍵交換パラメーター
集合を表します。たとえば、クライアントは複数の楕円曲線または複数の
FFDHEグループに対する共有値を提示できます。各KeyShareEntryの
key_exchange値は独立に生成されなければなりません (MUST)。
クライアントは同じグループに対して複数のKeyShareEntry値を提示しては
なりません (MUST NOT)。クライアントは自身の"supported_groups"拡張に
列挙されていないグループに対するKeyShareEntry値を提示してはなりま
せん (MUST NOT)。サーバーはこれらの規則違反を確認してもよく (MAY)、
違反がある場合は"illegal_parameter"アラートでハンドシェイクを中止
してもよいです。
HelloRetryRequestメッセージでは、この拡張の"extension_data"フィールドは
KeyShareHelloRetryRequest値を含みます。
struct {
NamedGroup selected_group;
} KeyShareHelloRetryRequest;
selected_group: サーバーが交渉しようとしており、再試行される
ClientHello/KeyShareを要求している、相互にサポートされるグループ。
HelloRetryRequest内でこの拡張を受信すると、クライアントは
(1) selected_groupフィールドが元のClientHello内の"supported_groups"
拡張で提供されたグループに対応すること、および(2) selected_group
フィールドが元のClientHello内の"key_share"拡張で提供されたグループに
対応しないことを検証しなければなりません (MUST)。これらの確認の
いずれかが失敗した場合、クライアントは"illegal_parameter"アラートで
ハンドシェイクを中止しなければなりません (MUST)。そうでない場合、
新しいClientHelloを送信するとき、クライアントは元の"key_share"拡張を、
Rescorla Standards Track [Page 49]
RFC 8446 TLS 2018年8月
トリガーとなったHelloRetryRequestのselected_groupフィールドで示された
グループに対する新しいKeyShareEntryのみを含むものに置き換えなければ
なりません (MUST)。
ServerHelloメッセージでは、この拡張の"extension_data"フィールドは
KeyShareServerHello値を含みます。
struct {
KeyShareEntry server_share;
} KeyShareServerHello;
server_share: クライアントの共有値のいずれかと同じグループに属する
単一のKeyShareEntry値。
(EC)DHE鍵確立を使用する場合、サーバーはServerHello内で正確に1つの
KeyShareEntryを提示します。この値は、交渉された鍵交換のために
サーバーが選択した、クライアントによって提示されたKeyShareEntry値と
同じグループに属さなければなりません (MUST)。サーバーは、クライアント
の"supported_groups"拡張に示されていない任意のグループに対して
KeyShareEntryを送信してはならず (MUST NOT)、"psk_ke"
PskKeyExchangeModeを使用する場合にKeyShareEntryを送信してはなりません
(MUST NOT)。(EC)DHE鍵確立を使用しており、"key_share"拡張を含む
HelloRetryRequestがクライアントによって受信された場合、クライアントは
ServerHello内で選択されたNamedGroupがHelloRetryRequest内のものと同じで
あることを検証しなければなりません (MUST)。この確認が失敗した場合、
クライアントは"illegal_parameter"アラートでハンドシェイクを中止しなけ
ればなりません (MUST)。
4.2.8.1. Diffie-Hellman Parameters
クライアントおよびサーバーの両方に対するDiffie-Hellman [DH76]
パラメーターは、KeyShare構造内のKeyShareEntryのopaque key_exchange
フィールドにエンコードされます。opaque値は、指定されたグループ
（グループ定義については[RFC7919]を参照）のDiffie-Hellman公開値
(Y = g^X mod p) を含み、ビッグエンディアン整数としてエンコードされ、
pのバイト単位サイズまで左側にゼロでパディングされます。
注: 特定のDiffie-Hellmanグループについて、パディングにより、すべての
公開鍵が同じ長さになります。
ピアは、1 < Y < p-1であることを確認することにより、互いの公開鍵Yを
検証しなければなりません (MUST)。この確認により、リモートピアが
適切に振る舞っており、ローカルシステムを小さな部分群へ強制して
いないことが保証されます。
Rescorla Standards Track [Page 50]
RFC 8446 TLS 2018年8月
4.2.8.2. ECDHE Parameters
クライアントおよびサーバーの両方に対するECDHEパラメーターは、
KeyShare構造内のKeyShareEntryのopaque key_exchangeフィールドに
エンコードされます。
secp256r1、secp384r1、およびsecp521r1について、内容は次のstructの
シリアライズ値です。
struct {
uint8 legacy_form = 4;
opaque X[coordinate_length];
opaque Y[coordinate_length];
} UncompressedPointRepresentation;
XおよびYはそれぞれ、ネットワークバイトオーダーでのx値およびy値の
バイナリ表現です。内部の長さマーカーはないため、各数値表現は曲線
パラメーターによって示されるだけのオクテットを占めます。P-256では、
XおよびYのそれぞれが32オクテットを使用し、必要に応じて左側にゼロで
パディングされることを意味します。P-384ではそれぞれ48オクテットです。
P-521ではそれぞれ66オクテットです。
曲線secp256r1、secp384r1、およびsecp521r1について、ピアは、点が楕円
曲線上の有効な点であることを確認することにより、互いの公開値Qを
検証しなければなりません (MUST)。適切な検証手順は、[ECDSA]の
Section 4.3.7、および代替として[KEYAGREEMENT]のSection 5.6.2.3で
定義されています。この処理は3つの手順から構成されます: (1) Qが無限
遠点 (O) でないことを検証する、(2) Q = (x, y)について整数xおよびyが
ともに正しい区間内にあることを検証する、(3) (x, y)が楕円曲線方程式の
正しい解であることを保証する。これらの曲線について、実装者は正しい
部分群への所属を検証する必要はありません。
X25519およびX448について、公開値の内容は[RFC7748]で定義される
対応する関数のバイト文字列入力および出力です。X25519では32バイト、
X448では56バイトです。
注: 1.3より前のTLSバージョンは点形式ネゴシエーションを許可して
いました。TLS 1.3は、各曲線について単一の点形式を採用するため、
この機能を削除します。
4.2.9. Pre-Shared Key Exchange Modes
PSKを使用するため、クライアントは"psk_key_exchange_modes"拡張も送信
しなければなりません (MUST)。この拡張の意味論は、クライアントが
これらのモードでのみPSKの使用をサポートするというものであり、
このClientHelloで提示されるPSK、およびサーバーがNewSessionTicketを
介して供給する可能性があるPSKの両方の使用を制限します。
Rescorla Standards Track [Page 51]
RFC 8446 TLS 2018年8月
クライアントは"pre_shared_key"拡張を提示する場合、
"psk_key_exchange_modes"拡張を提供しなければなりません (MUST)。
クライアントが"psk_key_exchange_modes"拡張なしで"pre_shared_key"を
提示した場合、サーバーはハンドシェイクを中止しなければなりません
(MUST)。サーバーは、クライアントによって列挙されていない鍵交換
モードを選択してはなりません (MUST NOT)。この拡張は、PSK再開で使用
されるモードも制限します。サーバーは広告されたモードと互換性のない
チケットを含むNewSessionTicketを送信すべきではありません (SHOULD NOT)。
ただし、サーバーがそうした場合、その影響は単にクライアントの再開の
試行が失敗するだけです。
サーバーは"psk_key_exchange_modes"拡張を送信してはなりません
(MUST NOT)。
enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode;
struct {
PskKeyExchangeMode ke_modes<1..255>;
} PskKeyExchangeModes;
psk_ke: PSKのみの鍵確立。このモードでは、サーバーは"key_share"値を
供給してはなりません (MUST NOT)。
psk_dhe_ke: (EC)DHE鍵確立を伴うPSK。このモードでは、クライアントと
サーバーはSection 4.2.8で説明されるように"key_share"値を供給
しなければなりません (MUST)。
将来割り当てられる任意の値は、送信されるプロトコルメッセージが
サーバーによって選択されたモードを曖昧さなく識別することを保証しな
ければなりません。現時点では、これはServerHello内の"key_share"の存在
によって示されます。
4.2.10. Early Data Indication
PSKが使用され、そのPSKについてearly dataが許可される場合、クライアント
は最初のメッセージフライトでApplication Dataを送信できます。
クライアントがそうすることを選択する場合、"pre_shared_key"拡張と
"early_data"拡張の両方を供給しなければなりません (MUST)。
この拡張の"extension_data"フィールドは、"EarlyDataIndication"値を
含みます。
Rescorla Standards Track [Page 52]
RFC 8446 TLS 2018年8月
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;
max_early_data_sizeフィールドの使用に関する詳細については、
Section 4.6.1を参照してください。
0-RTTデータのパラメーター（バージョン、対称暗号スイート、
Application-Layer Protocol Negotiation (ALPN) [RFC7301]プロトコルなど）
は、使用中のPSKに関連付けられたものです。外部でプロビジョニング
されたPSKについて、関連付けられた値は鍵とともにプロビジョニング
されたものです。NewSessionTicketメッセージを介して確立されたPSKに
ついて、関連付けられた値はそのPSKを確立した接続で交渉されたものです。
early dataを暗号化するために使用されるPSKは、クライアントの
"pre_shared_key"拡張に列挙された最初のPSKでなければなりません
(MUST)。
NewSessionTicketを介してプロビジョニングされたPSKについて、サーバーは
選択されたPSKアイデンティティのチケット年齢
（PskIdentity.obfuscated_ticket_ageからticket_age_addを2^32を法として
減算して計算）が、チケット発行時からの時間に対して小さな許容範囲内
にあることを検証しなければなりません (MUST)（Section 8を参照）。
そうでない場合、サーバーはハンドシェイクを継続すべきですが0-RTTを
拒否すべきであり (SHOULD)、このClientHelloが新鮮であると仮定する他の
動作を行うべきではありません (SHOULD NOT)。
最初のフライトで送信される0-RTTメッセージは、他のフライトで送信される
同じ種類のメッセージ（handshakeおよびapplication_data）と同じ
（暗号化された）content typeを持ちますが、異なる鍵で保護されます。
サーバーのFinishedメッセージを受信した後、サーバーがearly dataを
受け入れた場合、鍵変更を示すためにEndOfEarlyDataメッセージが送信
されます。このメッセージは0-RTTトラフィック鍵で暗号化されます。
Rescorla Standards Track [Page 53]
RFC 8446 TLS 2018年8月
"early_data"拡張を受信したサーバーは、次の3つのいずれかの方法で動作
しなければなりません (MUST)。
- 拡張を無視し、通常の1-RTT応答を返します。その後サーバーは、
ハンドシェイクトラフィック鍵を使用して受信レコードの保護解除を
試み、保護解除に失敗したレコードを（設定されたmax_early_data_size
まで）破棄することで、early dataを読み飛ばします。レコードが正常に
保護解除されると、それはクライアントの2回目のフライトの開始として
扱われ、サーバーは通常の1-RTTハンドシェイクと同様に処理を進めます。
- HelloRetryRequestで応答することにより、クライアントに別のClientHelloの
送信を要求します。クライアントは後続のClientHelloに"early_data"拡張を
含めてはなりません (MUST NOT)。その後サーバーは、設定された
max_early_data_sizeまで、外部content typeが"application_data"
（暗号化されていることを示す）であるすべてのレコードをスキップする
ことでearly dataを無視します。
- EncryptedExtensions内で自身の"early_data"拡張を返し、early dataを処理
する意図があることを示します。サーバーがearly dataメッセージの
一部だけを受け入れることはできません。サーバーがearly dataを受け入れる
メッセージを送信したとしても、実際のearly data自体は、サーバーが
このメッセージを生成する時点ですでに転送中である可能性があります。
early dataを受け入れるために、サーバーはPSK暗号スイートを受け入れ、
クライアントの"pre_shared_key"拡張で提示された最初の鍵を選択して
いなければなりません (MUST)。さらに、次の値が選択されたPSKに関連付け
られた値と同じであることを検証しなければなりません (MUST)。
- TLSバージョン番号
- 選択された暗号スイート
- 選択されたALPN [RFC7301]プロトコル（存在する場合）
これらの要件は、対象のPSKを使用して1-RTTハンドシェイクを行うために
必要な要件の上位集合です。外部で確立されたPSKについて、関連付けられた
値は鍵とともにプロビジョニングされたものです。NewSessionTicketメッセージ
を介して確立されたPSKについて、関連付けられた値はチケットが確立された
接続中に交渉されたものです。
将来の拡張は、0-RTTとの相互作用を定義しなければなりません (MUST)。
Rescorla Standards Track [Page 54]
RFC 8446 TLS 2018年8月
これらの確認のいずれかが失敗した場合、サーバーは拡張で応答してはならず
(MUST NOT)、上に列挙した最初の2つの機構のいずれかを使用して最初の
フライトのデータをすべて破棄しなければなりません（したがって1-RTT
または2-RTTへフォールバックします）。クライアントが0-RTTハンドシェイクを
試みたもののサーバーがそれを拒否した場合、サーバーは通常0-RTTレコード
保護鍵を持たず、代わりに（1-RTTハンドシェイク鍵を用いるか、
HelloRetryRequestの場合に平文ClientHelloを探すことにより）試行的復号を
使用して最初の非0-RTTメッセージを見つけなければなりません。
サーバーが"early_data"拡張を受け入れることを選択した場合、early data
レコードを処理するとき、すべてのレコードについて規定された同じエラー
処理要件に従わなければなりません (MUST)。具体的には、受け入れられた
"early_data"拡張の後に0-RTTレコードの復号に失敗した場合、サーバーは
Section 5.2に従い、"bad_record_mac"アラートで接続を終了しなければ
なりません (MUST)。
サーバーが"early_data"拡張を拒否した場合、クライアントアプリケーションは、
ハンドシェイク完了後、early dataで以前に送信されたApplication Dataを
再送することを選択してもよいです (MAY)。early dataの自動再送は、接続の
状態に関して誤った仮定をもたらす可能性があることに注意してください。
たとえば、交渉された接続がearly dataで使用されたものとは異なるALPN
プロトコルを選択した場合、アプリケーションは異なるメッセージを構築する
必要があるかもしれません。同様に、early dataが接続状態について何らかの
仮定を行っている場合、ハンドシェイク完了後に誤って送信される可能性が
あります。
TLS実装はearly dataを自動的に再送すべきではありません (SHOULD NOT)。
再送が適切な時期を判断するには、アプリケーションの方がより適した
立場にあります。TLS実装は、交渉された接続が同じALPNプロトコルを選択
しない限り、early dataを自動的に再送してはなりません (MUST NOT)。
4.2.11. Pre-Shared Key Extension
"pre_shared_key"拡張は、PSK鍵確立に関連して、特定のハンドシェイクで
使用される事前共有鍵のアイデンティティを交渉するために使用されます。
Rescorla Standards Track [Page 55]
RFC 8446 TLS 2018年8月
この拡張の"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: 鍵のラベル。たとえば、Appendix B.3.4で定義されるチケット、
または外部で確立された事前共有鍵のラベルです。
obfuscated_ticket_age: 鍵の年齢の難読化バージョン。
Section 4.2.11.1では、NewSessionTicketメッセージを介して確立された
アイデンティティについて、この値を形成する方法を説明します。
外部で確立されたアイデンティティについては、obfuscated_ticket_age
として0を使用すべきであり (SHOULD)、サーバーはその値を無視しなければ
なりません (MUST)。
identities: クライアントがサーバーと交渉する意思のあるアイデンティティの
一覧。"early_data"拡張（Section 4.2.10を参照）とともに送信される
場合、最初のアイデンティティが0-RTTデータで使用されるものです。
binders: identities一覧内の各値に対して1つずつ、同じ順序で下記のとおり
計算されるHMAC値の列。
selected_identity: クライアントの一覧内のidentitiesへの（0始まりの）
インデックスとして表される、サーバーが選択したアイデンティティ。
各PSKは単一のHashアルゴリズムに関連付けられます。チケット機構
（Section 4.6.1）を介して確立されたPSKについて、これはチケットが
確立された接続上のKDF Hashアルゴリズムです。外部で確立されたPSK
について、Hashアルゴリズムは、PSKが確立されるときに設定されなければ
Rescorla Standards Track [Page 56]
RFC 8446 TLS 2018年8月
なりません (MUST)。そのようなアルゴリズムが定義されていない場合は、
SHA-256が既定値になります。サーバーは、互換性のあるPSK（存在する場合）
および暗号スイートを選択することを保証しなければなりません (MUST)。
TLS 1.3より前のTLSバージョンでは、Server Name Identification (SNI)値は
セッションに関連付けられることが意図されており（[RFC6066]の
Section 3）、サーバーには、セッションに関連付けられたSNI値が再開
ハンドシェイクで指定されたものと一致することを強制することが要求
されていました。しかし実際には、供給された2つのSNI値のうちどちらを
使用するかについて実装に一貫性がなく、その結果、一貫性要件は事実上
クライアントによって強制されるものとなっていました。TLS 1.3では、
SNI値は常に再開ハンドシェイク内で明示的に指定され、サーバーがSNI値を
チケットと関連付ける必要はありません。ただし、クライアントは
Section 4.6.1の要件を満たすため、SNIをPSKとともに保存すべきです
(SHOULD)。
実装者向け注記: セッション再開がPSKの主要なユースケースである場合、
PSK/暗号スイート一致要件を実装する最も単純な方法は、まず暗号スイートを
交渉し、その後互換性のないPSKを除外することです。未知のPSK（例:
PSKデータベースにないもの、または未知の鍵で暗号化されたもの）は、
単に無視すべきです (SHOULD)。受け入れ可能なPSKが見つからない場合、
サーバーは可能であれば非PSKハンドシェイクを実行すべきです (SHOULD)。
後方互換性が重要な場合、クライアントが提供した外部で確立されたPSKは
暗号スイート選択に影響を与えるべきです (SHOULD)。
PSK鍵確立を受け入れる前に、サーバーは対応するbinder値を検証しなければ
なりません (MUST)（下のSection 4.2.11.2を参照）。この値が存在
しない、または検証されない場合、サーバーはハンドシェイクを中止しなければ
なりません (MUST)。サーバーは複数のbinderを検証しようとすべきではなく
(SHOULD NOT)、むしろ単一のPSKを選択し、そのPSKに対応するbinderのみを
検証すべきです (SHOULD)。この要件のセキュリティ上の根拠については、
Section 8.2およびAppendix E.6を参照してください。PSK鍵確立を
受け入れるために、サーバーは選択されたアイデンティティを示す
"pre_shared_key"拡張を送信します。
クライアントは、サーバーのselected_identityがクライアントによって
供給された範囲内にあること、サーバーがPSKに関連付けられたHashを示す
暗号スイートを選択したこと、およびClientHelloの"psk_key_exchange_modes"
拡張によって要求される場合はサーバーの"key_share"拡張が存在することを
検証しなければなりません (MUST)。これらの値に一貫性がない場合、
クライアントは"illegal_parameter"アラートでハンドシェイクを中止しなけれ
ばなりません (MUST)。
Rescorla Standards Track [Page 57]
RFC 8446 TLS 2018年8月
サーバーが"early_data"拡張を供給する場合、クライアントはサーバーの
selected_identityが0であることを検証しなければなりません (MUST)。
他の値が返された場合、クライアントは"illegal_parameter"アラートで
ハンドシェイクを中止しなければなりません (MUST)。
"pre_shared_key"拡張はClientHello内の最後の拡張でなければなりません
(MUST)（これにより、下記のとおり実装が容易になります）。サーバーは、
それが最後の拡張であることを確認しなければならず (MUST)、そうでない
場合は"illegal_parameter"アラートでハンドシェイクを失敗させます。
4.2.11.1. Ticket Age
クライアントから見たチケットの年齢は、NewSessionTicketメッセージの
受信時からの時間です。クライアントは、チケットとともに提供された
"ticket_lifetime"値より大きい年齢を持つチケットを使用しようとしては
なりません (MUST NOT)。各PskIdentityの"obfuscated_ticket_age"フィールドは、
ミリ秒単位の年齢を取り、チケットとともに含まれていた
"ticket_age_add"値（Section 4.6.1を参照）を2^32を法として加算する
ことによって形成される、チケット年齢の難読化バージョンを含みます。
この加算により、チケットが再利用されない限り、受動的観測者が接続を
相関付けることが防止されます。NewSessionTicketメッセージ内の
"ticket_lifetime"フィールドは秒単位ですが、"obfuscated_ticket_age"は
ミリ秒単位であることに注意してください。チケット有効期間は1週間に
制限されているため、32ビットは、ミリ秒単位であっても、あり得る年齢を
表すのに十分です。
4.2.11.2. PSK Binder
PSK binder値は、PSKと現在のハンドシェイクとの間の結合、および
（NewSessionTicketメッセージを介する場合）PSKが生成されたハンドシェイクと
現在のハンドシェイクとの間の結合を形成します。binders一覧内の各項目は、
PreSharedKeyExtension.identitiesフィールドまでを含む部分ClientHelloを
含むtranscript hash（Section 4.4.1を参照）に対するHMACとして計算
されます。すなわち、binders一覧自体を除くClientHello全体を含みます。
メッセージの長さフィールド（全体の長さ、extensionsブロックの長さ、
および"pre_shared_key"拡張の長さを含む）は、正しい長さのbinderが存在する
かのようにすべて設定されます。
PskBinderEntryはFinishedメッセージ（Section 4.4.4）と同じ方法で
計算されますが、BaseKeyは、提示されている対応するPSKから鍵スケジュールを
介して導出されたbinder_keyです（Section 7.1を参照）。
Rescorla Standards Track [Page 58]
RFC 8446 TLS 2018年8月
ハンドシェイクにHelloRetryRequestが含まれる場合、最初のClientHelloと
HelloRetryRequestは新しいClientHelloとともにトランスクリプトに含まれます。
たとえば、クライアントがClientHello1を送信する場合、そのbinderは次に
対して計算されます。
Transcript-Hash(Truncate(ClientHello1))
ここで、Truncate()はClientHelloからbinders一覧を削除します。
サーバーがHelloRetryRequestで応答し、クライアントがその後ClientHello2を
送信する場合、そのbinderは次に対して計算されます。
Transcript-Hash(ClientHello1,
HelloRetryRequest,
Truncate(ClientHello2))
完全なClientHello1/ClientHello2は、その他すべてのハンドシェイクハッシュ
計算に含まれます。最初のフライトではTruncate(ClientHello1)が直接
ハッシュされますが、2回目のフライトではClientHello1がハッシュされ、
Section 4.4.1で説明されるように"message_hash"メッセージとして再注入
されることに注意してください。
4.2.11.3. Processing Order
クライアントは、サーバーのFinishedを受信するまで0-RTTデータを
「ストリーム」することが許可されており、その後でのみEndOfEarlyData
メッセージを送信し、続いてハンドシェイクの残りを送信します。
デッドロックを避けるため、"early_data"を受け入れるとき、サーバーは
クライアントのEndOfEarlyDataメッセージを待ってからServerHelloを送信する
のではなく、クライアントのClientHelloを処理し、その直後に自身の
メッセージフライトを送信しなければなりません (MUST)。
4.3. Server Parameters
サーバーからの次の2つのメッセージ、EncryptedExtensionsおよび
CertificateRequestは、ハンドシェイクの残りを決定するサーバーからの
情報を含みます。これらのメッセージはserver_handshake_traffic_secretから
導出された鍵で暗号化されます。
Rescorla Standards Track [Page 59]
RFC 8446 TLS 2018年8月
4.3.1. Encrypted Extensions
すべてのハンドシェイクにおいて、サーバーはServerHelloメッセージの直後に
EncryptedExtensionsメッセージを送信しなければなりません (MUST)。
これはserver_handshake_traffic_secretから導出された鍵で暗号化される
最初のメッセージです。
EncryptedExtensionsメッセージは、保護できる拡張、すなわち暗号コンテキストを
確立するためには不要であり、かつ個々の証明書に関連付けられていない任意の
拡張を含みます。クライアントは、禁止された拡張の存在について
EncryptedExtensionsを確認しなければならず (MUST)、見つかった場合は
"illegal_parameter"アラートでハンドシェイクを中止しなければなりません
(MUST)。
このメッセージの構造:
struct {
Extension extensions<0..2^16-1>;
} EncryptedExtensions;
extensions: 拡張の一覧。詳細については、Section 4.2の表を参照して
ください。
4.3.2. Certificate Request
証明書で認証しているサーバーは、任意でクライアントから証明書を要求
してもよいです (MAY)。このメッセージが送信される場合、
EncryptedExtensionsに続かなければなりません (MUST)。
このメッセージの構造:
struct {
opaque certificate_request_context<0..2^8-1>;
Extension extensions<2..2^16-1>;
} CertificateRequest;
Rescorla Standards Track [Page 60]
RFC 8446 TLS 2018年8月
certificate_request_context: 証明書要求を識別するopaque文字列であり、
クライアントのCertificateメッセージ内でエコーされます。
certificate_request_contextは、この接続のスコープ内で一意でなければ
なりません (MUST)（これにより、クライアントCertificateVerify
メッセージのリプレイを防ぎます）。このフィールドは、
Section 4.6.2で説明されるハンドシェイク後認証交換で使用される
場合を除き、長さ0でなければなりません (SHALL)。ハンドシェイク後
認証を要求する場合、サーバーは、クライアントにとってコンテキストが
予測不能になるようにすべきです (SHOULD)（例: ランダムに生成する）。
これは、クライアントの秘密鍵に一時的にアクセスできる攻撃者が、
有効なCertificateVerifyメッセージを事前計算することを防ぐためです。
extensions: 要求されている証明書のパラメーターを記述する拡張の集合。
"signature_algorithms"拡張は指定されなければならず (MUST)、この
メッセージについて定義されている場合、他の拡張を任意で含めても
よいです。クライアントは認識しない拡張を無視しなければなりません
(MUST)。
以前のTLSバージョンでは、CertificateRequestメッセージは、サーバーが
受け入れる署名アルゴリズムおよび認証局の一覧を搬送していました。
TLS 1.3では、前者は"signature_algorithms"拡張および任意で
"signature_algorithms_cert"拡張を送信することで表現されます。後者は
"certificate_authorities"拡張を送信することで表現されます
（Section 4.2.4を参照）。
PSKで認証しているサーバーは、メインハンドシェイク内で
CertificateRequestメッセージを送信してはなりません (MUST NOT)。
ただし、クライアントが"post_handshake_auth"拡張（Section 4.2.6を
参照）を送信している場合、ハンドシェイク後認証
（Section 4.6.2を参照）で送信してもよいです (MAY)。
4.4. Authentication Messages
Section 2で説明したように、TLSは一般に、認証、鍵確認、および
ハンドシェイク完全性のために、Certificate、CertificateVerify、および
Finishedという共通のメッセージ集合を使用します。（PSK binderも同様の
方法で鍵確認を実行します。）これら3つのメッセージは、常にそれぞれの
ハンドシェイクフライトの最後のメッセージとして送信されます。
CertificateおよびCertificateVerifyメッセージは、以下で定義される特定の
状況でのみ送信されます。Finishedメッセージは常にAuthentication Blockの
一部として送信されます。これらのメッセージは、
[sender]_handshake_traffic_secretから導出された鍵で暗号化されます。
Rescorla Standards Track [Page 61]
RFC 8446 TLS 2018年8月
Authenticationメッセージの計算は、すべて一様に次の入力を取ります。
- 使用される証明書および署名鍵。
- transcript hashに含められるメッセージ集合から構成される
Handshake Context。
- MAC鍵を計算するために使用されるBase Key。
これらの入力に基づき、メッセージは次の内容を含みます。
Certificate: 認証に使用される証明書、およびチェーン内の任意の補助
証明書。証明書ベースのクライアント認証は、PSKハンドシェイクフロー
（0-RTTを含む）では利用できないことに注意してください。
CertificateVerify: 値
Transcript-Hash(Handshake Context, Certificate)
に対する署名。
Finished: Base Keyから導出されたMAC鍵を使用した、値
Transcript-Hash(Handshake Context,
Certificate, CertificateVerify) に対するMAC。
次の表は、各シナリオに対するHandshake ContextおよびMAC Base Keyを
定義します。
+-----------+-------------------------+-----------------------------+
| Mode | Handshake Context | Base Key |
+-----------+-------------------------+-----------------------------+
| Server | ClientHello ... later | server_handshake_traffic_ |
| | of EncryptedExtensions/ | secret |
| | CertificateRequest | |
| | | |
| Client | ClientHello ... later | client_handshake_traffic_ |
| | of server | secret |
| | Finished/EndOfEarlyData | |
| | | |
| Post- | ClientHello ... client | client_application_traffic_ |
| Handshake | Finished + | secret_N |
| | CertificateRequest | |
+-----------+-------------------------+-----------------------------+
Rescorla Standards Track [Page 62]
RFC 8446 TLS 2018年8月
4.4.1. The Transcript Hash
TLSにおける多くの暗号計算はtranscript hashを使用します。この値は、
含まれる各ハンドシェイクメッセージの連結をハッシュすることで計算
されます。これには、ハンドシェイクメッセージ種別および長さフィールドを
搬送するハンドシェイクメッセージヘッダーを含みますが、レコード層
ヘッダーは含みません。すなわち、
Transcript-Hash(M1, M2, ... Mn) = Hash(M1 || M2 || ... || Mn)
この一般規則の例外として、サーバーがClientHelloにHelloRetryRequestで
応答する場合、ClientHello1の値は、Hash(ClientHello1)を含む
handshake type "message_hash"の特別な合成ハンドシェイクメッセージで
置き換えられます。すなわち、
Transcript-Hash(ClientHello1, HelloRetryRequest, ... Mn) =
Hash(message_hash || /* Handshake type */
00 00 Hash.length || /* Handshake message length (bytes) */
Hash(ClientHello1) || /* Hash of ClientHello1 */
HelloRetryRequest || ... || Mn)
この構成の理由は、サーバーが中間ハッシュ状態全体をエクスポートする
必要なく、cookie内にClientHello1のハッシュだけを保存することで、
ステートレスなHelloRetryRequestを行えるようにするためです
（Section 4.2.2を参照）。
具体性のため、transcript hashは常に、最初のClientHelloから開始し、
送信されたメッセージのみを含む、次のハンドシェイクメッセージ列から
取られます: ClientHello、HelloRetryRequest、ClientHello、ServerHello、
EncryptedExtensions、server CertificateRequest、server Certificate、
server CertificateVerify、server Finished、EndOfEarlyData、client
Certificate、client CertificateVerify、client Finished。
一般に、実装は交渉されたハッシュに基づく実行中のtranscript hash値を
保持することで、トランスクリプトを実装できます。ただし、後続の
ハンドシェイク後認証は互いを含まず、メインハンドシェイクの終端までの
メッセージだけを含むことに注意してください。
Rescorla Standards Track [Page 63]
RFC 8446 TLS 2018年8月
4.4.2. Certificate
このメッセージは、エンドポイントの証明書チェーンをピアへ伝達します。
合意された鍵交換方式が認証に証明書を使用する場合、サーバーは常に
Certificateメッセージを送信しなければなりません (MUST)
（これには、PSKを除く、本文書で定義されるすべての鍵交換方式が含まれます）。
サーバーがCertificateRequestメッセージ（Section 4.3.2）を介して
クライアント認証を要求した場合に限り、クライアントはCertificate
メッセージを送信しなければなりません (MUST)。サーバーがクライアント
認証を要求しているが、適切な証明書が利用できない場合、クライアントは
証明書を含まないCertificateメッセージ（すなわち、"certificate_list"
フィールドの長さが0）を送信しなければなりません (MUST)。
Certificateメッセージが空であるかどうかにかかわらず、Finished
メッセージは送信されなければなりません (MUST)。
このメッセージの構造:
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;
Rescorla Standards Track [Page 64]
RFC 8446 TLS 2018年8月
certificate_request_context: このメッセージがCertificateRequestへの応答で
ある場合、そのメッセージ内のcertificate_request_contextの値。
それ以外の場合（サーバー認証の場合）、このフィールドは長さ0で
なければなりません (SHALL)。
certificate_list: CertificateEntry構造の列（チェーン）。それぞれが単一の
証明書および拡張の集合を含みます。
extensions: CertificateEntryに対する拡張値の集合。"Extension"形式は
Section 4.2で定義されます。現時点でサーバー証明書に有効な拡張には、
OCSP Status拡張 [RFC6066] およびSignedCertificateTimestamp拡張
[RFC6962] が含まれます。将来、このメッセージに対する拡張も定義される
可能性があります。サーバーからのCertificateメッセージ内の拡張は、
ClientHelloメッセージからのものに対応しなければなりません (MUST)。
クライアントからのCertificateメッセージ内の拡張は、サーバーからの
CertificateRequestメッセージ内の拡張に対応しなければなりません
(MUST)。拡張がチェーン全体に適用される場合、それは最初の
CertificateEntryに含めるべきです (SHOULD)。
対応する証明書種別拡張（"server_certificate_type"または
"client_certificate_type"）がEncryptedExtensionsで交渉されていない場合、
またはX.509証明書種別が交渉された場合、各CertificateEntryは
DERエンコードされたX.509証明書を含みます。送信者の証明書は一覧内の
最初のCertificateEntryに来なければなりません (MUST)。後続の各証明書は、
直前の証明書を直接証明すべきです (SHOULD)。証明書検証ではトラスト
アンカーが独立に配布される必要があるため、トラストアンカーを指定する
証明書は、サポートされるピアが省略された証明書を持っていることが
分かっているなら、チェーンから省略してもよいです (MAY)。
注: TLS 1.3より前では、"certificate_list"の順序は各証明書が直前の
証明書を証明することを要求していました。ただし、一部の実装はある程度の
柔軟性を許容していました。サーバーは移行目的で現在の中間証明書と
非推奨の中間証明書の両方を送信することがあり、また単に誤って構成
されているものもありますが、それでもこれらのケースは適切に検証できる
場合があります。最大限の互換性のため、すべての実装は、任意のTLS
バージョンからの潜在的に余分な証明書および任意の順序を処理する準備が
できているべきです (SHOULD)。ただし、最初でなければならないエンド
エンティティ証明書は例外です (MUST)。
RawPublicKey証明書種別が交渉された場合、certificate_listは高々1つの
CertificateEntryを含まなければならず (MUST)、それは
[RFC7250], Section 3で定義されるASN1_subjectPublicKeyInfo値を
含みます。
Rescorla Standards Track [Page 65]
RFC 8446 TLS 2018年8月
OpenPGP証明書種別 [RFC6091] は、TLS 1.3で使用してはなりません
(MUST NOT)。
サーバーのcertificate_listは常に空であってはなりません (MUST)。
クライアントは、サーバーの認証要求に応答して送信する適切な証明書を
持たない場合、空のcertificate_listを送信します。
4.4.2.1. OCSP Status and SCT Extensions
[RFC6066]および[RFC6961]は、サーバーがOCSP応答をクライアントへ
送信することを交渉するための拡張を提供します。TLS 1.2以下では、
サーバーはこの拡張の交渉を示すために空の拡張で応答し、OCSP情報は
CertificateStatusメッセージで搬送されます。TLS 1.3では、サーバーの
OCSP情報は、関連する証明書を含むCertificateEntry内の拡張で搬送されます。
具体的には、サーバーからの"status_request"拡張の本体は、[RFC6066]で
定義されるCertificateStatus構造でなければならず (MUST)、[RFC6960]で
定義されるとおりに解釈されます。
注: status_request_v2拡張 [RFC6961] は非推奨です。TLS 1.3サーバーは、
ClientHelloメッセージを処理するとき、その存在またはその中の情報に
基づいて動作してはなりません (MUST NOT)。特に、
EncryptedExtensions、CertificateRequest、またはCertificateメッセージ内で
status_request_v2拡張を送信してはなりません (MUST NOT)。TLS 1.3
サーバーは、それを含むClientHelloメッセージを処理できなければなりません
(MUST)。これは、以前のプロトコルバージョンで使用したいクライアントが
送信してもよいためです (MAY)。
サーバーは、CertificateRequestメッセージ内で空の"status_request"拡張を
送信することにより、クライアントに証明書とともにOCSP応答を提示する
よう要求してもよいです (MAY)。クライアントがOCSP応答を送信することを
選択した場合、その"status_request"拡張の本体は[RFC6066]で定義される
CertificateStatus構造でなければなりません (MUST)。
同様に、[RFC6962]は、TLS 1.2以下で、サーバーがSigned Certificate
Timestamp (SCT) をServerHello内の拡張として送信する機構を提供します。
TLS 1.3では、サーバーのSCT情報はCertificateEntry内の拡張で搬送されます。
Rescorla Standards Track [Page 66]
RFC 8446 TLS 2018年8月
4.4.2.2. Server Certificate Selection
次の規則は、サーバーによって送信される証明書に適用されます。
- 証明書種別は、明示的に別途交渉されない限り（例: [RFC7250]）、
X.509v3 [RFC5280]でなければなりません (MUST)。
- サーバーのエンドエンティティ証明書の公開鍵（および関連する制約）は、
クライアントの"signature_algorithms"拡張から選択された認証
アルゴリズム（現在はRSA、ECDSA、またはEdDSA）と互換性がなければ
なりません (MUST)。
- 証明書は、クライアントの"signature_algorithms"/
"signature_algorithms_cert"拡張で示される署名方式（Section 4.2.3を
参照）で署名に鍵を使用できることを許可しなければなりません (MUST)
（すなわち、Key Usage拡張が存在する場合、digitalSignatureビットが
設定されていなければなりません (MUST)）。
- "server_name" [RFC6066]および"certificate_authorities"拡張は、
証明書選択を導くために使用されます。サーバーは"server_name"拡張の
存在を要求してもよいので (MAY)、該当する場合、クライアントはこの
拡張を送信すべきです (SHOULD)。
サーバーによって提供されるすべての証明書は、そのようなチェーンを提供
できる場合、クライアントによって広告された署名アルゴリズムで署名されて
いなければなりません (MUST)（Section 4.2.3を参照）。自己署名証明書、
またはトラストアンカーであることが期待される証明書は、チェーンの一部
として検証されないため、任意のアルゴリズムで署名されてもよいです (MAY)。
サーバーが、示されたサポートアルゴリズムのみで署名された証明書チェーンを
生成できない場合、クライアントがサポートすることが分かっていない
アルゴリズムを含む可能性がある任意の証明書チェーンをクライアントへ
送信して、ハンドシェイクを継続すべきです (SHOULD)。このフォールバック
チェーンは、一般には非推奨のSHA-1ハッシュアルゴリズムを使用すべきでは
ありません (SHOULD NOT) が、クライアントの広告が許可する場合は使用しても
よく (MAY)、そうでない場合は使用してはなりません (MUST NOT)。
クライアントが提供された証明書を使用して受け入れ可能なチェーンを構築
できず、ハンドシェイクを中止することを決定した場合、適切な証明書関連
アラート（既定では"unsupported_certificate"。詳細はSection 6.2を参照）で
ハンドシェイクを中止しなければなりません (MUST)。
サーバーが複数の証明書を持つ場合、上記の基準（およびトランスポート層
エンドポイント、ローカル構成、優先順位などの他の基準）に基づいて、
それらのうち1つを選択します。
Rescorla Standards Track [Page 67]
RFC 8446 TLS 2018年8月
4.4.2.3. Client Certificate Selection
次の規則は、クライアントによって送信される証明書に適用されます。
- 証明書種別は、明示的に別途交渉されない限り（例: [RFC7250]）、
X.509v3 [RFC5280]でなければなりません (MUST)。
- CertificateRequestメッセージ内に"certificate_authorities"拡張が存在した
場合、証明書チェーン内の少なくとも1つの証明書は、列挙されたCAの
いずれかによって発行されているべきです (SHOULD)。
- 証明書は、Section 4.3.2で説明されるように、受け入れ可能な署名
アルゴリズムを使用して署名されていなければなりません (MUST)。
これは、以前のTLSバージョンに見られた証明書署名アルゴリズムへの
制約を緩和することに注意してください。
- CertificateRequestメッセージが空でない"oid_filters"拡張を含んでいた
場合、エンドエンティティ証明書は、Section 4.2.5で説明されるように、
クライアントが認識する拡張OIDに一致しなければなりません (MUST)。
4.4.2.4. Receiving a Certificate Message
一般に、詳細な証明書検証手順はTLSの範囲外です（[RFC5280]を参照）。
このセクションは、TLS固有の要件を提供します。
サーバーが空のCertificateメッセージを供給した場合、クライアントは
"decode_error"アラートでハンドシェイクを中止しなければなりません
(MUST)。
クライアントが証明書を送信しない場合（すなわち、空のCertificate
メッセージを送信する場合）、サーバーは裁量により、クライアント認証
なしでハンドシェイクを継続しても、"certificate_required"アラートで
ハンドシェイクを中止してもよいです (MAY)。また、証明書チェーンの
何らかの側面が受け入れ不能であった場合（例: 既知の信頼されたCAで署名
されていなかった場合）、サーバーは裁量により、ハンドシェイクを継続
する（クライアントを未認証と見なす）か、ハンドシェイクを中止しても
よいです (MAY)。
エンドポイントは、MD5ハッシュを使用する任意の署名アルゴリズムで検証する
必要がある証明書を受信した場合、"bad_certificate"アラートでハンド
シェイクを中止しなければなりません (MUST)。SHA-1は非推奨であり、
エンドポイントがSHA-1ハッシュを使用する任意の署名アルゴリズムで検証する
必要がある証明書を受信した場合、"bad_certificate"アラートでハンド
シェイクを中止することが推奨されます (RECOMMENDED)。明確にすると、
これは、エンドポイントが自己署名証明書またはトラストアンカーである
証明書について、これらのアルゴリズムを受け入れられることを意味します。
Rescorla Standards Track [Page 68]
RFC 8446 TLS 2018年8月
すべてのエンドポイントは、現在SHA-1サポートを段階的に廃止している
実装との相互運用性を維持するため、できるだけ早くSHA-256以上へ移行する
ことが推奨されます (RECOMMENDED)。
ある署名アルゴリズム用の鍵を含む証明書が、別の署名アルゴリズムを
使用して署名されてもよいことに注意してください (MAY)
（たとえば、ECDSA鍵で署名されたRSA鍵）。
4.4.3. Certificate Verify
このメッセージは、エンドポイントが自身の証明書に対応する秘密鍵を
所有していることの明示的な証明を提供するために使用されます。
CertificateVerifyメッセージは、この時点までのハンドシェイクの完全性も
提供します。サーバーは、証明書を介して認証するとき、このメッセージを
送信しなければなりません (MUST)。クライアントは、証明書を介して認証
するとき（すなわち、Certificateメッセージが空でないとき）は常に、この
メッセージを送信しなければなりません (MUST)。送信される場合、この
メッセージはCertificateメッセージの直後、かつFinishedメッセージの直前に
現れなければなりません (MUST)。
このメッセージの構造:
struct {
SignatureScheme algorithm;
opaque signature<0..2^16-1>;
} CertificateVerify;
algorithmフィールドは、使用される署名アルゴリズムを指定します
（この型の定義についてはSection 4.2.3を参照）。signatureは、
そのアルゴリズムを使用するデジタル署名です。署名の対象となる内容は、
Section 4.4.1で説明されるハッシュ出力、すなわち次のものです。
Transcript-Hash(Handshake Context, Certificate)
その後、デジタル署名は次の連結に対して計算されます。
- octet 32 (0x20) が64回繰り返された文字列
- context string
- 区切りとして機能する単一の0バイト
- 署名される内容
Rescorla Standards Track [Page 69]
RFC 8446 TLS 2018年8月
この構造は、以前のTLSバージョンに対する攻撃を防ぐことを意図しています。
その攻撃では、ServerKeyExchange形式により、攻撃者が選択した32バイトの
プレフィックス (ClientHello.random) を持つメッセージの署名を取得できました。
最初の64バイトのパッドは、サーバーが制御するServerHello.randomとともに
そのプレフィックスを消去します。
サーバー署名のcontext stringは
"TLS 1.3, server CertificateVerify"です。クライアント署名のcontext stringは
"TLS 1.3, client CertificateVerify"です。これは異なるコンテキストで作成
された署名を分離するために使用され、潜在的なクロスプロトコル攻撃への
対策に役立ちます。
たとえば、transcript hashが32バイトの01であった場合（この長さはSHA-256で
意味を持ちます）、サーバーCertificateVerifyのデジタル署名によってカバー
される内容は次のようになります。
2020202020202020202020202020202020202020202020202020202020202020
2020202020202020202020202020202020202020202020202020202020202020
544c5320312e332c207365727665722043657274696669636174655665726966
79
00
0101010101010101010101010101010101010101010101010101010101010101
送信側では、CertificateVerifyメッセージのsignatureフィールドを計算する
処理は次を入力として取ります。
- デジタル署名によってカバーされる内容
- 直前のメッセージで送信された証明書に対応する署名用秘密鍵
CertificateVerifyメッセージがサーバーによって送信される場合、有効な
証明書チェーンがサポートされていないアルゴリズムなしでは生成できない
場合を除き（Section 4.2.3を参照）、署名アルゴリズムはクライアントの
"signature_algorithms"拡張で提示されたものの1つでなければなりません
(MUST)。
クライアントによって送信される場合、署名で使用される署名アルゴリズムは、
CertificateRequestメッセージ内の"signature_algorithms"拡張の
supported_signature_algorithmsフィールドに存在するものの1つでなければ
なりません (MUST)。
さらに、署名アルゴリズムは送信者のエンドエンティティ証明書内の鍵と
互換性がなければなりません (MUST)。RSA署名は、RSASSA-PKCS1-v1_5
アルゴリズムが"signature_algorithms"に現れるかどうかにかかわらず、
RSASSA-PSSアルゴリズムを使用しなければなりません (MUST)。
SHA-1アルゴリズムは、CertificateVerifyメッセージのいかなる署名にも
使用してはなりません (MUST NOT)。
Rescorla Standards Track [Page 70]
RFC 8446 TLS 2018年8月
本仕様におけるすべてのSHA-1署名アルゴリズムは、レガシー証明書での
使用のためだけに定義されており、CertificateVerify署名には有効では
ありません。
CertificateVerifyメッセージの受信者は、signatureフィールドを検証しなければ
なりません (MUST)。検証処理は次を入力として取ります。
- デジタル署名によってカバーされる内容
- 関連するCertificateメッセージで見つかるエンドエンティティ証明書に
含まれる公開鍵
- CertificateVerifyメッセージのsignatureフィールドで受信したデジタル署名
検証が失敗した場合、受信者は"decrypt_error"アラートでハンドシェイクを
終了しなければなりません (MUST)。
4.4.4. Finished
FinishedメッセージはAuthentication Block内の最後のメッセージです。
これは、ハンドシェイクおよび計算された鍵の認証を提供するために不可欠です。
Finishedメッセージの受信者は、内容が正しいことを検証しなければならず
(MUST)、正しくない場合は"decrypt_error"アラートで接続を終了しなければ
なりません (MUST)。
一方が自身のFinishedメッセージを送信し、ピアからのFinishedメッセージを
受信して検証すると、その接続上でApplication Dataの送受信を開始しても
よいです。ピアのFinishedを受信する前にデータ送信が許可される設定は
2つあります。
1. Section 4.2.10で説明される0-RTTデータを送信するクライアント。
2. サーバーは最初のフライトを送信した後にデータを送信してもよいです
(MAY)。ただし、ハンドシェイクはまだ完了していないため、ピアの
アイデンティティまたはその生存性（すなわち、ClientHelloがリプレイ
された可能性）について保証はありません。
Rescorla Standards Track [Page 71]
RFC 8446 TLS 2018年8月
Finishedメッセージの計算に使用される鍵は、HKDF（Section 7.1を参照）を
使用して、Section 4.4で定義されるBase Keyから計算されます。
具体的には次のとおりです。
finished_key =
HKDF-Expand-Label(BaseKey, "finished", "", Hash.length)
このメッセージの構造:
struct {
opaque verify_data[Hash.length];
} Finished;
verify_data値は次のように計算されます。
verify_data =
HMAC(finished_key,
Transcript-Hash(Handshake Context,
Certificate*, CertificateVerify*))
* 存在する場合のみ含まれます。
HMAC [RFC2104]は、ハンドシェイクのHashアルゴリズムを使用します。上で
述べたように、HMAC入力は一般に実行中のハッシュ、すなわちこの時点での
ハンドシェイクハッシュだけで実装できます。
以前のTLSバージョンでは、verify_dataは常に12オクテット長でした。
TLS 1.3では、ハンドシェイクに使用されるHashのHMAC出力のサイズです。
注: アラートおよびその他の非ハンドシェイクレコード種別はハンドシェイク
メッセージではなく、ハッシュ計算に含まれません。
Finishedメッセージに続く任意のレコードは、Section 7.2で説明される
適切なアプリケーショントラフィック鍵で暗号化されなければなりません
(MUST)。特に、これにはクライアントCertificateおよびCertificateVerify
メッセージに応答してサーバーが送信する任意のアラートが含まれます。
4.5. End of Early Data
struct {} EndOfEarlyData;
サーバーがEncryptedExtensions内で"early_data"拡張を送信した場合、
クライアントはサーバーFinishedを受信した後にEndOfEarlyDataメッセージを
送信しなければなりません (MUST)。サーバーがEncryptedExtensions内で
"early_data"拡張を送信しない場合、クライアントはEndOfEarlyData
メッセージを送信してはなりません (MUST NOT)。このメッセージは、
0-RTT application_dataメッセージが存在する場合、それらがすべて送信
されたこと、および
Rescorla Standards Track [Page 72]
RFC 8446 TLS 2018年8月
後続のレコードがハンドシェイクトラフィック鍵で保護されることを示します。
サーバーはこのメッセージを送信してはならず (MUST NOT)、それを受信した
クライアントは"unexpected_message"アラートで接続を終了しなければなり
ません (MUST)。このメッセージはclient_early_traffic_secretから導出された
鍵で暗号化されます。
4.6. Post-Handshake Messages
TLSは、メインハンドシェイク後に他のメッセージを送信することも許可
します。これらのメッセージはハンドシェイクcontent typeを使用し、適切な
アプリケーショントラフィック鍵で暗号化されます。
4.6.1. New Session Ticket Message
サーバーは、クライアントFinishedメッセージを受信した後であればいつでも、
NewSessionTicketメッセージを送信してもよいです (MAY)。このメッセージは、
チケット値と、resumption master secretから導出されたsecret PSKとの間に
一意の関連付けを作成します（Section 7を参照）。
クライアントは、将来のハンドシェイクで、このPSKを使用するために、
ClientHello内の"pre_shared_key"拡張にチケット値を含めてもよいです
(MAY)（Section 4.2.11）。サーバーは、単一の接続上で複数の
チケットを送信してもよく (MAY)、それらを相互に直後に送信しても、
特定のイベント後に送信してもよいです（Appendix C.4を参照）。
たとえば、サーバーは追加のクライアント認証状態をカプセル化するため、
ハンドシェイク後認証の後で新しいチケットを送信するかもしれません。
複数のチケットは、次を含むさまざまな目的でクライアントに有用です。
- 複数の並列HTTP接続を開くこと。
- （たとえば）Happy Eyeballs [RFC8305]または関連技術を介して、
インターフェースおよびアドレスファミリをまたぐ接続レースを行うこと。
任意のチケットは、元の接続を確立するために使用されたものと同じ
KDFハッシュアルゴリズムを持つ暗号スイートでのみ再開されなければ
なりません (MUST)。
クライアントは、新しいSNI値が元のセッションで提示されたサーバー証明書に
対して有効である場合にのみ再開しなければならず (MUST)、SNI値が元の
セッションで使用されたものと一致する場合にのみ再開すべきです (SHOULD)。
後者は性能最適化です。通常、単一の証明書でカバーされる異なるサーバーが
互いのチケットを受け入れられると期待する理由はありません。したがって、
その場合に再開を試みると、単回使用チケットを無駄にします。そのような
表示が（外部またはその他の手段により）提供される場合、クライアントは
異なるSNI値で再開してもよいです (MAY)。
Rescorla Standards Track [Page 73]
RFC 8446 TLS 2018年8月
再開時に、呼び出し元アプリケーションへSNI値を報告する場合、実装は前の
セッションで送信された値ではなく、再開ClientHelloで送信された値を使用
しなければなりません (MUST)。サーバー実装が異なるSNI値を持つすべての
PSKアイデンティティを拒否する場合、これら2つの値は常に同じであることに
注意してください。
注: resumption master secretはクライアントの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-2>;
} NewSessionTicket;
ticket_lifetime: チケット発行時からの有効期間を、ネットワークバイト
オーダーの32ビット符号なし整数として秒単位で示します。サーバーは
604800秒（7日）を超える値を使用してはなりません (MUST NOT)。値0は、
チケットを直ちに破棄すべきであることを示します。クライアントは
ticket_lifetimeにかかわらず、7日を超えてチケットをキャッシュしては
ならず (MUST NOT)、ローカルポリシーに基づいてより早く削除しても
よいです (MAY)。サーバーは、ticket_lifetimeに記載された期間より短い
期間だけチケットを有効と扱ってもよいです (MAY)。
ticket_age_add: クライアントが"pre_shared_key"拡張に含めるチケット年齢を
隠蔽するために使用される、安全に生成されたランダムな32ビット値。
クライアント側のチケット年齢は、この値に2^32を法として加算され、
クライアントによって送信される値が得られます。サーバーは送信する各
チケットについて新しい値を生成しなければなりません (MUST)。
ticket_nonce: この接続で発行されるすべてのチケットにわたって一意な、
チケットごとの値。
Rescorla Standards Track [Page 74]
RFC 8446 TLS 2018年8月
ticket: PSKアイデンティティとして使用されるチケットの値。チケット自体は
opaqueラベルです。これはデータベース検索鍵であっても、自己暗号化かつ
自己認証された値であってもよいです (MAY)。
extensions: チケットに対する拡張値の集合。"Extension"形式は
Section 4.2で定義されます。クライアントは認識しない拡張を無視しなければ
なりません (MUST)。
NewSessionTicketについて現在定義されている唯一の拡張は"early_data"であり、
そのチケットが0-RTTデータを送信するために使用されてもよいことを示します
（Section 4.2.10）。これは次の値を含みます。
max_early_data_size: このチケットを使用するときにクライアントが送信を
許可される0-RTTデータの最大量（バイト単位）。Application Data
ペイロード（すなわち、平文。ただしパディングまたはinner content type
バイトは含まない）のみが数えられます。max_early_data_sizeバイトを超える
0-RTTデータを受信したサーバーは、"unexpected_message"アラートで接続を
終了すべきです (SHOULD)。暗号材料が不足しているためearly dataを拒否する
サーバーは、パディングと内容を区別できないため、クライアントはearly
dataレコード内で大量のパディングを送信できることに依存すべきではない
ことに注意してください (SHOULD NOT)。
チケットに関連付けられたPSKは次のように計算されます。
HKDF-Expand-Label(resumption_master_secret,
"resumption", ticket_nonce, Hash.length)
ticket_nonce値は各NewSessionTicketメッセージごとに異なるため、各チケットに
対して異なるPSKが導出されます。
原理上、初期の非PSKハンドシェイク（おそらくピアの証明書に結び付けられて
いる）から元々導出された鍵材料の寿命を無期限に延長する新しいチケットを
発行し続けることが可能であることに注意してください。実装は、そのような
鍵材料の総寿命に制限を設けることが推奨されます (RECOMMENDED)。
これらの制限は、ピアの証明書の寿命、介在する失効の可能性、およびピアの
オンラインCertificateVerify署名からの経過時間を考慮に入れるべきです。
4.6.2. Post-Handshake Authentication
クライアントが"post_handshake_auth"拡張（Section 4.2.6を参照）を送信
している場合、サーバーはハンドシェイク完了後いつでも
CertificateRequestメッセージを送信することで、クライアント認証を要求しても
よいです (MAY)。クライアントは適切なAuthenticationメッセージ
（Section 4.4を参照）で応答しなければなりません (MUST)。
クライアントが認証することを選択する場合、Certificate、CertificateVerify、
Rescorla Standards Track [Page 75]
RFC 8446 TLS 2018年8月
およびFinishedを送信しなければなりません (MUST)。拒否する場合、
証明書を含まないCertificateメッセージを送信し、その後にFinishedを送信
しなければなりません (MUST)。特定の応答に対するクライアントのすべての
メッセージは、他種のメッセージを挟まず、ワイヤ上で連続して現れなければ
なりません (MUST)。
"post_handshake_auth"拡張を送信していないにもかかわらず
CertificateRequestメッセージを受信したクライアントは、
"unexpected_message" fatal alertを送信しなければなりません (MUST)。
注: クライアント認証にはユーザーへのプロンプトが関与する可能性があるため、
サーバーは、CertificateRequestの送信から応答の受信までの間に任意の数の
他のメッセージを受信することを含め、ある程度の遅延に備えなければなりません
(MUST)。加えて、複数のCertificateRequestを短い間隔で受信したクライアントは、
受信した順序とは異なる順序で応答してもよいです (MAY)
（certificate_request_context値により、サーバーは応答を曖昧さなく区別できます）。
4.6.3. Key and Initialization Vector Update
KeyUpdateハンドシェイクメッセージは、送信者が自身の送信用暗号鍵を更新
していることを示すために使用されます。このメッセージは、Finished
メッセージを送信した後であれば、どちらのピアからも送信できます。
Finishedメッセージを受信する前にKeyUpdateメッセージを受信した実装は、
"unexpected_message"アラートで接続を終了しなければなりません (MUST)。
KeyUpdateメッセージを送信した後、送信者は、Section 7.2で説明される
ように計算された次世代の鍵を使用して、すべてのトラフィックを送信しなければ
なりません (SHALL)。KeyUpdateを受信すると、受信者は自身の受信用鍵を更新
しなければなりません (MUST)。
enum {
update_not_requested(0), update_requested(1), (255)
} KeyUpdateRequest;
struct {
KeyUpdateRequest request_update;
} KeyUpdate;
request_update: KeyUpdateの受信者が自身のKeyUpdateで応答すべきかどうかを
示します。実装が他の任意の値を受信した場合、"illegal_parameter"
アラートで接続を終了しなければなりません (MUST)。
request_updateフィールドが"update_requested"に設定されている場合、受信者は
次のApplication Dataレコードを送信する前に、request_updateを
"update_not_requested"に設定した自身のKeyUpdateを送信しなければなりません
(MUST)。この機構により、どちらの側も接続全体の更新を強制できますが、
サイレントである間に複数のKeyUpdateを受信した実装は、単一の更新で応答する
Rescorla Standards Track [Page 76]
RFC 8446 TLS 2018年8月
複数のKeyUpdateを受信した実装は、単一の更新で応答することになります。
実装は、request_updateを"update_requested"に設定したKeyUpdateを送信してから
ピアのKeyUpdateを受信するまでの間に、任意の数のメッセージを受信する
可能性があることに注意してください。これは、それらのメッセージがすでに
転送中である可能性があるためです。ただし、送信用鍵と受信用鍵は独立した
traffic secretから導出されるため、receive traffic secretを保持しても、
送信者が鍵を変更する前に送信されたデータの前方秘匿性を脅かすことは
ありません。
実装が独立に、request_updateを"update_requested"に設定した自身の
KeyUpdateを送信し、それらが転送中に交差した場合、それぞれの側も応答を
送信することになり、その結果、それぞれの側は2世代分増分します。
送信者と受信者の両方は、自身のKeyUpdateメッセージを古い鍵で暗号化
しなければなりません (MUST)。さらに、両側は、新しい鍵で暗号化された
メッセージを受け入れる前に、古い鍵を持つKeyUpdateが受信されることを
強制しなければなりません (MUST)。これを行わないと、メッセージ切り詰め
攻撃を許す可能性があります。
5. Record Protocol
TLS record protocolは、送信されるメッセージを受け取り、データを扱いやすい
ブロックに断片化し、レコードを保護し、その結果を送信します。受信された
データは検証され、復号され、再構成され、その後上位レベルのクライアントへ
渡されます。
TLSレコードには型があり、これにより複数の上位レベルプロトコルを同じ
レコード層上で多重化できます。本文書は4つのcontent type、すなわち
handshake、application_data、alert、およびchange_cipher_specを規定します。
change_cipher_specレコードは互換性目的でのみ使用されます
（Appendix D.4を参照）。
実装は、最初のClientHelloメッセージが送信または受信された後、かつピアの
Finishedメッセージが受信される前であればいつでも、単一バイト値0x01から
なるchange_cipher_spec型の暗号化されていないレコードを受信してもよく、
それをそれ以上処理せずに単に破棄しなければなりません (MUST)。このレコードは、
実装が保護されたレコードを期待しているハンドシェイクの時点に現れる可能性が
あるため、レコードの保護解除を試みる前にこの条件を検出する必要があることに
注意してください。他のchange_cipher_spec値を受信した実装、または保護された
change_cipher_specレコードを受信した実装は、"unexpected_message"アラートで
ハンドシェイクを中止しなければなりません (MUST)。実装が、最初のClientHello
メッセージの前、またはピアのFinishedメッセージの後に受信された
change_cipher_specレコードを検出した場合、それは予期しないレコード型として
扱われなければなりません (MUST)（ただし、ステートレスサーバーはこれらの
ケースを許可されたケースと区別できない場合があります）。
Rescorla Standards Track [Page 77]
RFC 8446 TLS 2018年8月
実装は、何らかの拡張によって交渉されない限り、本文書で定義されていない
レコード型を送信してはなりません (MUST NOT)。TLS実装が予期しない
レコード型を受信した場合、"unexpected_message"アラートで接続を終了しなければ
なりません (MUST)。新しいrecord content type値は、Section 11で説明される
ように、TLS ContentTypeレジストリでIANAにより割り当てられます。
5.1. Record Layer
レコード層は、情報ブロックを2^14バイト以下のチャンクでデータを搬送する
TLSPlaintextレコードへ断片化します。メッセージ境界は、基礎となる
ContentTypeに応じて異なる方法で処理されます。将来の任意のcontent typeは、
適切な規則を指定しなければなりません (MUST)。これらの規則は、TLS 1.2で
強制されていたものより厳格であることに注意してください。
Handshakeメッセージは、次の条件を満たす限り、単一のTLSPlaintextレコードに
結合してもよく (MAY)、または複数のレコードに断片化してもよいです。
- Handshakeメッセージは、他のレコード型と交錯してはなりません (MUST NOT)。
すなわち、handshakeメッセージが2つ以上のレコードに分割される場合、
その間に他のレコードが存在してはなりません (MUST NOT)。
- Handshakeメッセージは鍵変更をまたいではなりません (MUST NOT)。
実装は、鍵変更の直前にあるすべてのメッセージがレコード境界に整列して
いることを検証しなければなりません (MUST)。そうでない場合、実装は
"unexpected_message"アラートで接続を終了しなければなりません (MUST)。
ClientHello、EndOfEarlyData、ServerHello、Finished、およびKeyUpdate
メッセージは鍵変更の直前に現れ得るため、実装はこれらのメッセージを
レコード境界に整列させて送信しなければなりません (MUST)。
実装は、たとえそれらの断片がパディングを含んでいても、Handshake型の
長さ0の断片を送信してはなりません (MUST NOT)。
Alertメッセージ（Section 6）はレコードをまたいで断片化されてはならず
(MUST NOT)、複数のalertメッセージは単一のTLSPlaintextレコードに結合されては
なりません (MUST NOT)。言い換えると、Alert型を持つレコードは正確に1つの
メッセージを含まなければなりません (MUST)。
Application Dataメッセージは、TLSにとってopaqueなデータを含みます。
Application Dataメッセージは常に保護されます。Application Dataの長さ0の
断片は、トラフィック解析への対抗策として有用である可能性があるため、
送信してもよいです (MAY)。Application Data断片は複数のレコードに分割
されてもよく、単一のレコードに結合されてもよいです (MAY)。
Rescorla Standards Track [Page 78]
RFC 8446 TLS 2018年8月
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: 含まれるfragmentを処理するために使用される上位レベルプロトコル。
legacy_record_version: 初期ClientHello（すなわち、HelloRetryRequest後に
生成されたものではないもの）以外で、TLS 1.3実装によって生成される
すべてのレコードについて0x0303に設定されなければなりません (MUST)。
初期ClientHelloでは、互換性目的で0x0301であってもよいです (MAY)。
このフィールドは非推奨であり、すべての目的で無視されなければなり
ません (MUST)。以前のTLSバージョンは、状況によってこのフィールドで
他の値を使用していました。
length: 後続のTLSPlaintext.fragmentの長さ（バイト単位）。長さは
2^14バイトを超えてはなりません (MUST NOT)。この長さを超えるレコードを
受信したエンドポイントは、"record_overflow"アラートで接続を終了しなければ
なりません (MUST)。
fragment: 送信されるデータ。この値は透過的であり、typeフィールドで
指定される上位レベルプロトコルによって扱われる独立したブロックとして
処理されます。
本文書は、バージョン0x0304を使用するTLS 1.3を説明します。このバージョン値は
歴史的なものであり、TLS 1.0での0x0301およびSSL 3.0での0x0300の使用に由来
します。後方互換性を最大化するため、初期ClientHelloを含むレコードは
（TLS 1.0を反映して）バージョン0x0301を持つべきであり (SHOULD)、
2回目のClientHelloまたはServerHelloを含むレコードは（TLS 1.2を反映して）
バージョン0x0303を持たなければなりません (MUST)。以前のTLSバージョンを
交渉する場合、エンドポイントはAppendix Dで提供される手順および
要件に従います。
Rescorla Standards Track [Page 79]
RFC 8446 TLS 2018年8月
レコード保護がまだ開始されていない場合、TLSPlaintext構造はワイヤ上へ直接
書き込まれます。レコード保護が開始されると、TLSPlaintextレコードは次の
セクションで説明されるように保護され、送信されます。Application Data
レコードは保護されずにワイヤへ書き込まれてはならないことに注意してください
(MUST NOT)（詳細はSection 2を参照）。
5.2. Record Payload Protection
レコード保護関数は、TLSPlaintext構造をTLSCiphertext構造へ変換します。
保護解除関数はその処理を逆に行います。TLS 1.3では、以前のTLSバージョンとは
異なり、すべての暗号は"Authenticated Encryption with Associated Data"
(AEAD) [RFC5116]としてモデル化されます。AEAD関数は、平文を認証済み
暗号文へ、またその逆へ変換する、統合された暗号化および認証操作を提供します。
各暗号化レコードは、平文ヘッダーに続いて暗号化された本体で構成され、
その本体自体はtypeおよび任意のpaddingを含みます。
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: TLSPlaintext.fragment値。handshakeまたはalertメッセージのバイト
エンコード、または送信するアプリケーションデータの生バイトを含みます。
type: レコードのcontent typeを含むTLSPlaintext.type値。
zeros: 任意長の0値バイト列が、typeフィールドの後のcleartextに現れても
よいです。これにより、合計がレコードサイズ制限内に収まる限り、送信者は
任意のTLSレコードを選択した量だけパディングできます。詳細については
Section 5.4を参照してください。
Rescorla Standards Track [Page 80]
RFC 8446 TLS 2018年8月
opaque_type: TLSCiphertextレコードの外側のopaque_typeフィールドは、以前の
TLSバージョンを解析することに慣れたmiddleboxとの外向き互換性のため、
常に値23 (application_data) に設定されます。レコードの実際のcontent typeは、
復号後のTLSInnerPlaintext.typeにあります。
legacy_record_version: legacy_record_versionフィールドは常に0x0303です。
TLS 1.3 TLSCiphertextはTLS 1.3が交渉された後でなければ生成されないため、
他の値が受信される可能性に関する歴史的な互換性上の懸念はありません。
ClientHelloおよびServerHelloメッセージを含むhandshake protocolが
プロトコルバージョンを認証するため、この値は冗長であることに注意
してください。
length: 後続のTLSCiphertext.encrypted_recordの長さ（バイト単位）。
これはcontentとpaddingの長さの合計に、inner content typeのための1を加え、
さらにAEADアルゴリズムによって追加される任意の拡張を加えたものです。
長さは2^14 + 256バイトを超えてはなりません (MUST NOT)。この長さを超える
レコードを受信したエンドポイントは、"record_overflow"アラートで接続を
終了しなければなりません (MUST)。
encrypted_record: シリアライズされたTLSInnerPlaintext構造のAEAD暗号化形式。
AEADアルゴリズムは、[RFC5116]のSection 2.1で説明されるように、
単一の鍵、nonce、平文、および認証確認に含められる"additional data"を
入力として取ります。鍵はclient_write_keyまたはserver_write_keyであり、
nonceはシーケンス番号とclient_write_ivまたはserver_write_ivから導出され
（Section 5.3を参照）、additional data入力はレコードヘッダーです。
すなわち、
additional_data = TLSCiphertext.opaque_type ||
TLSCiphertext.legacy_record_version ||
TLSCiphertext.length
AEADアルゴリズムへの平文入力は、エンコードされたTLSInnerPlaintext構造です。
traffic keyの導出はSection 7.3で定義されます。
AEAD出力は、AEAD暗号化操作からのciphertext出力で構成されます。
TLSInnerPlaintext.typeおよび送信者によって供給される任意のpaddingを含む
ため、平文の長さは対応するTLSPlaintext.lengthより大きくなります。
AEAD出力の長さは一般に平文より大きくなりますが、その差はAEADアルゴリズムに
よって異なります。
Rescorla Standards Track [Page 81]
RFC 8446 TLS 2018年8月
暗号がpaddingを組み込む可能性があるため、オーバーヘッド量は平文の長さに
よって異なる可能性があります。記号的には次のとおりです。
AEADEncrypted =
AEAD-Encrypt(write_key, nonce, additional_data, plaintext)
TLSCiphertextのencrypted_recordフィールドはAEADEncryptedに設定されます。
復号および検証のため、暗号は鍵、nonce、additional data、および
AEADEncrypted値を入力として取ります。出力は平文、または復号が失敗したことを
示すエラーのいずれかです。別個の完全性確認はありません。記号的には次の
とおりです。
plaintext of encrypted_record =
AEAD-Decrypt(peer_write_key, nonce,
additional_data, AEADEncrypted)
復号が失敗した場合、受信者は"bad_record_mac"アラートで接続を終了しなければ
なりません (MUST)。
TLS 1.3で使用されるAEADアルゴリズムは、255オクテットを超える拡張を生成しては
なりません (MUST NOT)。ピアからTLSCiphertext.lengthが2^14 + 256オクテットを
超えるレコードを受信したエンドポイントは、"record_overflow"アラートで接続を
終了しなければなりません (MUST)。この制限は、TLSInnerPlaintextの最大長
2^14オクテット + ContentTypeのための1オクテット + 最大AEAD拡張255オクテット
から導出されます。
5.3. Per-Record Nonce
64ビットのシーケンス番号は、レコードの読み取りと書き込みのために別々に
維持されます。適切なシーケンス番号は、各レコードを読み取った後または
書き込んだ後に1ずつ増分されます。各シーケンス番号は、接続の開始時および
鍵が変更されるたびに0に設定されます。特定のtraffic keyの下で送信される
最初のレコードは、シーケンス番号0を使用しなければなりません (MUST)。
シーケンス番号のサイズは64ビットであるため、ラップすべきではありません。
TLS実装がシーケンス番号をラップする必要がある場合、再鍵化
（Section 4.6.3）するか、接続を終了しなければなりません (MUST)。
Rescorla Standards Track [Page 82]
RFC 8446 TLS 2018年8月
各AEADアルゴリズムは、per-record nonceについて、入力のN_MINバイトから
N_MAXバイトまでの可能な長さの範囲を指定します [RFC5116]。TLSの
per-record nonceの長さ (iv_length) は、AEADアルゴリズムについて8バイトと
N_MINのうち大きい方に設定されます（[RFC5116], Section 4を参照）。
N_MAXが8バイト未満であるAEADアルゴリズムは、TLSで使用してはなりません
(MUST NOT)。AEAD構成のためのper-record nonceは、次のように形成されます。
1. 64ビットのレコードシーケンス番号はネットワークバイトオーダーで
エンコードされ、iv_lengthまで左側にゼロでパディングされます。
2. パディングされたシーケンス番号は、役割に応じて、静的な
client_write_ivまたはserver_write_ivのいずれかとXORされます。
結果として得られる量（長さiv_length）は、per-record nonceとして使用されます。
注: これは、部分的に明示的なnonceを指定していたTLS 1.2の構成とは異なります。
5.4. Record Padding
すべての暗号化TLSレコードは、TLSCiphertextのサイズを膨らませるために
パディングできます。これにより、送信者はトラフィックのサイズを観測者から
隠すことができます。
TLSCiphertextレコードを生成するとき、実装はパディングを選択してもよいです
(MAY)。パディングされていないレコードは、単にpadding lengthが0のレコードです。
Paddingは、暗号化の前にContentTypeフィールドへ追加される0値バイトの文字列です。
実装は、暗号化の前にpadding octetをすべてゼロに設定しなければなりません
(MUST)。
送信者が望む場合、Application Dataレコードは長さ0の
TLSInnerPlaintext.contentを含んでもよいです。これにより、活動の有無が
機微である可能性があるコンテキストで、もっともらしいサイズのカバー
トラフィックを生成できます。実装は、長さ0のTLSInnerPlaintext.contentを持つ
HandshakeおよびAlertレコードを送信してはなりません (MUST NOT)。そのような
メッセージを受信した場合、受信側実装は"unexpected_message"アラートで接続を
終了しなければなりません (MUST)。
Rescorla Standards Track [Page 83]
RFC 8446 TLS 2018年8月
送信されたpaddingは、レコード保護機構によって自動的に検証されます。
TLSCiphertext.encrypted_recordの復号に成功すると、受信側実装は、非ゼロ
オクテットを見つけるまでフィールドを末尾から先頭へ向けてスキャンします。
この非ゼロオクテットがメッセージのcontent typeです。このpadding方式は、
新しいcontent typeを導入することなく、任意の暗号化TLSレコードを任意の
サイズ（0からTLSレコードサイズ制限まで）でパディングできるため選択されました。
この設計はまた、すべてゼロのpadding octetを強制し、paddingエラーの迅速な
検出を可能にします。
実装は、AEAD復号から返されたcleartextにスキャンを制限しなければなりません
(MUST)。受信側実装がcleartext内に非ゼロオクテットを見つけない場合、
"unexpected_message"アラートで接続を終了しなければなりません (MUST)。
paddingの存在は、全体のレコードサイズ制限を変更しません。完全にエンコード
されたTLSInnerPlaintextは、2^14 + 1オクテットを超えてはなりません (MUST NOT)。
たとえば[RFC8449]のrecord_size_limit拡張によってmaximum fragment lengthが
削減される場合、削減された制限はcontent typeおよびpaddingを含む完全な平文に
適用されます。
いつ、どれだけパディングするかを示唆するpaddingポリシーの選択は複雑な
トピックであり、本仕様の範囲外です。TLS上のアプリケーション層プロトコルが
独自のpaddingを持つ場合、Application Data TLSレコードをアプリケーション層内で
パディングする方が望ましいかもしれません。ただし、暗号化されたHandshakeまたは
Alertレコードのpaddingは、依然としてTLS層で処理されなければなりません。
後続の文書は、padding選択アルゴリズムを定義したり、TLS拡張またはその他の
手段を通じてpaddingポリシー要求機構を定義したりする可能性があります。
5.5. Limits on Key Usage
特定の鍵集合の下で安全に暗号化できる平文の量には、暗号学的な制限が
あります。[AEAD-LIMITS]は、基礎となるプリミティブ（AESまたはChaCha20）に
弱点がないという仮定の下で、これらの制限を分析しています。実装は、
これらの制限に達する前に、Section 4.6.3で説明されるようにkey updateを
行うべきです (SHOULD)。
AES-GCMについては、Authenticated Encryption (AE) セキュリティに対して
約2^-57の安全余裕を保ちながら、特定の接続上で最大2^24.5個のフルサイズ
レコード（約2400万）を暗号化できます。ChaCha20/Poly1305については、
安全制限に達する前にレコードシーケンス番号がラップすることになります。
Rescorla Standards Track [Page 84]
RFC 8446 TLS 2018年8月
6. Alert Protocol
TLSは、閉鎖情報およびエラーを示すためにAlert content typeを提供します。
他のメッセージと同様、alertメッセージは現在の接続状態によって指定される
とおりに暗号化されます。
Alertメッセージは、アラートの説明、および以前のTLSバージョンでメッセージの
重大度レベルを伝えていたレガシーフィールドを伝達します。アラートは
2つのクラス、すなわちclosure alertとerror alertに分けられます。TLS 1.3では、
重大度は送信されるアラートの種類に暗黙的に含まれ、"level"フィールドは安全に
無視できます。"close_notify"アラートは、接続の一方向の秩序だった閉鎖を示す
ために使用されます。そのようなアラートを受信すると、TLS実装はアプリケーションへ
データ終端を示すべきです (SHOULD)。
Error alertは、接続の中断的な閉鎖を示します（Section 6.2を参照）。
error alertを受信すると、TLS実装はアプリケーションへエラーを示すべきであり
(SHOULD)、その接続上でそれ以上のデータの送受信を許可してはなりません
(MUST NOT)。サーバーおよびクライアントは、失敗した接続で確立されたsecret値
および鍵を忘れなければなりません (MUST)。ただし、セッションチケットに関連する
PSKは例外であり、可能であれば破棄すべきです (SHOULD)。
Section 6.2に列挙されるすべてのアラートは、AlertLevel=fatalで送信されなければ
ならず (MUST)、メッセージ内のAlertLevelにかかわらず、受信時にはerror alertとして
扱われなければなりません (MUST)。未知のAlert型はerror alertとして扱われなければ
なりません (MUST)。
注: TLSは、メッセージの解析に失敗した場合に使用する2つの汎用アラート
（Section 6を参照）を定義します。構文に従って解析できないメッセージ
（例: メッセージ境界を超える長さを持つ、または範囲外の長さを含む）を
受信したピアは、"decode_error"アラートで接続を終了しなければなりません
(MUST)。構文的には正しいが意味的に無効なメッセージ（例: p - 1のDHE共有、
または無効なenum）を受信したピアは、"illegal_parameter"アラートで接続を
終了しなければなりません (MUST)。
Rescorla Standards Track [Page 85]
RFC 8446 TLS 2018年8月
enum { warning(1), fatal(2), (255) } AlertLevel;
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
record_overflow(22),
handshake_failure(40),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
protocol_version(70),
insufficient_security(71),
internal_error(80),
inappropriate_fallback(86),
user_canceled(90),
missing_extension(109),
unsupported_extension(110),
unrecognized_name(112),
bad_certificate_status_response(113),
unknown_psk_identity(115),
certificate_required(116),
no_application_protocol(120),
(255)
} AlertDescription;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
Rescorla Standards Track [Page 86]
RFC 8446 TLS 2018年8月
6.1. Closure Alerts
切り詰め攻撃を避けるため、クライアントとサーバーは接続が終了している
という知識を共有しなければなりません。
close_notify: このアラートは、送信者がこの接続上でもうメッセージを
送信しないことを受信者に通知します。closure alertを受信した後に受信された
任意のデータは無視されなければなりません (MUST)。
user_canceled: このアラートは、送信者がプロトコル失敗とは無関係な何らかの
理由でハンドシェイクをキャンセルしていることを受信者に通知します。
ハンドシェイク完了後にユーザーが操作をキャンセルする場合は、"close_notify"を
送信して接続を閉じるだけの方がより適切です。このアラートの後には
"close_notify"が続くべきです (SHOULD)。このアラートは一般に
AlertLevel=warningを持ちます。
いずれの当事者も、"close_notify"アラートを送信することで、接続の書き込み側の
closeを開始してもよいです (MAY)。closure alertを受信した後に受信された
任意のデータは無視されなければなりません (MUST)。"close_notify"より前に
トランスポートレベルのcloseを受信した場合、受信者は、送信されたすべての
データが受信されたことを知ることができません。
各当事者は、すでに何らかのerror alertを送信していない限り、接続の書き込み側を
閉じる前に"close_notify"アラートを送信しなければなりません (MUST)。
これは接続の読み取り側には影響しません。これはTLS 1.3より前のTLSバージョン
からの変更であることに注意してください。以前は、実装が"close_notify"に
反応して保留中の書き込みを破棄し、自身の即時の"close_notify"アラートを
送信することが要求されていました。その以前の要件は、読み取り側で切り詰めを
引き起こす可能性がありました。どちらの当事者も、接続の読み取り側を閉じる前に
"close_notify"アラートの受信を待つ必要はありませんが、そうすると切り詰めの
可能性が生じます。
TLSを使用するアプリケーションプロトコルが、TLS接続が閉じられた後に基礎となる
トランスポート上で任意のデータを搬送できることを規定している場合、TLS実装は
アプリケーション層へデータ終端を示す前に"close_notify"アラートを受信しなければ
なりません (MUST)。本標準のどの部分も、TLSの使用プロファイルが、接続がいつ
開かれるかまたは閉じられるかを含め、そのデータトランスポートを管理する方法を
指示するものと解釈されるべきではありません。
注: 接続の書き込み側を閉じることは、トランスポートを破壊する前に保留中の
データを確実に配送すると仮定されています。
Rescorla Standards Track [Page 87]
RFC 8446 TLS 2018年8月
6.2. Error Alerts
TLSにおけるエラー処理は非常に単純です。エラーが検出されると、検出した
当事者はピアへメッセージを送信します。fatal alertメッセージの送信または
受信時、両当事者は直ちに接続を閉じなければなりません (MUST)。
実装がfatal error条件に遭遇したときは常に、適切なfatal alertを送信すべきであり
(SHOULD)、追加データを送受信せずに接続を閉じなければなりません (MUST)。
本仕様の残りで、特定のアラートなしに"terminate the connection"および
"abort the handshake"という句が使用される場合、実装が下記の説明で示される
アラートを送信すべきであることを意味します (SHOULD)。"terminate the connection
with an X alert"および"abort the handshake with an X alert"という句は、実装が
何らかのアラートを送信する場合、アラートXを送信しなければならないことを
意味します (MUST)。本セクションで以下に定義されるすべてのアラート、および
すべての未知のアラートは、TLS 1.3時点で普遍的にfatalと見なされます
（Section 6を参照）。実装は、アラートの送受信のログ記録を容易にする
方法を提供すべきです (SHOULD)。
次のerror alertが定義されます。
unexpected_message: 不適切なメッセージ（例: 誤ったhandshakeメッセージ、
早すぎるApplication Dataなど）が受信されました。このアラートは、適切な
実装間の通信では決して観測されるべきではありません。
bad_record_mac: 保護解除できないレコードを受信した場合に、このアラートが
返されます。AEADアルゴリズムは復号と検証を結合しており、またサイド
チャネル攻撃を避けるため、このアラートはすべての保護解除失敗に使用されます。
このアラートは、ネットワークでメッセージが破損した場合を除き、適切な実装間の
通信では決して観測されるべきではありません。
record_overflow: 長さが2^14 + 256バイトを超えるTLSCiphertextレコードを受信したか、
または2^14バイト（またはその他の交渉された制限）を超えるTLSPlaintext
レコードへ復号されたレコードを受信しました。このアラートは、ネットワークで
メッセージが破損した場合を除き、適切な実装間の通信では決して観測されるべき
ではありません。
handshake_failure: "handshake_failure"アラートメッセージの受信は、利用可能な
選択肢を踏まえて、送信者が受け入れ可能なセキュリティパラメーター集合を
交渉できなかったことを示します。
bad_certificate: 証明書が破損していた、正しく検証されない署名を含んでいた、
などです。
Rescorla Standards Track [Page 88]
RFC 8446 TLS 2018年8月
unsupported_certificate: 証明書がサポートされていない型でした。
certificate_revoked: 証明書が署名者によって失効されていました。
certificate_expired: 証明書が期限切れである、または現在有効ではありません。
certificate_unknown: 証明書の処理中に、その他の（未指定の）問題が発生し、
それにより証明書が受け入れ不能になりました。
illegal_parameter: ハンドシェイク内のフィールドが不正である、または他の
フィールドと一貫していませんでした。このアラートは、形式的なプロトコル
構文には従っているが、それ以外の点で不正なエラーに使用されます。
unknown_ca: 有効な証明書チェーンまたは部分チェーンが受信されましたが、
CA証明書を見つけられない、または既知のトラストアンカーと照合できないため、
証明書は受け入れられませんでした。
access_denied: 有効な証明書またはPSKが受信されましたが、アクセス制御が適用
されたとき、送信者は交渉を続行しないことを決定しました。
decode_error: 何らかのフィールドが指定範囲外である、またはメッセージの長さが
不正であるため、メッセージをデコードできませんでした。このアラートは、
メッセージが形式的なプロトコル構文に従っていないエラーに使用されます。
このアラートは、ネットワークでメッセージが破損した場合を除き、適切な実装間の
通信では決して観測されるべきではありません。
decrypt_error: 署名を正しく検証できない、FinishedメッセージまたはPSK binderを
検証できないことを含め、ハンドシェイク（レコード層ではない）の暗号操作が
失敗しました。
protocol_version: ピアが交渉しようとしたプロトコルバージョンは認識されていますが、
サポートされていません（Appendix Dを参照）。
insufficient_security: サーバーがクライアントによってサポートされるものより
安全なパラメーターを要求するために交渉が失敗した場合に、
"handshake_failure"の代わりに返されます。
internal_error: ピアまたはプロトコルの正しさとは無関係な内部エラー
（メモリ割り当て失敗など）により、続行できません。
inappropriate_fallback: クライアントからの無効な接続再試行に応答して、サーバーに
よって送信されます（[RFC7507]を参照）。
Rescorla Standards Track [Page 89]
RFC 8446 TLS 2018年8月
missing_extension: 提示されたTLSバージョンまたは他の交渉されたパラメーターに
ついて送信が必須である拡張を含まないhandshakeメッセージを受信した
エンドポイントによって送信されます。
unsupported_extension: 特定のhandshakeメッセージに含めることが禁止されている
ことが知られている拡張を含む任意のhandshakeメッセージを受信した
エンドポイント、または対応するClientHelloもしくはCertificateRequestで
先に提示されていない任意の拡張をServerHelloまたはCertificateに含めた
エンドポイントによって送信されます。
unrecognized_name: クライアントが"server_name"拡張を介して提供した名前で識別
されるサーバーが存在しない場合に、サーバーによって送信されます
（[RFC6066]を参照）。
bad_certificate_status_response: "status_request"拡張を介して、サーバーによって
無効または受け入れ不能なOCSP応答が提供された場合に、クライアントによって
送信されます（[RFC6066]を参照）。
unknown_psk_identity: PSK鍵確立が望まれるが、受け入れ可能なPSKアイデンティティが
クライアントから提供されない場合に、サーバーによって送信されます。
このアラートの送信は任意です (OPTIONAL)。サーバーは代わりに、単に無効な
PSKアイデンティティを示すため、"decrypt_error"アラートを送信することを
選択してもよいです (MAY)。
certificate_required: クライアント証明書が望まれるが、クライアントによって
提供されなかった場合に、サーバーによって送信されます。
no_application_protocol: クライアントの"application_layer_protocol_negotiation"拡張が、
サーバーがサポートしないプロトコルのみを広告する場合に、サーバーによって
送信されます（[RFC7301]を参照）。
新しいAlert値は、Section 11で説明されるようにIANAによって割り当てられます。
7. Cryptographic Computations
TLSハンドシェイクは1つ以上の入力secretを確立し、それらは以下で詳述される
ように、実際に動作する鍵材料を作成するために結合されます。鍵導出処理は、
入力secretとハンドシェイクトランスクリプトの両方を組み込みます。Hello
メッセージからのランダム値がハンドシェイクトランスクリプトに含まれるため、
同じ入力secretが使用される場合（同じPSKが複数の接続で使用される場合など）
であっても、任意のハンドシェイクは異なるtraffic secretを持つことに注意して
ください。
Rescorla Standards Track [Page 90]
RFC 8446 TLS 2018年8月
7.1. Key Schedule
鍵導出処理は、HKDF [RFC5869]について定義されるHKDF-Extractおよび
HKDF-Expand関数、ならびに以下で定義される関数を利用します。
HKDF-Expand-Label(Secret, Label, Context, Length) =
HKDF-Expand(Secret, HkdfLabel, Length)
ここで、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)
Transcript-HashおよびHKDFで使用されるHash関数は、暗号スイートの
ハッシュアルゴリズムです。Hash.lengthは、その出力長（バイト単位）です。
Messagesは、示されたhandshakeメッセージの連結であり、handshakeメッセージ
種別および長さフィールドを含みますが、レコード層ヘッダーは含みません。
場合によっては、長さ0のContext（""で示される）がHKDF-Expand-Labelへ渡される
ことに注意してください。本文書で指定されるラベルはすべてASCII文字列であり、
末尾のNULバイトを含みません。
注: 一般的なハッシュ関数では、12文字を超える任意のラベルは、計算のために
ハッシュ関数の追加反復を必要とします。本仕様のラベルはすべて、この制限内に
収まるように選択されています。
Rescorla Standards Track [Page 91]
RFC 8446 TLS 2018年8月
鍵は、HKDF-ExtractおよびDerive-Secret関数を使用して2つの入力secretから
導出されます。新しいsecretを追加する一般的なパターンは、Saltを現在の
secret状態とし、Input Keying Material (IKM) を追加される新しいsecretとして、
HKDF-Extractを使用することです。このTLS 1.3のバージョンでは、2つの入力secretは
次のとおりです。
- PSK（外部で確立された事前共有鍵、または以前の接続からの
resumption_master_secret値から導出されたもの）
- (EC)DHE shared secret（Section 7.4）
これにより、下の図に示される完全な鍵導出スケジュールが生成されます。
この図では、次の書式規約が適用されます。
- HKDF-Extractは、Salt引数を上から、IKM引数を左から取り、出力を下へ、
出力名を右に示すように描かれています。
- Derive-SecretのSecret引数は、入力矢印によって示されます。たとえば、
Early Secretはclient_early_traffic_secretを生成するためのSecretです。
- "0"は、Hash.lengthバイトがゼロに設定された文字列を示します。
Rescorla Standards Track [Page 92]
RFC 8446 TLS 2018年8月
0
|
v
PSK -> HKDF-Extract = Early Secret
|
+-----> Derive-Secret(., "ext binder" | "res binder", "")
| = binder_key
|
+-----> Derive-Secret(., "c e traffic", ClientHello)
| = client_early_traffic_secret
|
+-----> Derive-Secret(., "e exp master", ClientHello)
| = early_exporter_master_secret
v
Derive-Secret(., "derived", "")
|
v
(EC)DHE -> HKDF-Extract = Handshake Secret
|
+-----> Derive-Secret(., "c hs traffic",
| ClientHello...ServerHello)
| = client_handshake_traffic_secret
|
+-----> Derive-Secret(., "s hs traffic",
| ClientHello...ServerHello)
| = server_handshake_traffic_secret
v
Derive-Secret(., "derived", "")
|
v
0 -> HKDF-Extract = Master Secret
|
+-----> Derive-Secret(., "c ap traffic",
| ClientHello...server Finished)
| = client_application_traffic_secret_0
|
+-----> Derive-Secret(., "s ap traffic",
| ClientHello...server Finished)
| = server_application_traffic_secret_0
|
+-----> Derive-Secret(., "exp master",
| ClientHello...server Finished)
| = exporter_master_secret
|
+-----> Derive-Secret(., "res master",
ClientHello...client Finished)
= resumption_master_secret
Rescorla Standards Track [Page 93]
RFC 8446 TLS 2018年8月
ここでの一般的なパターンは、図の左側に示されるsecretはコンテキストを持たない
生のエントロピーにすぎない一方、右側のsecretはHandshake Contextを含むため、
追加のコンテキストなしに作業鍵を導出するために使用できるというものです。
同じsecretであっても、Derive-Secretへの異なる呼び出しは異なるMessages引数を
取る可能性があることに注意してください。0-RTT交換では、Derive-Secretは
4つの異なるトランスクリプトで呼び出されます。1-RTTのみの交換では、
3つの異なるトランスクリプトで呼び出されます。
特定のsecretが利用できない場合、Hash.lengthバイトがゼロに設定された文字列から
なる0値が使用されます。これはラウンドをスキップすることを意味しないことに
注意してください。したがって、PSKが使用されない場合でも、Early Secretは依然として
HKDF-Extract(0, 0)になります。binder_keyの計算について、ラベルは外部PSK
（TLSの外部でプロビジョニングされたもの）に対して"ext binder"であり、再開PSK
（以前のハンドシェイクのresumption master secretとしてプロビジョニングされた
もの）に対して"res binder"です。異なるラベルにより、一方の種類のPSKが他方に
置換されることを防ぎます。
サーバーが最終的にどのPSKを選択するかに応じて、複数の潜在的なEarly Secret値が
存在します。クライアントは各潜在的PSKについて1つを計算する必要があります。
PSKが選択されない場合、その後、ゼロPSKに対応するEarly Secretを計算する必要が
あります。
特定のsecretから導出されるすべての値が計算されたら、そのsecretは消去される
べきです (SHOULD)。
7.2. Updating Traffic Secrets
ハンドシェイクが完了すると、どちらの側もSection 4.6.3で定義される
KeyUpdateハンドシェイクメッセージを使用して、自身の送信用traffic keyを更新
できます。次世代のtraffic keyは、本セクションで説明されるように
client_/server_application_traffic_secret_Nから
client_/server_application_traffic_secret_N+1を生成し、その後Section 7.3で
説明されるようにtraffic keyを再導出することで計算されます。
次世代のapplication_traffic_secretは次のように計算されます。
application_traffic_secret_N+1 =
HKDF-Expand-Label(application_traffic_secret_N,
"traffic upd", "", Hash.length)
client_/server_application_traffic_secret_N+1およびその関連traffic keyが計算されたら、
実装はclient_/server_application_traffic_secret_Nおよびその関連traffic keyを削除
すべきです (SHOULD)。
Rescorla Standards Track [Page 94]
RFC 8446 TLS 2018年8月
7.3. Traffic Key Calculation
traffic keying materialは、次の入力値から生成されます。
- secret値
- 生成される特定の値を示すpurpose値
- 生成される鍵の長さ
traffic keying materialは、入力traffic secret値から次を使用して生成されます。
[sender]_write_key = HKDF-Expand-Label(Secret, "key", "", key_length)
[sender]_write_iv = HKDF-Expand-Label(Secret, "iv", "", iv_length)
[sender]は送信側を示します。各レコード型に対するSecretの値は下の表に
示されます。
+-------------------+---------------------------------------+
| Record Type | Secret |
+-------------------+---------------------------------------+
| 0-RTT Application | client_early_traffic_secret |
| | |
| Handshake | [sender]_handshake_traffic_secret |
| | |
| Application Data | [sender]_application_traffic_secret_N |
+-------------------+---------------------------------------+
基礎となるSecretが変化するたびに（例: handshakeからApplication Data鍵へ変更する
とき、またはkey update時）、すべてのtraffic keying materialが再計算されます。
7.4. (EC)DHE Shared Secret Calculation
7.4.1. Finite Field Diffie-Hellman
有限体グループについては、従来のDiffie-Hellman [DH76]計算が実行されます。
交渉された鍵 (Z) は、ビッグエンディアン形式でエンコードされ、素数のサイズまで
左側にゼロでパディングされることにより、バイト文字列へ変換されます。この
バイト文字列は、上で指定された鍵スケジュール内のshared secretとして使用されます。
この構成は、先頭のゼロを削除していた以前のTLSバージョンとは異なることに注意して
ください。
Rescorla Standards Track [Page 95]
RFC 8446 TLS 2018年8月
7.4.2. Elliptic Curve Diffie-Hellman
secp256r1、secp384r1、およびsecp521r1について、ECDH計算（パラメーターおよび
鍵生成、ならびにshared secret計算を含む）は、鍵導出関数 (KDF) として
identity mapを持つECKAS-DH1方式を使用して、[IEEE1363]に従って実行されます。
したがって、shared secretは、オクテット文字列として表されるECDH shared secret
楕円曲線点のx座標です。FE2OSP（Field Element to Octet String Conversion
Primitive）によって出力されるこのオクテット文字列（IEEE 1363用語で"Z"）は、
任意の特定の体について一定長を持つことに注意してください。このオクテット文字列内の
先頭ゼロは切り詰められてはなりません (MUST NOT)。
（identity KDFのこの使用は技術的な形式上のものです。全体像としては、TLSはこの
secretを他のsecretの計算以外に直接使用しないため、ECDHは非自明なKDFとともに
用いられます。）
X25519およびX448について、ECDH計算は次のとおりです。
- KeyShareEntry.key_exchange構造に入れる公開鍵は、適切な長さの秘密鍵
（scalar入力へ）および標準公開基点（u-coordinate point入力へ）にECDH
scalar multiplication関数を適用した結果です。
- ECDH shared secretは、秘密鍵（scalar入力へ）およびピアの公開鍵
（u-coordinate point入力へ）にECDH scalar multiplication関数を適用した結果です。
出力は処理なしでそのまま使用されます。
これらの曲線について、実装はDiffie-Hellman shared secretを計算するために
[RFC7748]で指定される手法を使用すべきです (SHOULD)。実装は、計算された
Diffie-Hellman shared secretがall-zero値であるかどうかを確認し、そうであれば
[RFC7748]のSection 6で説明されるように中止しなければなりません (MUST)。
実装者がこれらの楕円曲線の代替実装を使用する場合、[RFC7748]のSection 7で
指定される追加の確認を実行すべきです (SHOULD)。
Rescorla Standards Track [Page 96]
RFC 8446 TLS 2018年8月
7.5. Exporters
[RFC5705]は、TLS pseudorandom function (PRF) の観点からTLSのkeying material
exporterを定義します。本文書はPRFをHKDFで置き換えるため、新しい構成を必要と
します。exporterインターフェースは同じままです。
exporter値は次のように計算されます。
TLS-Exporter(label, context_value, key_length) =
HKDF-Expand-Label(Derive-Secret(Secret, label, ""),
"exporter", Hash(context_value), key_length)
ここで、Secretはearly_exporter_master_secretまたはexporter_master_secretの
いずれかです。実装は、アプリケーションによって明示的に指定されない限り、
exporter_master_secretを使用しなければなりません (MUST)。early_exporter_master_secretは、
0-RTTデータにexporterが必要な設定で使用するために定義されています。
early exporterのための別個のインターフェースが推奨されます (RECOMMENDED)。
これにより、exporter利用者が通常のexporterを望んでいるときに誤ってearly
exporterを使用したり、その逆を行ったりすることを避けられます。
contextが提供されない場合、context_valueは長さ0です。したがって、contextを
提供しないことは、空のcontextを提供することと同じ値を計算します。これは、
空のcontextがcontext不在とは異なる出力を生成していた以前のTLSバージョンからの
変更です。本文書の公開時点で、割り当て済みのexporter labelのうち、contextありと
contextなしの両方で使用されるものはありません。将来の仕様は、同じラベルで
空のcontextとcontextなしの両方を許可するexporterの使用を定義してはなりません
(MUST NOT)。exporterの新しい使用は、すべてのexporter計算でcontextを提供すべきです
(SHOULD)。ただし、その値は空であってもよいです。
exporter labelの形式に関する要件は、[RFC5705]のSection 4で定義されます。
Rescorla Standards Track [Page 97]
RFC 8446 TLS 2018年8月
8. 0-RTT and Anti-Replay
Section 2.3およびAppendix E.5で述べたように、TLSは0-RTTデータに
固有のリプレイ保護を提供しません。懸念すべき潜在的な脅威は2つあります。
- 0-RTTデータのフライトを単純に複製することによってリプレイ攻撃を仕掛ける
ネットワーク攻撃者。
- クライアントの再試行動作を利用して、サーバーがアプリケーションメッセージの
複数コピーを受信するように仕向けるネットワーク攻撃者。この脅威は、堅牢性を
重視するクライアントがネットワークエラーに対して要求の再試行を試みるため、
すでにある程度存在します。ただし、0-RTTは、グローバルに一貫したサーバー状態を
維持しない任意のサーバーシステムに対して追加の次元を加えます。具体的には、
サーバーシステムが複数のゾーンを持ち、ゾーンAのチケットがゾーンBで受け入れ
られない場合、攻撃者はA向けのClientHelloおよびearly dataをAとBの両方へ
複製できます。Aではデータが0-RTTで受け入れられますが、Bではサーバーが0-RTT
データを拒否し、代わりに完全なハンドシェイクを強制します。攻撃者がAからの
ServerHelloをブロックすると、クライアントはBとのハンドシェイクを完了し、
おそらく要求を再試行するため、サーバーシステム全体として重複が生じます。
1つ目の種類の攻撃は、0-RTTデータが高々1回だけ受け入れられることを保証するために
状態を共有することで防止できます。サーバーは、本セクションで説明される方法の
いずれか、または同等の手段を実装することにより、そのレベルのリプレイ安全性を
提供すべきです (SHOULD)。ただし、運用上の懸念により、すべてのデプロイメントが
そのレベルで状態を維持するわけではないことは理解されています。したがって、通常の
運用では、クライアントはサーバーがこれらの機構のうちどれを実際に実装しているかを
知ることができず、そのためリプレイされても安全であると判断するearly dataのみを
送信しなければなりません (MUST)。
リプレイの直接的な影響に加えて、通常は冪等と見なされる操作であっても、大量の
リプレイによって悪用され得る攻撃の種類があります（タイミング攻撃、リソース制限の
枯渇など、Appendix E.5で説明されるもの）。これらは、すべての0-RTT
ペイロードが限られた回数だけリプレイ可能であることを保証することで緩和できます。
サーバーは、その任意のインスタンス（マシン、スレッド、または関連する提供
インフラストラクチャ内の任意の他のエンティティ）が、同じ0-RTTハンドシェイクに対して
0-RTTを高々1回だけ受け入れることを保証しなければなりません (MUST)。これにより、
リプレイ数はデプロイメント内のサーバーインスタンス数に制限されます。そのような
保証は、最近受信したClientHelloからのデータをローカルに記録し、反復を拒否すること、
または同じかより強い保証を
Rescorla Standards Track [Page 98]
RFC 8446 TLS 2018年8月
提供する他の任意の方法によって達成できます。"at most once per server instance"
保証は最小要件です。サーバーは、実現可能な場合、0-RTTリプレイをさらに制限
すべきです (SHOULD)。
2つ目の種類の攻撃はTLS層では防止できず、任意のアプリケーションによって対処
されなければなりません (MUST)。何らかの再試行動作を実装するクライアントを持つ
任意のアプリケーションは、すでに何らかのリプレイ対策防御を実装する必要があることに
注意してください。
8.1. Single-Use Tickets
リプレイ対策防御の最も単純な形は、サーバーが各セッションチケットを1回だけ使用
可能にすることです。たとえば、サーバーは未使用の有効なすべてのチケットの
データベースを維持し、各チケットが使用されるとデータベースから削除できます。
未知のチケットが提供された場合、サーバーは完全なハンドシェイクへフォールバックします。
チケットが自己完結型ではなくデータベース鍵であり、対応するPSKが使用時に削除される
場合、PSKを使用して確立された接続は前方秘匿性を享受します。これは、PSKが
(EC)DHEなしで使用される場合のすべての0-RTTデータおよびPSK使用のセキュリティを
改善します。
この機構は、複数の分散サーバーを持つ環境でサーバーノード間でセッション
データベースを共有する必要があるため、自己暗号化チケットと比較して、PSK 0-RTT接続の
高い成功率を達成することが難しい場合があります。セッションデータベースとは異なり、
セッションチケットは一貫したストレージなしでもPSKベースのセッション確立を成功
させることができます。ただし、0-RTTが許可される場合、次のセクションで詳述される
ように、0-RTTデータのリプレイ対策のためには依然として一貫したストレージを必要とします。
8.2. Client Hello Recording
リプレイ対策の代替形式は、ClientHelloから導出された一意な値（一般にはrandom値
またはPSK binderのいずれか）を記録し、重複を拒否することです。すべてのClientHelloを
記録すると状態が無制限に増大しますが、サーバーは代わりに、特定の時間窓内の
ClientHelloを記録し、"obfuscated_ticket_age"を使用してチケットがその時間窓外で
再利用されないことを保証できます。
これを実装するため、ClientHelloを受信したとき、サーバーはまずSection 4.2.11で
説明されるようにPSK binderを検証します。その後、次のセクションで説明されるように
expected_arrival_timeを計算し、それが記録窓の外にある場合は0-RTTを拒否し、
1-RTTハンドシェイクへフォールバックします。
Rescorla Standards Track [Page 99]
RFC 8446 TLS 2018年8月
expected_arrival_timeが窓内にある場合、サーバーは一致するClientHelloを記録済みか
どうかを確認します。見つかった場合、"illegal_parameter"アラートでハンドシェイクを
中止するか、PSKを受け入れるが0-RTTを拒否します。一致するClientHelloが見つからない
場合、サーバーは0-RTTを受け入れ、その後expected_arrival_timeが窓内にある限り
ClientHelloを保存します。サーバーは、Bloom filterなど、偽陽性を持つデータストアも
実装してもよく (MAY)、その場合、見かけ上のリプレイに対して0-RTTを拒否することで
応答しなければなりません (MUST) が、ハンドシェイクを中止してはなりません (MUST NOT)。
サーバーは、ClientHelloの検証済みセクションのみからストレージ鍵を導出しなければ
なりません (MUST)。ClientHelloが複数のPSKアイデンティティを含む場合、攻撃者は、
サーバーがそれを検証しない（Section 4.2.11で推奨されるように）という仮定の下で、
優先度の低いアイデンティティについて異なるbinder値を持つ複数のClientHelloを作成
できます。すなわち、クライアントがPSK AおよびBを送信し、サーバーがAを優先する場合、
攻撃者はAのbinderに影響を与えることなくBのbinderを変更できます。Bのbinderが
ストレージ鍵の一部である場合、このClientHelloは重複として現れず、その結果
ClientHelloが受け入れられ、リプレイキャッシュ汚染などの副作用を引き起こす可能性が
あります。ただし、0-RTTデータは異なる鍵を使用するため復号できません。検証済みの
binderまたはClientHello.randomがストレージ鍵として使用される場合、この攻撃は
不可能です。
この機構は未使用のすべてのチケットを保存する必要がないため、再開および0-RTTの割合が
高い分散システムでは、受信したClientHelloメッセージを確実に保存および取得することが
難しいためにリプレイ対策防御が弱くなる可能性を代償として、実装が容易な場合があります。
そのような多くのシステムでは、受信したすべてのClientHelloについてグローバルに
一貫したストレージを持つことは非現実的です。この場合、特定のチケットについて単一の
ストレージゾーンを権威とし、そのチケットに対する0-RTTを他の任意のゾーンで拒否する
ことで、最良のリプレイ対策保護が提供されます。この手法は、1つのゾーンだけが0-RTT
データを受け入れるため、攻撃者による単純なリプレイを防止します。より弱い設計は、
各ゾーンに別個のストレージを実装するが、任意のゾーンで0-RTTを許可することです。
この手法は、リプレイ数をゾーンごとに1回に制限します。もちろん、アプリケーション
メッセージの重複はどちらの設計でも依然として可能です。
実装が新たに起動された場合、記録窓の任意の部分が起動時刻と重なる限り、0-RTTを拒否
すべきです (SHOULD)。そうでない場合、その期間中に元々送信されたリプレイを受け入れる
リスクがあります。
Rescorla Standards Track [Page 100]
RFC 8446 TLS 2018年8月
注: クライアントの時計がサーバーの時計よりかなり速く進んでいる場合、ClientHelloが
将来の窓外で受信されることがあります。その場合、それは1-RTTとして受け入れられ、
クライアントの再試行を引き起こし、その後0-RTTとして受け入れ可能になる可能性が
あります。これは、Section 8で説明される2つ目の攻撃形式の別の変種です。
8.3. Freshness Checks
ClientHelloはクライアントがそれを送信した時刻を示すため、ClientHelloが妥当に最近
送信された可能性が高いかどうかを効率的に判断し、そのようなClientHelloについてのみ
0-RTTを受け入れ、それ以外では1-RTTハンドシェイクへフォールバックできます。
これはSection 8.2で説明されるClientHello保存機構に必要です。そうでなければ、
サーバーは無制限の数のClientHelloを保存する必要があります。また、自己完結型の単回使用
チケットにとっても有用な最適化です。なぜなら、0-RTTに使用できないClientHelloを効率的に
拒否できるためです。
この機構を実装するため、サーバーは、サーバーがセッションチケットを生成した時刻を、
クライアントとサーバー間のround-trip timeの推定値でオフセットして保存する必要があります。
すなわち、
adjusted_creation_time = creation_time + estimated_RTT
この値はチケットにエンコードできるため、未使用の各チケットについて状態を保持する必要を
避けられます。サーバーは、クライアントの"pre_shared_key"拡張内の
"obfuscated_ticket_age"パラメーターからチケットの"ticket_age_add"値を減算することで、
チケット年齢についてのクライアントの見方を判断できます。サーバーは、ClientHelloの
expected_arrival_timeを次のように判断できます。
expected_arrival_time = adjusted_creation_time + clients_ticket_age
新しいClientHelloが受信されると、expected_arrival_timeは現在のサーバー壁時計時刻と
比較され、それらが一定量を超えて異なる場合、0-RTTは拒否されます。ただし、1-RTT
ハンドシェイクの完了は許可できます。
Rescorla Standards Track [Page 101]
RFC 8446 TLS 2018年8月
expected_arrival_timeと測定時刻の間の不一致を引き起こし得る潜在的なエラー源は
いくつかあります。クライアントおよびサーバーの時計レートの変動は最小である可能性が
高いですが、絶対時刻は大きくずれている可能性があります。ネットワーク伝搬遅延は、
経過時間の正当な値における不一致の最も可能性が高い原因です。NewSessionTicketおよび
ClientHelloメッセージの両方は再送され、そのため遅延する可能性があり、それはTCPに
よって隠される可能性があります。インターネット上のクライアントについては、時計の
エラーおよび測定の変動を考慮するため、10秒程度の窓を意味します。他のデプロイメント
シナリオでは異なるニーズがあるかもしれません。時計ずれの分布は対称ではないため、
最適なトレードオフは許容される不一致値の非対称な範囲を伴う可能性があります。
freshness checkingだけではリプレイを防止するのに十分ではないことに注意してください。
なぜなら、エラー窓の間のリプレイを検出しないためです。この窓は、帯域幅および
システム容量に応じて、実世界の設定で数十億のリプレイを含む可能性があります。
さらに、このfreshness checkingはClientHelloが受信された時点でのみ行われ、後続の
early Application Dataレコードが受信された時点では行われません。early dataが受け入れられた
後、レコードはより長い時間にわたってサーバーへストリーミングされ続ける可能性があります。
9. Compliance Requirements
9.1. Mandatory-to-Implement Cipher Suites
別途指定するアプリケーションプロファイル標準が存在しない場合:
TLS準拠アプリケーションは、TLS_AES_128_GCM_SHA256 [GCM]暗号スイートを
実装しなければならず (MUST)、TLS_AES_256_GCM_SHA384 [GCM]および
TLS_CHACHA20_POLY1305_SHA256 [RFC8439]暗号スイートを実装すべきです
(SHOULD)（Appendix B.4を参照）。
TLS準拠アプリケーションは、rsa_pkcs1_sha256（証明書用）、
rsa_pss_rsae_sha256（CertificateVerifyおよび証明書用）、および
ecdsa_secp256r1_sha256によるデジタル署名をサポートしなければなりません (MUST)。
TLS準拠アプリケーションは、secp256r1 (NIST P-256) による鍵交換をサポートしなければ
ならず (MUST)、X25519 [RFC7748]による鍵交換をサポートすべきです (SHOULD)。
Rescorla Standards Track [Page 102]
RFC 8446 TLS 2018年8月
9.2. Mandatory-to-Implement Extensions
別途指定するアプリケーションプロファイル標準が存在しない場合、TLS準拠
アプリケーションは次のTLS拡張を実装しなければなりません (MUST)。
- Supported Versions ("supported_versions"; Section 4.2.1)
- Cookie ("cookie"; Section 4.2.2)
- Signature Algorithms ("signature_algorithms"; Section 4.2.3)
- Signature Algorithms Certificate ("signature_algorithms_cert";
Section 4.2.3)
- Negotiated Groups ("supported_groups"; Section 4.2.7)
- Key Share ("key_share"; Section 4.2.8)
- Server Name Indication ("server_name"; [RFC6066]のSection 3)
すべての実装は、該当する機能を提示するとき、これらの拡張を送信し使用しなければ
なりません (MUST)。
- "supported_versions"は、すべてのClientHello、ServerHello、および
HelloRetryRequestメッセージに必須です (REQUIRED)。
- "signature_algorithms"は、証明書認証に必須です (REQUIRED)。
- "supported_groups"は、DHEまたはECDHE鍵交換を使用するClientHelloメッセージに
必須です (REQUIRED)。
- "key_share"は、DHEまたはECDHE鍵交換に必須です (REQUIRED)。
- "pre_shared_key"は、PSK鍵合意に必須です (REQUIRED)。
- "psk_key_exchange_modes"は、PSK鍵合意に必須です (REQUIRED)。
Rescorla Standards Track [Page 103]
RFC 8446 TLS 2018年8月
ClientHelloが、その本体に0x0304を含む"supported_versions"拡張を含む場合、
クライアントは本仕様を使用して交渉しようとしていると見なされます。
そのようなClientHelloメッセージは、次の要件を満たさなければなりません (MUST)。
- "pre_shared_key"拡張を含まない場合、"signature_algorithms"拡張と
"supported_groups"拡張の両方を含まなければなりません (MUST)。
- "supported_groups"拡張を含む場合、"key_share"拡張も含まなければならず
(MUST)、その逆も同様です。空のKeyShare.client_sharesベクトルは許可されます。
これらの要件に適合しないClientHelloを受信したサーバーは、"missing_extension"
アラートでハンドシェイクを中止しなければなりません (MUST)。
さらに、すべての実装は、それを使用できるアプリケーションで"server_name"拡張の使用を
サポートしなければなりません (MUST)。サーバーは、クライアントに有効な
"server_name"拡張の送信を要求してもよいです (MAY)。この拡張を要求するサーバーは、
"server_name"拡張を欠くClientHelloに対して、"missing_extension"アラートで接続を
終了することにより応答すべきです (SHOULD)。
9.3. Protocol Invariants
このセクションは、TLSエンドポイントおよびmiddleboxが従わなければならない (MUST)
invariantsを説明します。これは以前のTLSバージョンにも適用されます。
TLSは、安全かつ互換性を保って拡張可能であるように設計されています。新しいクライアント
またはサーバーは、新しいピアと通信するとき、最も優先される共通パラメーターを交渉
すべきです。TLSハンドシェイクはdowngrade protectionを提供します。TLSを終端せずに
新しいクライアントと新しいサーバーの間のトラフィックを通すmiddleboxは、ハンドシェイクに
影響を与えられないべきです（Appendix E.1を参照）。同時に、
デプロイメントは異なる速度で更新されるため、新しいクライアントまたはサーバーは、
古いエンドポイントと相互運用できるよう、古いパラメーターを引き続きサポートしても
よいです (MAY)。
Rescorla Standards Track [Page 104]
RFC 8446 TLS 2018年8月
これが機能するため、実装は拡張可能フィールドを正しく処理しなければなりません (MUST)。
- ClientHelloを送信するクライアントは、その中で広告されるすべてのパラメーターを
サポートしなければなりません (MUST)。そうでない場合、サーバーがそれらの
パラメーターの1つを選択することで相互運用に失敗する可能性があります。
- ClientHelloを受信するサーバーは、認識しないすべての暗号スイート、拡張、および
その他のパラメーターを正しく無視しなければなりません (MUST)。そうでない場合、
新しいクライアントとの相互運用に失敗する可能性があります。TLS 1.3では、
CertificateRequestまたはNewSessionTicketを受信するクライアントも、認識しない
すべての拡張を無視しなければなりません (MUST)。
- TLS接続を終端するmiddleboxは、元のクライアントに対して準拠TLSサーバーとして
振る舞わなければならず (MUST)、これにはクライアントが受け入れる意思のある
証明書を持つことが含まれます。また、元のサーバーに対して準拠TLSクライアントとして
振る舞わなければならず (MUST)、これには元のサーバーの証明書を検証することが
含まれます。特に、それは自身が理解するパラメーターのみを含む自身のClientHelloを
生成しなければならず (MUST)、エンドポイントの値を転送するのではなく、新しい
ServerHello random値を生成しなければなりません (MUST)。
TLSのプロトコル要件およびセキュリティ分析は、2つの接続に対して別々にのみ
適用されることに注意してください。TLS terminatorを安全にデプロイするには、
本文書の範囲外である追加のセキュリティ考慮事項が必要です。
- 理解しないClientHelloパラメーターを転送するmiddleboxは、そのClientHello以降の
任意のメッセージを処理してはなりません (MUST NOT)。それは後続のすべての
トラフィックを変更せずに転送しなければなりません (MUST)。そうでない場合、新しい
クライアントおよびサーバーとの相互運用に失敗する可能性があります。
転送されたClientHelloはmiddleboxによってサポートされていない機能の広告を含む
可能性があるため、応答にはmiddleboxが認識しない将来のTLS追加が含まれる可能性が
あります。これらの追加は、ClientHello以降の任意のメッセージを任意に変更しても
よいです (MAY)。特に、ServerHelloで送信される値が変わる可能性、ServerHello形式が
変わる可能性、およびTLSCiphertext形式が変わる可能性があります。
TLS 1.3の設計は、広くデプロイされた非準拠TLS middlebox
（Appendix D.4を参照）によって制約されました。ただし、invariantsを緩和する
ものではありません。それらのmiddleboxは引き続き非準拠です。
Rescorla Standards Track [Page 105]
RFC 8446 TLS 2018年8月
10. Security Considerations
セキュリティ上の問題は、本メモ全体、特にAppendices C、D、およびEで議論されます。
11. IANA Considerations
本文書は、元々[RFC4346]で作成され、[RFC8447]で更新された複数の
レジストリを使用します。IANAは、本文書を参照するようにこれらを更新しました。
レジストリおよびその割り当てポリシーは次のとおりです。
- TLS Cipher Suitesレジストリ: 先頭バイトが0-254（10進）の範囲にある値は、
Specification Required [RFC8126]を介して割り当てられます。先頭バイトが255
（10進）の値はPrivate Use [RFC8126]のために予約されています。
IANAは、Appendix B.4に列挙された暗号スイートをレジストリに追加しました。
"Value"および"Description"列は表から取られます。"DTLS-OK"および
"Recommended"列は、新しい各暗号スイートについてどちらも"Y"とマークされます。
- TLS ContentTypeレジストリ: 将来の値はStandards Action [RFC8126]を介して
割り当てられます。
- TLS Alertsレジストリ: 将来の値はStandards Action [RFC8126]を介して
割り当てられます。IANAは、Appendix B.2からの値でこのレジストリを
埋めました。"DTLS-OK"列は、それらすべての値について"Y"とマークされます。
"_RESERVED"とマークされた値は、その以前の使用を説明するコメントを持ちます。
- TLS HandshakeTypeレジストリ: 将来の値はStandards Action [RFC8126]を介して
割り当てられます。IANAは、このレジストリを更新し、項目4を"NewSessionTicket"から
"new_session_ticket"へ改名し、Appendix B.3からの値でこのレジストリを
埋めました。"DTLS-OK"列は、それらすべての値について"Y"とマークされます。
"_RESERVED"とマークされた値は、その以前または一時的な使用を説明するコメントを持ちます。
Rescorla Standards Track [Page 106]
RFC 8446 TLS 2018年8月
本文書はまた、元々[RFC4366]で作成されたTLS ExtensionType Values
レジストリを使用します。IANAは、本文書を参照するようにそれを更新しました。
レジストリへの変更は次のとおりです。
- IANAは登録ポリシーを次のように更新しました。
先頭バイトが0-254（10進）の範囲にある値は、Specification Required
[RFC8126]を介して割り当てられます。先頭バイトが255（10進）の値は
Private Use [RFC8126]のために予約されています。
- IANAはこのレジストリを更新し、本文書で定義される値および"Recommended"値"Y"を
持つ"key_share"、"pre_shared_key"、"psk_key_exchange_modes"、
"early_data"、"cookie"、"supported_versions"、"certificate_authorities"、
"oid_filters"、"post_handshake_auth"、および"signature_algorithms_cert"拡張を
含めました。
- IANAはこのレジストリを更新し、拡張が現れてよいメッセージを列挙する
"TLS 1.3"列を含めました。この列はSection 4.2の表から初期入力され、
そこに列挙されていない任意の拡張は、TLS 1.3で使用されないことを示すため"-"と
マークされます。
本文書は、元々[RFC6091]で作成され、[RFC8447]で更新された
TLS Certificate Typesレジストリ内の項目を更新します。IANAは、値1の項目を
名前"OpenPGP_RESERVED"、"Recommended"値"N"、およびコメント"Used in TLS versions
prior to 1.3."を持つように更新しました。
本文書は、元々[RFC6961]で作成されたTLS Certificate Status Types
レジストリ内の項目を更新します。IANAは、値2の項目を名前"ocsp_multi_RESERVED"および
コメント"Used in TLS versions prior to 1.3"を持つように更新しました。
本文書は、TLS Supported Groupsレジストリ（[RFC4492]によって異なる名前で
作成され、現在は[RFC8422]によって維持されています）内の2つの項目を更新します。
このレジストリは[RFC7919]および[RFC8447]によって更新されています。
値29および30（x25519およびx448）の項目は、本文書も参照するように更新されました。
Rescorla Standards Track [Page 107]
RFC 8446 TLS 2018年8月
さらに、本文書はIANAによって維持される2つの新しいレジストリを定義します。
- TLS SignatureSchemeレジストリ: 先頭バイトが0-253（10進）の範囲にある値は、
Specification Required [RFC8126]を介して割り当てられます。先頭バイトが
254または255（10進）の値はPrivate Use [RFC8126]のために予約されています。
先頭バイトが0-6の範囲にある値、または2番目のバイトが0-3の範囲にあり現在
割り当てられていない値は、後方互換性のために予約されています。このレジストリは
"Recommended"列を持ちます。このレジストリは、Section 4.2.3で説明される値で
初期入力されています。次の値は"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。"Recommended"列には、明示的に要求されない限り値"N"が割り当てられ、
"Recommended"値"Y"を持つ値を追加するにはStandards Action [RFC8126]が必要です。
Y->Nへの移行にはIESG Approvalが必要です (REQUIRED)。
- TLS PskKeyExchangeModeレジストリ: 0-253（10進）の範囲の値は
Specification Required [RFC8126]を介して割り当てられます。値254および255（10進）は
Private Use [RFC8126]のために予約されています。このレジストリは"Recommended"列を
持ちます。このレジストリはpsk_ke (0)およびpsk_dhe_ke (1)で初期入力されて
います。両方とも"Recommended"としてマークされています。"Recommended"列には、
明示的に要求されない限り値"N"が割り当てられ、"Recommended"値"Y"を持つ値を
追加するにはStandards Action [RFC8126]が必要です。Y->Nへの移行には
IESG Approvalが必要です (REQUIRED)。
Rescorla Standards Track [Page 108]
RFC 8446 TLS 2018年8月
12. References
12.1. Normative References
[DH76] Diffie, W. and M. Hellman, "New directions in
cryptography", IEEE Transactions on Information
Theory, Vol. 22 No. 6, pp. 644-654,
DOI 10.1109/TIT.1976.1055638, November 1976.
[ECDSA] American National Standards Institute, "Public Key
Cryptography for the Financial Services Industry: The
Elliptic Curve Digital Signature Algorithm (ECDSA)",
ANSI ANS X9.62-2005, November 2005.
[GCM] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC",
NIST Special Publication 800-38D,
DOI 10.6028/NIST.SP.800-38D, November 2007.
[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>.
[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>.
Rescorla Standards Track [Page 109]
RFC 8446 TLS 2018年8月
[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>.
[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>.
Rescorla Standards Track [Page 110]
RFC 8446 TLS 2018年8月
[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>.
[SHS] Dang, Q., "Secure Hash Standard (SHS)", National Institute
of Standards and Technology report,
DOI 10.6028/NIST.FIPS.180-4, August 2015.
[X690] ITU-T, "Information technology -- ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ISO/IEC 8825-1:2015, November 2015.
Rescorla Standards Track [Page 111]
RFC 8446 TLS 2018年8月
12.2. Informative References
[AEAD-LIMITS]
Luykx, A. and K. Paterson, "Limits on Authenticated
Encryption Use in TLS", August 2017,
<http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.
[BBFGKZ16]
Bhargavan, K., Brzuska, C., Fournet, C., Green, M.,
Kohlweiss, M., and S. Zanella-Beguelin, "Downgrade
Resilience in Key-Exchange Protocols", Proceedings of IEEE
Symposium on Security and Privacy (San Jose),
DOI 10.1109/SP.2016.37, May 2016.
[BBK17] Bhargavan, K., Blanchet, B., and N. Kobeissi, "Verified
Models and Reference Implementations for the TLS 1.3
Standard Candidate", Proceedings of IEEE Symposium on
Security and Privacy (San Jose), DOI 10.1109/SP.2017.26,
May 2017.
[BDFKPPRSZZ16]
Bhargavan, K., Delignat-Lavaud, A., Fournet, C.,
Kohlweiss, M., Pan, J., Protzenko, J., Rastogi, A., Swamy,
N., Zanella-Beguelin, S., and J. Zinzindohoue,
"Implementing and Proving the TLS 1.3 Record Layer",
Proceedings of IEEE Symposium on Security and Privacy (San
Jose), May 2017, <https://eprint.iacr.org/2016/1178>.
[Ben17a] Benjamin, D., "Presentation before the TLS WG at
IETF 100", November 2017,
<https://datatracker.ietf.org/meeting/100/materials/
slides-100-tls-sessa-tls13/>.
[Ben17b] Benjamin, D., "Additional TLS 1.3 results from Chrome",
message to the TLS mailing list, 18 December 2017,
<https://www.ietf.org/mail-archive/web/tls/current/
msg25168.html>.
[Blei98] Bleichenbacher, D., "Chosen Ciphertext Attacks against
Protocols Based on RSA Encryption Standard PKCS #1",
Proceedings of CRYPTO '98, 1998.
[BMMRT15] Badertscher, C., Matt, C., Maurer, U., Rogaway, P., and B.
Tackmann, "Augmented Secure Channels and the Goal of the
TLS 1.3 Record Layer", ProvSec 2015, September 2015,
<https://eprint.iacr.org/2015/394>.
Rescorla Standards Track [Page 112]
RFC 8446 TLS 2018年8月
[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 Computer Security
Foundations Symposium, DOI 10.1109/CSF.2016.19, July 2015.
[CHECKOWAY]
Checkoway, S., Maskiewicz, J., Garman, C., Fried, J.,
Cohney, S., Green, M., Heninger, N., Weinmann, R.,
Rescorla, E., and H. Shacham, "A Systematic Analysis of
the Juniper Dual EC Incident", Proceedings of the 2016 ACM
SIGSAC Conference on Computer and Communications Security
- CCS '16, DOI 10.1145/2976749.2978395, October 2016.
[CHHSV17] Cremers, C., Horvat, M., Hoyland, J., Scott, S., and T.
van der Merwe, "Awkward Handshake: Possible mismatch of
client/server view on client authentication in
post-handshake mode in Revision 18", message to the TLS
mailing list, 10 February 2017, <https://www.ietf.org/
mail-archive/web/tls/current/msg22382.html>.
[CHSV16] Cremers, C., Horvat, M., Scott, S., and T. van der Merwe,
"Automated Analysis and Verification of TLS 1.3: 0-RTT,
Resumption and Delayed Authentication", Proceedings of
IEEE Symposium on Security and Privacy (San Jose),
DOI 10.1109/SP.2016.35, May 2016,
<https://ieeexplore.ieee.org/document/7546518/>.
[CK01] Canetti, R. and H. Krawczyk, "Analysis of Key-Exchange
Protocols and Their Use for Building Secure Channels",
Proceedings of Eurocrypt 2001,
DOI 10.1007/3-540-44987-6_28, April 2001.
[CLINIC] Miller, B., Huang, L., Joseph, A., and J. Tygar, "I Know
Why You Went to the Clinic: Risks and Realization of HTTPS
Traffic Analysis", Privacy Enhancing Technologies, pp.
143-163, DOI 10.1007/978-3-319-08506-7_8, 2014.
[DFGS15] Dowling, B., Fischlin, M., Guenther, F., and D. Stebila,
"A Cryptographic Analysis of the TLS 1.3 Handshake
Protocol Candidates", Proceedings of ACM CCS 2015,
October 2015, <https://eprint.iacr.org/2015/914>.
Rescorla Standards Track [Page 113]
RFC 8446 TLS 2018年8月
[DFGS16] Dowling, B., Fischlin, M., Guenther, F., and D. Stebila,
"A Cryptographic Analysis of the TLS 1.3 Full and
Pre-shared Key Handshake Protocol", TRON 2016,
February 2016, <https://eprint.iacr.org/2016/081>.
[DOW92] Diffie, W., van Oorschot, P., and M. Wiener,
"Authentication and authenticated key exchanges", Designs,
Codes and Cryptography, DOI 10.1007/BF00124891, June 1992.
[DSS] National Institute of Standards and Technology, U.S.
Department of Commerce, "Digital Signature Standard
(DSS)", NIST FIPS PUB 186-4, DOI 10.6028/NIST.FIPS.186-4,
July 2013.
[FG17] Fischlin, M. and F. Guenther, "Replay Attacks on Zero
Round-Trip Time: The Case of the TLS 1.3 Handshake
Candidates", Proceedings of EuroS&P 2017, April 2017,
<https://eprint.iacr.org/2017/082>.
[FGSW16] Fischlin, M., Guenther, F., Schmidt, B., and B. Warinschi,
"Key Confirmation in Key Exchange: A Formal Treatment and
Implications for TLS 1.3", Proceedings of IEEE Symposium
on Security and Privacy (San Jose),
DOI 10.1109/SP.2016.34, May 2016,
<https://ieeexplore.ieee.org/document/7546517/>.
[FW15] Weimer, F., "Factoring RSA Keys With TLS Perfect Forward
Secrecy", September 2015.
[HCJC16] Husak, M., Cermak, M., Jirsik, T., and P. Celeda, "HTTPS
traffic analysis and client identification using passive
SSL/TLS fingerprinting", EURASIP Journal on Information
Security, Vol. 2016, DOI 10.1186/s13635-016-0030-7,
February 2016.
[HGFS15] Hlauschek, C., Gruber, M., Fankhauser, F., and C. Schanes,
"Prying Open Pandora's Box: KCI Attacks against TLS",
Proceedings of USENIX Workshop on Offensive Technologies,
August 2015.
[IEEE1363]
IEEE, "IEEE Standard Specifications for Public Key
Cryptography", IEEE Std. 1363-2000,
DOI 10.1109/IEEESTD.2000.92292.
Rescorla Standards Track [Page 114]
RFC 8446 TLS 2018年8月
[JSS15] Jager, T., Schwenk, J., and J. Somorovsky, "On the
Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1
v1.5 Encryption", Proceedings of ACM CCS 2015,
DOI 10.1145/2810103.2813657, October 2015,
<https://www.nds.rub.de/media/nds/
veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf>.
[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.
[Kraw10] Krawczyk, H., "Cryptographic Extraction and Key
Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010,
August 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 EuroS&P 2016, March 2016,
<https://eprint.iacr.org/2015/978>.
[LXZFH16] Li, X., Xu, J., Zhang, Z., Feng, D., and H. Hu, "Multiple
Handshakes Security of TLS 1.3 Candidates", Proceedings of
IEEE Symposium on Security and Privacy (San Jose),
DOI 10.1109/SP.2016.36, May 2016,
<https://ieeexplore.ieee.org/document/7546519/>.
[Mac17] MacCarthaigh, C., "Security Review of TLS1.3 0-RTT",
March 2017, <https://github.com/tlswg/tls13-spec/
issues/1001>.
[PS18] Patton, C. and T. Shrimpton, "Partially specified
channels: The TLS 1.3 record layer without elision", 2018,
<https://eprint.iacr.org/2018/634>.
[PSK-FINISHED]
Scott, S., Cremers, C., Horvat, M., and T. van der Merwe,
"Revision 10: possible attack if client authentication is
allowed during PSK", message to the TLS mailing list,
31 October 2015, <https://www.ietf.org/
mail-archive/web/tls/current/msg18215.html>.
Rescorla Standards Track [Page 115]
RFC 8446 TLS 2018年8月
[REKEY] Abdalla, M. and M. Bellare, "Increasing the Lifetime of a
Key: A Comparative Analysis of the Security of Re-keying
Techniques", ASIACRYPT 2000, DOI 10.1007/3-540-44448-3_42,
October 2000.
[Res17a] Rescorla, E., "Preliminary data on Firefox TLS 1.3
Middlebox experiment", message to the TLS mailing list,
5 December 2017, <https://www.ietf.org/
mail-archive/web/tls/current/msg25091.html>.
[Res17b] Rescorla, E., "More compatibility measurement results",
message to the TLS mailing list, 22 December 2017,
<https://www.ietf.org/mail-archive/web/tls/current/
msg25179.html>.
[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>.
Rescorla Standards Track [Page 116]
RFC 8446 TLS 2018年8月
[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>.
[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>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[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>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
Rescorla Standards Track [Page 117]
RFC 8446 TLS 2018年8月
[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>.
[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>.
[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>.
[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>.
[RFC8449] Thomson, M., "Record Size Limit Extension for TLS",
RFC 8449, DOI 10.17487/RFC8449, August 2018,
<https://www.rfc-editor.org/info/rfc8449>.
Rescorla Standards Track [Page 118]
RFC 8446 TLS 2018年8月
[RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key
Cryptosystems", Communications of the ACM, Vol. 21 No. 2,
pp. 120-126, DOI 10.1145/359340.359342, February 1978.
[SIGMA] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to
Authenticated Diffie-Hellman and its Use in the IKE
Protocols", Proceedings of CRYPTO 2003,
DOI 10.1007/978-3-540-45146-4_24, August 2003.
[SLOTH] Bhargavan, K. and G. Leurent, "Transcript Collision
Attacks: Breaking Authentication in TLS, IKE, and SSH",
Network and Distributed System Security
Symposium (NDSS 2016), DOI 10.14722/ndss.2016.23418,
February 2016.
[SSL2] Hickman, K., "The SSL Protocol", February 1995.
[TIMING] Boneh, D. and D. Brumley, "Remote Timing Attacks Are
Practical", USENIX Security Symposium, August 2003.
[TLS13-TRACES]
Thomson, M., "Example Handshake Traces for TLS 1.3", Work
in Progress, draft-ietf-tls-tls13-vectors-06, July 2018.
[X501] ITU-T, "Information Technology - Open Systems
Interconnection - The Directory: Models", ITU-T X.501,
October 2016, <https://www.itu.int/rec/T-REC-X.501/en>.
Rescorla Standards Track [Page 119]
RFC 8446 TLS 2018年8月
Appendix A. 状態機械
この付録は、クライアントおよびサーバーのハンドシェイクにおける正当な状態遷移の
概要を提供します。状態名（すべて大文字、例: START）は形式的な意味を持ちませんが、
理解を容易にするために提供されています。特定の状況でのみ実行されるアクションは
[]で示されます。"K_{send,recv} = foo"という表記は、「send/recv鍵を指定された鍵に
設定する」ことを意味します。
A.1. Client
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
上に示された遷移では、クライアントはServerHello後のメッセージに由来する
アラートを、平文またはearly data鍵で送信する可能性があることに注意してください。
クライアントがそのようなアラートを送信する必要がある場合、可能であればまず
handshake鍵へ再鍵化すべきです (SHOULD)。
Rescorla Standards Track [Page 120]
RFC 8446 TLS 2018年8月
A.2. Server
START <-----+
Recv ClientHello | | Send HelloRetryRequest
v |
RECVD_CH ----+
| Select parameters
v
NEGOTIATED
| Send ServerHello
| K_send = handshake
| Send EncryptedExtensions
| [Send CertificateRequest]
Can send | [Send Certificate + CertificateVerify]
app data | Send Finished
after --> | K_send = application
here +--------+--------+
No 0-RTT | | 0-RTT
| |
K_recv = handshake | | K_recv = early data
[Skip decrypt errors] | +------> WAIT_EOED -+
| | Recv | | Recv EndOfEarlyData
| | early data | | K_recv = handshake
| +------------+ |
| |
+> WAIT_FLIGHT2 <--------+
|
+--------+--------+
No auth | | Client auth
| |
| v
| WAIT_CERT
| Recv | | Recv Certificate
| empty | v
| Certificate | WAIT_CV
| | | Recv
| v | CertificateVerify
+-> WAIT_FINISHED <---+
| Recv Finished
| K_recv = application
v
CONNECTED
Rescorla Standards Track [Page 121]
RFC 8446 TLS 2018年8月
Appendix B. プロトコルデータ構造および定数値
この付録は、規範的なプロトコル型および定数の定義を提供します。
"_RESERVED"として列挙される値は、以前のTLSバージョンで使用されていたものであり、
完全性のためにここに列挙されています。TLS 1.3実装はそれらを送信してはなりません
(MUST NOT) が、古いTLS実装から受信する可能性があります。
B.1. Record Layer
enum {
invalid(0),
change_cipher_spec(20),
alert(21),
handshake(22),
application_data(23),
heartbeat(24), /* RFC 6520 */
(255)
} ContentType;
struct {
ContentType type;
ProtocolVersion legacy_record_version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
struct {
opaque content[TLSPlaintext.length];
ContentType type;
uint8 zeros[length_of_padding];
} TLSInnerPlaintext;
struct {
ContentType opaque_type = application_data; /* 23 */
ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */
uint16 length;
opaque encrypted_record[TLSCiphertext.length];
} TLSCiphertext;
Rescorla Standards Track [Page 122]
RFC 8446 TLS 2018年8月
B.2. Alert Messages
enum { warning(1), fatal(2), (255) } AlertLevel;
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed_RESERVED(21),
record_overflow(22),
decompression_failure_RESERVED(30),
handshake_failure(40),
no_certificate_RESERVED(41),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
export_restriction_RESERVED(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
inappropriate_fallback(86),
user_canceled(90),
no_renegotiation_RESERVED(100),
missing_extension(109),
unsupported_extension(110),
certificate_unobtainable_RESERVED(111),
unrecognized_name(112),
bad_certificate_status_response(113),
bad_certificate_hash_value_RESERVED(114),
unknown_psk_identity(115),
certificate_required(116),
no_application_protocol(120),
(255)
} AlertDescription;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
Rescorla Standards Track [Page 123]
RFC 8446 TLS 2018年8月
B.3. Handshake Protocol
enum {
hello_request_RESERVED(0),
client_hello(1),
server_hello(2),
hello_verify_request_RESERVED(3),
new_session_ticket(4),
end_of_early_data(5),
hello_retry_request_RESERVED(6),
encrypted_extensions(8),
certificate(11),
server_key_exchange_RESERVED(12),
certificate_request(13),
server_hello_done_RESERVED(14),
certificate_verify(15),
client_key_exchange_RESERVED(16),
finished(20),
certificate_url_RESERVED(21),
certificate_status_RESERVED(22),
supplemental_data_RESERVED(23),
key_update(24),
message_hash(254),
(255)
} HandshakeType;
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */
select (Handshake.msg_type) {
case client_hello: ClientHello;
case server_hello: ServerHello;
case end_of_early_data: EndOfEarlyData;
case encrypted_extensions: EncryptedExtensions;
case certificate_request: CertificateRequest;
case certificate: Certificate;
case certificate_verify: CertificateVerify;
case finished: Finished;
case new_session_ticket: NewSessionTicket;
case key_update: KeyUpdate;
};
} Handshake;
Rescorla Standards Track [Page 124]
RFC 8446 TLS 2018年8月
B.3.1. Key Exchange Messages
uint16 ProtocolVersion;
opaque Random[32];
uint8 CipherSuite[2]; /* Cryptographic suite selector */
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id<0..32>;
CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>;
} ClientHello;
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id_echo<0..32>;
CipherSuite cipher_suite;
uint8 legacy_compression_method = 0;
Extension extensions<6..2^16-1>;
} ServerHello;
Rescorla Standards Track [Page 125]
RFC 8446 TLS 2018年8月
struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
enum {
server_name(0), /* RFC 6066 */
max_fragment_length(1), /* RFC 6066 */
status_request(5), /* RFC 6066 */
supported_groups(10), /* RFC 8422, 7919 */
signature_algorithms(13), /* RFC 8446 */
use_srtp(14), /* RFC 5764 */
heartbeat(15), /* RFC 6520 */
application_layer_protocol_negotiation(16), /* RFC 7301 */
signed_certificate_timestamp(18), /* RFC 6962 */
client_certificate_type(19), /* RFC 7250 */
server_certificate_type(20), /* RFC 7250 */
padding(21), /* RFC 7685 */
RESERVED(40), /* Used but never
assigned */
pre_shared_key(41), /* RFC 8446 */
early_data(42), /* RFC 8446 */
supported_versions(43), /* RFC 8446 */
cookie(44), /* RFC 8446 */
psk_key_exchange_modes(45), /* RFC 8446 */
RESERVED(46), /* Used but never
assigned */
certificate_authorities(47), /* RFC 8446 */
oid_filters(48), /* RFC 8446 */
post_handshake_auth(49), /* RFC 8446 */
signature_algorithms_cert(50), /* RFC 8446 */
key_share(51), /* RFC 8446 */
(65535)
} ExtensionType;
struct {
NamedGroup group;
opaque key_exchange<1..2^16-1>;
} KeyShareEntry;
struct {
KeyShareEntry client_shares<0..2^16-1>;
} KeyShareClientHello;
struct {
NamedGroup selected_group;
} KeyShareHelloRetryRequest;
Rescorla Standards Track [Page 126]
RFC 8446 TLS 2018年8月
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;
Rescorla Standards Track [Page 127]
RFC 8446 TLS 2018年8月
B.3.1.1. Version Extension
struct {
select (Handshake.msg_type) {
case client_hello:
ProtocolVersion versions<2..254>;
case server_hello: /* and HelloRetryRequest */
ProtocolVersion selected_version;
};
} SupportedVersions;
B.3.1.2. Cookie Extension
struct {
opaque cookie<1..2^16-1>;
} Cookie;
Rescorla Standards Track [Page 128]
RFC 8446 TLS 2018年8月
B.3.1.3. Signature Algorithm Extension
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;
Rescorla Standards Track [Page 129]
RFC 8446 TLS 2018年8月
B.3.1.4. Supported Groups Extension
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;
"obsolete_RESERVED"範囲内の値は、以前のTLSバージョンで使用されており、
TLS 1.3実装によって提示または交渉されてはなりません (MUST NOT)。廃止された曲線には、
さまざまな既知または理論上の弱点があるか、または使用実績が非常に少なく、一部の
場合では意図しないサーバー構成の問題によるものにすぎません。それらは一般利用に
適切であるとはもはや見なされておらず、潜在的に安全でないものと仮定すべきです。
ここで指定される曲線集合は、現在デプロイされ、適切に構成されているすべてのTLS実装と
相互運用するのに十分です。
Rescorla Standards Track [Page 130]
RFC 8446 TLS 2018年8月
B.3.2. Server Parameters Messages
opaque DistinguishedName<1..2^16-1>;
struct {
DistinguishedName authorities<3..2^16-1>;
} CertificateAuthoritiesExtension;
struct {
opaque certificate_extension_oid<1..2^8-1>;
opaque certificate_extension_values<0..2^16-1>;
} OIDFilter;
struct {
OIDFilter filters<0..2^16-1>;
} OIDFilterExtension;
struct {} PostHandshakeAuth;
struct {
Extension extensions<0..2^16-1>;
} EncryptedExtensions;
struct {
opaque certificate_request_context<0..2^8-1>;
Extension extensions<2..2^16-1>;
} CertificateRequest;
Rescorla Standards Track [Page 131]
RFC 8446 TLS 2018年8月
B.3.3. Authentication Messages
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;
B.3.4. Ticket Establishment
struct {
uint32 ticket_lifetime;
uint32 ticket_age_add;
opaque ticket_nonce<0..255>;
opaque ticket<1..2^16-1>;
Extension extensions<0..2^16-2>;
} NewSessionTicket;
Rescorla Standards Track [Page 132]
RFC 8446 TLS 2018年8月
B.3.5. Updating Keys
struct {} EndOfEarlyData;
enum {
update_not_requested(0), update_requested(1), (255)
} KeyUpdateRequest;
struct {
KeyUpdateRequest request_update;
} KeyUpdate;
B.4. Cipher Suites
対称暗号スイートは、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 |
| | |
| VALUE | The two-byte ID assigned for this cipher suite |
+-----------+------------------------------------------------+
本仕様は、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} |
+------------------------------+-------------+
Rescorla Standards Track [Page 133]
RFC 8446 TLS 2018年8月
対応する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]で
定義されます。
TLS 1.3は以前のTLSバージョンと同じ暗号スイート空間を使用しますが、TLS 1.3の
暗号スイートは異なる方法で定義され、対称暗号のみを指定し、TLS 1.2では使用できません。
同様に、TLS 1.2以下の暗号スイートはTLS 1.3で使用できません。
新しい暗号スイート値は、Section 11で説明されるようにIANAによって割り当て
られます。
Appendix C. 実装上の注意
TLSプロトコルは、多くの一般的なセキュリティ上の誤りを防止できません。この付録は、
実装者を支援するためにいくつかの推奨事項を提供します。[TLS13-TRACES]は、
TLS 1.3ハンドシェイクのテストベクトルを提供します。
C.1. 乱数生成およびシード
TLSは、暗号学的に安全な疑似乱数生成器 (CSPRNG) を必要とします。ほとんどの場合、
オペレーティングシステムは/dev/urandomなどの適切な機能を提供しており、他の
懸念（例: 性能）がなければそれを使用すべきです。新しいものを作るよりも、既存の
CSPRNG実装を使用することが推奨されます (RECOMMENDED)。多くの十分な暗号ライブラリが、
有利なライセンス条件ですでに利用可能です。それらが不十分であることが判明した場合、
[RFC4086]は乱数値の生成に関する指針を提供します。
TLSは、(1) ClientHelloおよびServerHello内の公開Random値などの公開プロトコル
フィールドで、また(2) keying materialを生成するために、乱数値を使用します。
適切に機能するCSPRNGでは、これはセキュリティ上の問題を提示しません。なぜなら、
その出力からCSPRNG状態を判定することは実行可能ではないためです。しかし、壊れた
CSPRNGでは、[CHECKOWAY]で文書化されているように、攻撃者が公開出力を用いて
CSPRNG内部状態を判定し、それによりkeying materialを予測できる可能性があります。
実装は、公開値と秘密値を生成するために別々のCSPRNGを使用することで、この形式の攻撃に
対する追加のセキュリティを提供できます。
Rescorla Standards Track [Page 134]
RFC 8446 TLS 2018年8月
C.2. Certificates and Authentication
実装は、証明書の完全性を検証する責任を負い、一般に証明書失効メッセージを
サポートすべきです。アプリケーションプロファイルから特定の指示がない場合、
証明書は、信頼された認証局 (CA) によって適切に署名されていることを保証するため、
常に検証されるべきです。トラストアンカーの選択および追加は、非常に慎重に行うべきです。
ユーザーは、証明書およびトラストアンカーに関する情報を表示できるべきです。
アプリケーションは、最小および最大の鍵サイズも強制すべきです (SHOULD)。たとえば、
2048ビットRSAまたは224ビットECDSAより弱い鍵または署名を含む認証パスは、安全な
アプリケーションには適切ではありません。
C.3. Implementation Pitfalls
実装経験は、以前のTLS仕様の特定の部分が理解しやすくなく、相互運用性および
セキュリティ問題の原因となってきたことを示しています。これらの領域の多くは
本文書で明確化されていますが、この付録は実装者が特別な注意を払う必要がある最も
重要な事項の短い一覧を含みます。
TLSプロトコルの問題:
- 複数のTLSレコードへ断片化されたhandshakeメッセージを正しく処理していますか
（Section 5.1を参照）? ClientHelloが複数の小さな断片に分割されるような
コーナーケースを正しく処理していますか? maximum fragment sizeを超えるhandshake
メッセージを断片化していますか? 特に、CertificateおよびCertificateRequest
handshakeメッセージは、断片化を必要とするほど大きくなる可能性があります。
- すべての暗号化されていないTLSレコードでTLSレコード層バージョン番号を無視して
いますか（Appendix Dを参照）?
- TLS 1.3以降をサポートするすべての可能な構成から、SSL、RC4、EXPORT暗号、および
MD5（"signature_algorithms"拡張を介する）のすべてのサポートが完全に削除され、
これらの廃止された機能を使用しようとする試みが正しく失敗することを確認しましたか
（Appendix Dを参照）?
- 未知の拡張を含め、ClientHello内のTLS拡張を正しく処理していますか?
Rescorla Standards Track [Page 135]
RFC 8446 TLS 2018年8月
- サーバーがクライアント証明書を要求しているが適切な証明書が利用できない場合、
メッセージ全体を省略するのではなく、空のCertificateメッセージを正しく送信して
いますか（Section 4.4.2を参照）?
- AEAD-Decryptによって生成されたplaintext fragmentを処理し、末尾から
ContentTypeをスキャンするとき、ピアがすべてゼロの不正なplaintextを送信した場合に、
cleartextの先頭を越えてスキャンすることを避けていますか?
- ClientHello内の認識しないcipher suite（Section 4.1.2）、
hello extension（Section 4.2）、named group（Section 4.2.7）、
key share（Section 4.2.8）、supported version（Section 4.2.1）、
およびsignature algorithm（Section 4.2.3）を適切に無視していますか?
- サーバーとして、互換性のある(EC)DHEグループをサポートしているが
"key_share"拡張でそれを予測していないクライアントへHelloRetryRequestを送信して
いますか? クライアントとして、サーバーからのHelloRetryRequestを正しく処理して
いますか?
暗号学的な詳細:
- タイミング攻撃 [TIMING]を防ぐために、どのような対策を使用していますか?
- Diffie-Hellman鍵交換を使用するとき、交渉された鍵内の先頭ゼロバイトを正しく保持して
いますか（Section 7.4.1を参照）?
- あなたのTLSクライアントは、サーバーによって送信されたDiffie-Hellmanパラメーターが
受け入れ可能であることを確認していますか（Section 4.2.8.1を参照）?
- Diffie-Hellman秘密値、ECDSA "k"パラメーター、およびその他のセキュリティ上重要な値を
生成するとき、強力で、最も重要なこととして適切にシードされた乱数生成器を使用して
いますか（Appendix C.1を参照）? 実装は、[RFC6979]で
指定される"deterministic ECDSA"を実装することが推奨されます (RECOMMENDED)。
- Diffie-Hellman公開鍵値およびshared secretをグループサイズまでゼロパディングして
いますか（Section 4.2.8.1およびSection 7.4.1を参照）?
- RSA-CRT鍵漏洩 [FW15]から保護するため、署名を作成した後にそれらを検証して
いますか?
Rescorla Standards Track [Page 136]
RFC 8446 TLS 2018年8月
C.4. Client Tracking Prevention
クライアントは、複数の接続でチケットを再利用すべきではありません (SHOULD NOT)。
チケットの再利用により、受動的観測者は異なる接続を相関させることができます。
チケットを発行するサーバーは、クライアントが使用する可能性のある接続数と少なくとも
同じ数のチケットを提供すべきです (SHOULD)。たとえば、HTTP/1.1 [RFC7230]を使用する
Webブラウザーは、サーバーへの6つの接続を開く可能性があります。サーバーは各接続で
新しいチケットを発行すべきです (SHOULD)。これにより、クライアントは新しい接続を
作成するときに常に新しいチケットを使用できることが保証されます。
C.5. Unauthenticated Operation
以前のTLSバージョンは、匿名Diffie-Hellmanに基づく明示的に未認証の暗号スイートを
提供していました。これらのモードはTLS 1.3で非推奨になりました。しかし、
検証可能なサーバー認証を提供しないパラメーターを、次を含むいくつかの方法で
交渉することは依然として可能です。
- Raw public keys [RFC7250]。
- 証明書に含まれる公開鍵を使用するが、証明書チェーンまたはその内容を検証しないこと。
いずれの手法も単独で使用するとman-in-the-middle攻撃に脆弱であり、そのため一般利用には
安全ではありません。ただし、サーバーの公開鍵のout-of-band検証、trust on first use、
またはchannel bindingsのような機構（ただし[RFC5929]で説明されるchannel bindingsは
TLS 1.3について定義されていません）を介して、そのような接続を外部認証機構へ
結び付けることも可能です。そのような機構が使用されない場合、その接続は能動的な
man-in-the-middle攻撃に対する保護を持ちません。アプリケーションは、明示的な構成または
特定のアプリケーションプロファイルがない限り、そのような方法でTLSを使用しては
なりません (MUST NOT)。
Rescorla Standards Track [Page 137]
RFC 8446 TLS 2018年8月
Appendix D. 後方互換性
TLSプロトコルは、異なるTLSバージョンをサポートする可能性のあるエンドポイント間で
バージョン交渉を行うための組み込み機構を提供します。
TLS 1.xおよびSSL 3.0は、互換性のあるClientHelloメッセージを使用します。
サーバーは、ClientHello形式が互換性を保ち、クライアントとサーバーの両方によって
サポートされる少なくとも1つのプロトコルバージョンが存在する限り、将来のTLSバージョンを
使用しようとするクライアントも処理できます。
以前のTLSバージョンは、レコード層バージョン番号（TLSPlaintext.legacy_record_versionおよび
TLSCiphertext.legacy_record_version）をさまざまな目的に使用していました。TLS 1.3時点で、
このフィールドは非推奨です。TLSPlaintext.legacy_record_versionの値は、すべての実装に
よって無視されなければなりません (MUST)。TLSCiphertext.legacy_record_versionの値は、
保護解除のadditional dataに含まれますが、それ以外では無視してもよく (MAY)、固定定数値と
一致するように検証してもよいです (MAY)。バージョン交渉は、handshakeバージョン
（ClientHello.legacy_versionおよびServerHello.legacy_version、ならびにClientHello、
HelloRetryRequest、およびServerHelloの"supported_versions"拡張）のみを使用して実行されます。
古いエンドポイントとの相互運用性を最大化するため、TLS 1.0-1.2の使用を交渉する実装は、
ServerHelloおよびそれ以降のすべてのレコードについて、レコード層バージョン番号を交渉された
バージョンに設定すべきです (SHOULD)。
以前の非標準動作および誤構成されたデプロイメントとの最大限の互換性のため、すべての
実装は、以前のTLSバージョンのハンドシェイクを処理するときであっても、本文書の期待に
基づく証明パスの検証をサポートすべきです (SHOULD)（Section 4.4.2.2を参照）。
TLS 1.2以前は、ハンドシェイクトランスクリプトの大部分をmaster secretへ取り込む
"Extended Master Secret" [RFC7627]拡張をサポートしていました。
TLS 1.3は常にサーバーFinishedまでのトランスクリプトをハッシュするため、TLS 1.3と
以前のバージョンの両方をサポートする実装は、TLS 1.3が使用されるときは常にAPI内で
Extended Master Secret拡張の使用を示すべきです (SHOULD)。
Rescorla Standards Track [Page 138]
RFC 8446 TLS 2018年8月
D.1. Negotiating with an Older Server
TLS 1.3をサポートしないサーバーと交渉したいTLS 1.3クライアントは、
ClientHello.legacy_versionに0x0303 (TLS 1.2) を含む通常のTLS 1.3 ClientHelloを
送信しますが、"supported_versions"拡張には正しいバージョンを含めます。サーバーが
TLS 1.3をサポートしない場合、古いバージョン番号を含むServerHelloで応答します。
クライアントがこのバージョンの使用に同意する場合、交渉は交渉されたプロトコルに適した
方法で続行されます。再開のためにチケットを使用するクライアントは、以前に交渉された
バージョンを使用して接続を開始すべきです (SHOULD)。
0-RTTデータは古いサーバーと互換性がなく、サーバーがTLS 1.3をサポートすることを
知らない限り送信すべきではないことに注意してください (SHOULD NOT)。Appendix D.3を
参照してください。
サーバーによって選択されたバージョンがクライアントによってサポートされていない
（または受け入れ可能でない）場合、クライアントは"protocol_version"アラートで
ハンドシェイクを中止しなければなりません (MUST)。
一部のレガシーサーバー実装はTLS仕様を適切に実装しておらず、認識していないTLS拡張や
バージョンに遭遇すると接続を中止することが知られています。バグのあるサーバーとの
相互運用性は、本文書の範囲外である複雑なトピックです。後方互換性のある接続を交渉する
ために複数の接続試行が必要になる可能性があります。ただし、この慣行はダウングレード攻撃に
脆弱であり、推奨されません (NOT RECOMMENDED)。
D.2. Negotiating with an Older Client
TLSサーバーは、自身がサポートする最高バージョンより小さいバージョン番号を示す
ClientHelloを受信することもできます。"supported_versions"拡張が存在する場合、サーバーは
Section 4.2.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)。
以前のTLSバージョンは、すべての場合についてレコード層バージョン番号値
(TLSPlaintext.legacy_record_version) を明確に指定していなかったことに注意してください。
サーバーはこのフィールドでさまざまなTLS 1.xバージョンを受信しますが、その値は常に
無視されなければなりません (MUST)。
Rescorla Standards Track [Page 139]
RFC 8446 TLS 2018年8月
D.3. 0-RTT Backward Compatibility
0-RTTデータは古いサーバーと互換性がありません。古いサーバーはClientHelloに対して古い
ServerHelloで応答しますが、0-RTTデータを正しくスキップせず、ハンドシェイクを完了
できません。これは、クライアントが0-RTTを使用しようとする場合、特にマルチサーバー
デプロイメントに対して問題を引き起こす可能性があります。たとえば、デプロイメントが
TLS 1.3を段階的にデプロイし、一部のサーバーがTLS 1.3を実装し、一部がTLS 1.2を
実装している場合、またはTLS 1.3デプロイメントがTLS 1.2へダウングレードされる場合が
あります。
0-RTTデータを送信しようとするクライアントは、TLS 1.2以前のServerHelloを受信した場合、
接続を失敗させなければなりません (MUST)。その後、0-RTTを無効にして接続を再試行できます。
ダウングレード攻撃を避けるため、クライアントはTLS 1.3を無効にすべきではなく
(SHOULD NOT)、0-RTTのみを無効にすべきです。
このエラー条件を避けるため、マルチサーバーデプロイメントは、0-RTTを有効にする前に、
0-RTTなしのTLS 1.3の均一かつ安定したデプロイメントを保証すべきです (SHOULD)。
D.4. Middlebox Compatibility Mode
フィールド測定 [Ben17a] [Ben17b] [Res17a] [Res17b]により、
TLSクライアント/サーバーペアがTLS 1.3を交渉すると、かなりの数のmiddleboxが不正に
振る舞うことが判明しています。実装は、TLS 1.3ハンドシェイクをTLS 1.2ハンドシェイクに
より似せることで、それらのmiddleboxを通じて接続できる可能性を高めることができます。
- クライアントは、Section 4.1.2のlegacy_session_idセクションで説明されるように、
ClientHello内で常に空でないsession IDを提供します。
- early dataを提示しない場合、クライアントは2回目のフライトの直前にダミーの
change_cipher_specレコード（Section 5の第3段落を参照）を送信します。
これは2回目のClientHelloの前、または暗号化されたhandshakeフライトの前のいずれでも
かまいません。early dataを提示する場合、レコードは最初のClientHelloの直後に置かれます。
- サーバーは最初のhandshakeメッセージの直後にダミーのchange_cipher_specレコードを
送信します。これはServerHelloまたはHelloRetryRequestの後のいずれでもかまいません。
これらの変更を組み合わせると、TLS 1.3ハンドシェイクはTLS 1.2セッション再開に似た
ものとなり、middleboxを通じた接続成功の可能性が改善されます。この"compatibility mode"は
部分的に交渉されます。クライアントはsession IDを提供するかどうかを選択でき、サーバーは
それをエコーしなければなりません。どちらの側も
Rescorla Standards Track [Page 140]
RFC 8446 TLS 2018年8月
ハンドシェイク中いつでもchange_cipher_specを送信できます。これはピアによって無視され
なければならないためです。ただし、クライアントが空でないsession IDを送信する場合、
サーバーは本付録で説明されるようにchange_cipher_specを送信しなければなりません (MUST)。
D.5. Security Restrictions Related to Backward Compatibility
古いTLSバージョンの使用を交渉する実装は、利用可能な場合、forward secretかつAEADの
暗号スイートを優先すべきです (SHOULD)。
RC4暗号スイートのセキュリティは、[RFC7465]で引用される理由により不十分と
見なされます。実装は、いかなる理由でも、TLSのいかなるバージョンについてもRC4暗号
スイートを提示または交渉してはなりません (MUST NOT)。
古いTLSバージョンは、非常に低い強度の暗号の使用を許可していました。強度が112ビット
未満の暗号は、いかなる理由でも、TLSのいかなるバージョンについても提示または交渉
されてはなりません (MUST NOT)。
SSL 3.0 [RFC6101]のセキュリティは、[RFC7568]で列挙される理由により不十分と
見なされ、いかなる理由でも交渉されてはなりません (MUST NOT)。
SSL 2.0 [SSL2]のセキュリティは、[RFC6176]で列挙される理由により不十分と
見なされ、いかなる理由でも交渉されてはなりません (MUST NOT)。
実装はSSLバージョン2.0互換CLIENT-HELLOを送信してはなりません (MUST NOT)。
実装はSSLバージョン2.0互換CLIENT-HELLOを使用してTLS 1.3以降を交渉しては
なりません (MUST NOT)。実装は、古いTLSバージョンを交渉するためにSSLバージョン2.0
互換CLIENT-HELLOを受け入れることは推奨されません (NOT RECOMMENDED)。
実装は、0x0300以下に設定されたClientHello.legacy_versionまたは
ServerHello.legacy_versionを送信してはなりません (MUST NOT)。
ClientHello.legacy_versionまたはServerHello.legacy_versionが0x0300に設定された
Helloメッセージを受信する任意のエンドポイントは、"protocol_version"アラートで
ハンドシェイクを中止しなければなりません (MUST)。
実装は、0x0300未満のバージョンを持つ任意のレコードを送信してはなりません (MUST NOT)。
実装は、0x0300未満のバージョンを持つ任意のレコードを受け入れるべきではありません
(SHOULD NOT)（ただし、レコードバージョン番号が完全に無視される場合、意図せずそうする
可能性があります）。
実装は、AEADアルゴリズムに適用できず、一部のシナリオで安全でないことが示されているため、
[RFC6066]のSection 7で定義されるTruncated HMAC拡張を使用してはなりません
(MUST NOT)。
Rescorla Standards Track [Page 141]
RFC 8446 TLS 2018年8月
Appendix E. セキュリティ特性の概要
TLSの完全なセキュリティ分析は本文書の範囲外です。この付録では、望ましい特性の
非形式的な説明と、より形式的な定義を提供する研究文献におけるより詳細な作業への
参照を提供します。
ここでは、handshakeの特性とrecord layerの特性を別々に扱います。
E.1. Handshake
TLSハンドシェイクはAuthenticated Key Exchange (AKE) プロトコルであり、一方向認証
（サーバーのみ）および相互認証（クライアントとサーバー）の両方の機能を提供することを
意図しています。ハンドシェイクの完了時に、それぞれの側は次の値について自身の見解を
出力します。
- 作業鍵の集合を導出できる「session keys」の集合（master secretから導出される
さまざまなsecret）。
- 暗号パラメーターの集合（アルゴリズムなど）。
- 通信している当事者のアイデンティティ。
攻撃者は能動的ネットワーク攻撃者であると仮定します。これは、当事者間の通信に使用される
ネットワークを完全に制御することを意味します [RFC3552]。これらの条件下でも、
ハンドシェイクは以下に列挙される特性を提供すべきです。これらの特性は必ずしも独立して
いるわけではなく、プロトコル利用者のニーズを反映していることに注意してください。
同じsession keysの確立: ハンドシェイクは、各エンドポイントで正常に完了するなら、
ハンドシェイクの両側で同じsession keysの集合を出力する必要があります
（[CK01]、Definition 1、part 1を参照）。
session keysの秘匿性: 共有session keysは通信当事者だけに知られ、攻撃者には知られない
べきです（[CK01]、Definition 1、part 2を参照）。一方向認証された接続では、
攻撃者がサーバーと自身のsession keysを確立できますが、それらのsession keysは
クライアントによって確立されたものとは異なることに注意してください。
ピア認証: ピアアイデンティティについてのクライアントの見解は、サーバーの
アイデンティティを反映すべきです。クライアントが認証される場合、ピア
アイデンティティについてのサーバーの見解はクライアントのアイデンティティと一致
すべきです。
Rescorla Standards Track [Page 142]
RFC 8446 TLS 2018年8月
session keysの一意性: 任意の2つの異なるハンドシェイクは、異なり無関係なsession keysを
生成すべきです。ハンドシェイクによって生成される個々のsession keysも、異なり独立して
いるべきです。
Downgrade protection: 暗号パラメーターは両側で同じであるべきであり、攻撃が存在しない
状況でピアが通信していた場合と同じであるべきです（[BBFGKZ16]、
Definitions 8および9を参照）。
長期鍵に関するforward secret: ハンドシェイク完了後に長期鍵材料（この場合、
証明書ベース認証モードの署名鍵、または(EC)DHE付きPSKモードのexternal/resumption
PSK）が侵害されても、session key自体が消去されている限り、session keyの
セキュリティは侵害されません（[DOW92]を参照）。PSKが"psk_ke"
PskKeyExchangeModeで使用される場合、forward secrecy特性は満たされません。
Key Compromise Impersonation (KCI)耐性: 証明書による相互認証接続では、ある主体の
長期secretが侵害されても、その接続におけるその主体によるピアの認証を破るべきでは
ありません（[HGFS15]を参照）。たとえば、クライアントの署名鍵が侵害されても、
後続のハンドシェイクで任意のサーバーになりすましてそのクライアントに接続することは
可能であるべきではありません。
エンドポイントアイデンティティの保護: サーバーのアイデンティティ（証明書）は、
受動的攻撃者から保護されるべきです。クライアントのアイデンティティは、受動的攻撃者と
能動的攻撃者の両方から保護されるべきです。
非形式的には、TLS 1.3の署名ベースモードは、(EC)DHE鍵交換によって確立され、サーバーの
ハンドシェイクトランスクリプト上の署名によって認証され、さらにMACによってサーバーの
アイデンティティに結び付けられた、一意で秘密の共有鍵の確立を提供します。クライアントが
証明書によって認証される場合、クライアントもハンドシェイクトランスクリプト上に署名し、
両方のアイデンティティに結び付いたMACを提供します。[SIGMA]は、この種類の鍵交換
プロトコルの設計および分析を説明しています。各接続に新しい(EC)DHE鍵が使用される場合、
出力鍵はforward secretです。
external PSKおよびresumption PSKは、長期共有secretから、一意な接続ごとの短期
session keys集合へブートストラップします。このsecretは以前のハンドシェイクで確立された
可能性があります。(EC)DHE鍵確立付きPSKが使用される場合、これらのsession keysも
forward secretになります。resumption PSKは、接続Nによって計算され、接続N+1を形成するのに
必要なresumption master secretが、接続Nで使用されるtraffic keysから分離されるように設計
されており、それにより接続間のforward secrecyを提供します。さらに、同じ接続で
Rescorla Standards Track [Page 143]
RFC 8446 TLS 2018年8月
複数のチケットが確立される場合、それらは異なる鍵に関連付けられるため、1つのチケットに
関連付けられたPSKの侵害は、他のチケットに関連付けられたPSKで確立される接続の侵害には
つながりません。この特性は、チケットが自己暗号化される場合よりも、データベースに保存される
（したがって削除できる）場合に最も興味深いものです。
PSK binder値は、PSKと現在のハンドシェイクとの間、およびPSKが確立されたセッションと
現在のセッションとの間の結合を形成します。この結合は、推移的に元のハンドシェイク
トランスクリプトを含みます。なぜなら、そのトランスクリプトはresumption master secretを
生成する値へ取り込まれるためです。これには、resumption master secretを生成するために
使用されるKDFとbinderを計算するために使用されるMACの両方がcollision resistantであることが
必要です。詳細についてはAppendix E.1.1を参照してください。注: binderは他のPSKの
binder値をカバーしませんが、それらはFinished MACに含まれます。
TLSは現在、非証明書ベースのハンドシェイク（例: PSK）でサーバーが
certificate_requestメッセージを送信することを許可していません。この制限が将来緩和された場合、
クライアントの署名はサーバーの証明書を直接カバーしません。しかし、PSKがNewSessionTicketを
通じて確立された場合、クライアントの署名はPSK binderを通じてサーバーの証明書を推移的に
カバーします。[PSK-FINISHED]は、サーバーの証明書へ結合しない構成に対する具体的な
攻撃を説明しています（[Kraw16]も参照）。クライアントが同じPSK/key-idペアを
2つの異なるエンドポイントと共有する可能性がある場合、証明書ベースのクライアント認証を
使用することは安全ではありません。実装は、何らかの拡張によって交渉されない限り、
external PSKをクライアントまたはサーバーのいずれかの証明書ベース認証と組み合わせては
なりません (MUST NOT)。
exporterが使用される場合、それは一意かつ秘密の値を生成します（なぜなら、それらは一意の
session keyから生成されるためです）。異なるlabelおよびcontextで計算されるexporterは
計算上独立しているため、一方から他方を、またはexported valueからsession secretを計算する
ことは実行可能ではありません。注: exporterは任意長の値を生成できます。exporterを
channel bindingとして使用する場合、exported valueはcollision resistanceを提供するのに十分
大きくなければなりません (MUST)。TLS 1.3で提供されるexporterは、それぞれearly traffic key
およびapplication traffic keyと同じHandshake Contextから導出されるため、同様のセキュリティ
特性を持ちます。これらはクライアントの証明書を含まないことに注意してください。クライアントの
証明書に結合したい将来のアプリケーションは、完全なハンドシェイクトランスクリプトを含む
新しいexporterを定義する必要があるかもしれません。
Rescorla Standards Track [Page 144]
RFC 8446 TLS 2018年8月
すべてのhandshakeモードで、Finished MAC（および存在する場合は署名）がダウングレード攻撃を
防止します。さらに、Section 4.1.3で説明されるようにrandom nonce内の特定の
バイトを使用することで、以前のTLSバージョンへのダウングレードを検出できます。TLS 1.3および
ダウングレードの詳細については[BBFGKZ16]を参照してください。
クライアントとサーバーが共有鍵を確立するのに十分な情報を交換するとすぐに、ハンドシェイクの
残りは暗号化され、それにより、計算された共有鍵が認証されていない場合でも、受動的攻撃者に
対する保護を提供します。サーバーはクライアントより前に認証するため、クライアントは、
サーバーへ認証する場合、自身のアイデンティティを認証済みサーバーにのみ開示することを保証
できます。長さによるアイデンティティに関する情報漏洩を避けるため、実装はハンドシェイク中に
提供されるレコードパディング機構を使用しなければならないことに注意してください。クライアントが
提案するPSKアイデンティティは暗号化されず、サーバーが選択するものも暗号化されません。
E.1.1. Key Derivation and HKDF
TLS 1.3の鍵導出は、[RFC5869]で定義されるHKDFと、その2つのコンポーネントである
HKDF-ExtractおよびHKDF-Expandを使用します。HKDF構成の完全な根拠は[Kraw10]に、
TLS 1.3でそれが使用される方法の根拠は[KW16]にあります。本文書全体を通して、
HKDF-Extractの各適用の後には、HKDF-Expandの1回以上の呼び出しが続きます。この順序は常に
従われるべきです（本文書の将来の改訂を含む）。特に、HKDF-Extractの出力を、その間に
HKDF-Expandを挟まずに別のHKDF-Extractの適用への入力として使用すべきではありません
(SHOULD NOT)。同じ入力の一部に対してHKDF-Expandを複数回適用することは、それらが鍵および/
またはラベルによって区別される限り許可されます。
HKDF-Expandは、可変長の入力および出力を持つpseudorandom function (PRF)を実装することに
注意してください。本文書におけるHKDFの使用の一部（例: exporterおよび
resumption_master_secretの生成）では、HKDF-Expandの適用がcollision resistantである必要が
あります。すなわち、同じ値を出力するHKDF-Expandへの2つの異なる入力を見つけることが
実行不能であるべきです。これには、基礎となるハッシュ関数がcollision resistantであり、
HKDF-Expandからの出力長が少なくとも256ビット（またはそのハッシュ関数で衝突を見つけることを
防ぐために必要なだけ）であることが必要です。
Rescorla Standards Track [Page 145]
RFC 8446 TLS 2018年8月
E.1.2. Client Authentication
ハンドシェイク中またはハンドシェイク後認証でサーバーへ認証データを送信した
クライアントは、その後サーバーがクライアントを認証済みと見なすかどうかを確信できません。
クライアントが、サーバーが接続を一方向認証済みまたは相互認証済みと見なしているかどうかを
判定する必要がある場合、これはアプリケーション層によってプロビジョニングされなければ
なりません。詳細は[CHHSV17]を参照してください。さらに、[Kraw16]からのハンドシェイク後認証の
分析は、ハンドシェイク後段階で送信された証明書によって識別されるクライアントがtraffic keyを
所有していることを示しています。したがって、この当事者は、元のハンドシェイクに参加した
クライアント、または元のクライアントがtraffic keyを委譲した相手です（traffic keyが侵害されて
いないと仮定します）。
E.1.3. 0-RTT
0-RTT動作モードは一般に、1-RTTデータと同様のセキュリティ特性を提供します。ただし、
2つの例外があります。0-RTT暗号化鍵は完全なforward secrecyを提供しないこと、および
サーバーは、潜在的に過度な量の状態を保持しなければ、ハンドシェイクの一意性
（非リプレイ性）を保証できないことです。リプレイへの露出を制限する機構については
Section 8を参照してください。
E.1.4. Exporter Independence
exporter_master_secretおよびearly_exporter_master_secretは、traffic keyから独立するように
導出されるため、それらの鍵で暗号化されたトラフィックのセキュリティに対する脅威を表しません。
しかし、これらのsecretは任意のexporter値を計算するために使用できるため、できるだけ早く
消去されるべきです (SHOULD)。exporter labelの総集合が分かっている場合、実装はそれらの
すべてのラベルについてexporter計算の内部Derive-Secret段階を事前計算し、その後
[early_]exporter_master_secretを消去し、続いて各内部値が再び必要とされないことが分かり次第、
それを消去すべきです (SHOULD)。
E.1.5. Post-Compromise Security
TLSは、ピアの長期secret（署名鍵またはexternal PSK）が侵害された後に行われる
ハンドシェイクに対するセキュリティを提供しません。したがって、post-compromise security
[CCG16]、時にbackward secrecyまたはfuture secrecyとも呼ばれるものを提供しません。
これは、自身の長期secretが侵害された後に当事者が持つセキュリティ保証を説明するKCI耐性とは
対照的です。
Rescorla Standards Track [Page 146]
RFC 8446 TLS 2018年8月
E.1.6. External References
読者は、TLSハンドシェイクの分析について次の参考文献を参照すべきです:
[DFGS15], [CHSV16], [DFGS16], [KW16], [Kraw16],
[FGSW16], [LXZFH16], [FG17], and [BBK17].
E.2. Record Layer
record layerは、双方向暗号化鍵およびnonceを導出するために使用できる強いtraffic secretを
handshakeが生成することに依存します。それが真であり、鍵がSection 5.5で示される
量を超えるデータに使用されないと仮定すると、record layerは次の保証を提供すべきです。
Confidentiality: 攻撃者は、特定のレコードの平文内容を判定できるべきではありません。
Integrity: 攻撃者は、既存のレコードとは異なる新しいレコードで、受信者に受け入れられるものを
作成できるべきではありません。
Order protection/non-replayability: 攻撃者は、受信者がすでに受け入れたレコードを再び
受け入れさせたり、レコードNを先に処理させずにレコードN+1を受け入れさせたりできるべき
ではありません。
Length concealment: 特定の外部長を持つレコードが与えられた場合、攻撃者はそのレコードのうち
どれだけがcontentでどれだけがpaddingであるかを判定できるべきではありません。
鍵変更後のforward secrecy: Section 4.6.3で説明されるtraffic key update機構が
使用され、前世代の鍵が削除された場合、エンドポイントを侵害した攻撃者は古い鍵で暗号化された
トラフィックを復号できるべきではありません。
非形式的には、TLS 1.3は強い鍵で平文をAEAD保護することにより、これらの特性を提供します。
AEAD encryption [RFC5116]は、データの機密性および完全性を提供します。非リプレイ性は、
各レコードに別々のnonceを使用することで提供されます。そのnonceはレコードシーケンス番号
（Section 5.3）から導出され、シーケンス番号は両側で独立に維持されます。したがって、
順不同で配送されるレコードはAEAD保護解除の失敗を引き起こします。同じ平文が同じ鍵の下で
異なるユーザーによって繰り返し暗号化される場合（HTTPで一般的な場合）に大量暗号解析を防ぐ
ため、nonceはシーケンス番号を、traffic keyとともに導出される接続ごとのsecretな初期化
Rescorla Standards Track [Page 147]
RFC 8446 TLS 2018年8月
ベクトルと混合することによって形成されます。この構成の分析については[BT16]を参照して
ください。
TLS 1.3のrekeying手法（Section 7.2を参照）は、[REKEY]で議論されるserial generatorの
構成に従います。これは、rekeyingにより、rekeyingなしの場合よりも多くの暗号化に鍵を
使用できることを示しています。これは、pseudorandom function (PRF)としての
HKDF-Expand-Label関数のセキュリティに依存します。さらに、この関数が真に一方向である限り、
鍵変更前からtraffic keyを計算することは不可能です（forward secrecy）。
TLSは、その接続のtraffic secretが侵害された後にその接続上で通信されるデータに対する
セキュリティを提供しません。すなわち、TLSはtraffic secretに関してpost-compromise security/
future secrecy/backward secrecyを提供しません。実際、traffic secretを知った攻撃者は、
その接続上のすべての将来のtraffic secretを計算できます。そのような保証を望むシステムは、
新しいハンドシェイクを行い、(EC)DHE交換で新しい接続を確立する必要があります。
E.2.1. External References
読者は、TLS record layerの分析について次の参考文献を参照すべきです:
[BMMRT15], [BT16], [BDFKPPRSZZ16], [BBK17], and
[PS18].
E.3. Traffic Analysis
TLSは、暗号化パケットの長さおよびタイミングの観測に基づくさまざまなtraffic analysis攻撃に
影響を受けます [CLINIC] [HCJC16]。これは、固定されたコンテンツ集合をホストする
動画サーバーのように、区別すべき可能なメッセージ集合が小さい場合に特に容易ですが、
より複雑なシナリオでも依然として有用な情報を提供します。
TLSはこの形式の攻撃に対する特定の防御を提供しませんが、アプリケーションが使用するための
padding機構を含みます。AEAD関数によって保護される平文はcontentと可変長paddingから構成され、
これによりアプリケーションは任意長の暗号化レコードおよびpaddingのみのカバートラフィックを
生成し、送信期間と沈黙期間の差を隠すことができます。paddingは実際のcontentとともに暗号化
されるため、攻撃者はpaddingの長さを直接判定できませんが、レコード処理中に露出するタイミング
チャネルを利用して間接的に測定できる可能性があります（すなわち、レコード処理にどれだけ時間が
かかるかを観測する、またはレコードを少しずつ送り込んでどれがサーバーからの応答を引き出すかを
Rescorla Standards Track [Page 148]
RFC 8446 TLS 2018年8月
見る）。一般に、これらのチャネルをすべて除去する方法は知られていません。なぜなら、
constant-timeなpadding除去関数であっても、contentをデータ依存の関数へ渡す可能性が高いため
です。少なくとも、完全にconstant-timeなサーバーまたはクライアントには、その上位レベル
プロトコルをconstant timeにすることを含め、アプリケーション層プロトコル実装との緊密な協力が
必要です。
注: 強固なtraffic analysis防御は、パケット送信の遅延およびトラフィック量の増加により、
性能低下を招く可能性があります。
E.4. Side-Channel Attacks
一般に、TLSはside-channel攻撃（すなわち、タイミングなどの二次的チャネルを介して通信を
攻撃するもの）に対する特定の防御を持たず、それらを関連する暗号プリミティブの実装に委ねます。
しかし、TLSの特定の機能は、side-channel耐性のあるコードを書きやすくするように設計されています。
- 複合的なMAC-then-encrypt構造を使用していた以前のTLSバージョンとは異なり、TLS 1.3は
AEADアルゴリズムのみを使用するため、実装はそれらのプリミティブの自己完結した
constant-time実装を使用できます。
- TLSは、すべての復号エラーに対して一様な"bad_record_mac"アラートを使用します。これは、
攻撃者がメッセージの一部について断片的な洞察を得ることを防ぐことを意図しています。
そのようなエラーで接続を終了することにより、追加の耐性が提供されます。新しい接続は
異なる暗号材料を持ち、複数回の試行を必要とする暗号プリミティブへの攻撃を防ぎます。
side channelを通じた情報漏洩は、TLSより上の層、すなわちアプリケーションプロトコルおよび
それらを使用するアプリケーションで発生する可能性があります。side-channel攻撃への耐性は、
アプリケーションおよびアプリケーションプロトコルが、機密情報が不用意に漏洩しないことを
別々に保証することに依存します。
Rescorla Standards Track [Page 149]
RFC 8446 TLS 2018年8月
E.5. Replay Attacks on 0-RTT
リプレイ可能な0-RTTデータは、TLSを使用するアプリケーションに対して多くのセキュリティ
脅威を提示します。ただし、それらのアプリケーションがリプレイ下で安全であるように特別に
設計されている場合は除きます（最低限、これは冪等であることを意味しますが、多くの場合、
constant-time応答など、他のより強い条件も必要になる可能性があります）。潜在的な攻撃には
次が含まれます。
- 副作用を引き起こすアクション（例: 商品購入または送金）が重複し、それによりサイトまたは
ユーザーに害を与えること。
- 攻撃者は0-RTTメッセージを保存およびリプレイし、他のメッセージに対してそれらを並べ替える
ことができます（例: deleteをcreateの後へ移動する）。
- cache timing挙動を悪用して、0-RTTメッセージを別のキャッシュノードへリプレイし、その後
別の接続を使用して要求レイテンシを測定し、2つの要求が同じリソースを指すかどうかを確認する
ことにより、0-RTTメッセージの内容を発見すること。
データが大量にリプレイ可能な場合、暗号操作速度の反復測定など、追加の攻撃が可能になります。
さらに、それらはrate-limitingシステムを過負荷にできる可能性があります。これらの攻撃の
さらなる説明については[Mac17]を参照してください。
最終的に、サーバーは0-RTTデータ複製を利用する攻撃から自身を保護する責任を持ちます。
Section 8で説明される機構は、TLS層でリプレイを防止することを意図していますが、
クライアントデータの複数コピーを受信することに対する完全な保護は提供しません。
TLS 1.3は、サーバーがクライアントについて何の情報も持たない場合、たとえば状態を共有しない
別のクラスターにいるため、またはSection 8.1で説明されるようにチケットが削除されているため、
1-RTTハンドシェイクへフォールバックします。この設定でアプリケーション層プロトコルがデータを
再送する場合、攻撃者はClientHelloを元のクラスター（データを直ちに処理する）と、1-RTTへ
フォールバックしアプリケーション層リプレイ時にデータを処理する別のクラスターの両方へ送信する
ことで、メッセージ重複を誘発できる可能性があります。この攻撃の規模は、トランザクションを
再試行するクライアントの意思によって制限されるため、限られた量の重複しか許さず、各コピーは
サーバーにおいて新しい接続として現れます。
Rescorla Standards Track [Page 150]
RFC 8446 TLS 2018年8月
正しく実装された場合、Sections 8.1および8.2で説明される機構は、一貫した
状態を持つ任意のクラスターによって、リプレイされたClientHelloおよびそれに関連する0-RTT
データが複数回受け入れられることを防ぎます。0-RTTの使用を単一チケットに対して1つの
クラスターに制限するサーバーでは、特定のClientHelloおよびそれに関連する0-RTTデータは
1回だけ受け入れられます。しかし、状態が完全には一貫していない場合、攻撃者は複製窓の間に
データの複数コピーを受け入れさせることができる可能性があります。クライアントはサーバー挙動の
正確な詳細を知らないため、リプレイされても安全でなく、複数の1-RTT接続をまたいで再試行する
つもりもないメッセージをearly dataで送信してはなりません (MUST NOT)。
アプリケーションプロトコルは、その使用を定義するプロファイルなしに0-RTTデータを使用しては
なりません (MUST NOT)。そのプロファイルは、どのメッセージまたは相互作用が0-RTTで安全に
使用できるか、およびサーバーが0-RTTを拒否して1-RTTへフォールバックする状況をどう処理するかを
識別する必要があります。
さらに、偶発的な誤用を避けるため、TLS実装は、アプリケーションによって特に要求されない限り
0-RTT（送信または受け入れのいずれも）を有効にしてはならず (MUST NOT)、アプリケーションに
指示されない限り、サーバーによって拒否された0-RTTデータを自動的に再送してはなりません
(MUST NOT)。サーバー側アプリケーションは、ある種のアプリケーショントラフィックについて
0-RTTデータに特別な処理を実装したい場合があります（例: 接続を中止する、アプリケーション層で
データの再送を要求する、またはハンドシェイクが完了するまで処理を遅延する）。アプリケーションが
この種の処理を実装できるようにするため、TLS実装は、ハンドシェイクが完了したかどうかを
アプリケーションが判断する方法を提供しなければなりません (MUST)。
E.5.1. Replay and Exporters
ClientHelloのリプレイは同じearly exporterを生成するため、これらのexporterを使用する
アプリケーションには追加の注意が必要です。特に、これらのexporterが認証channel binding
（例: exporterの出力に署名すること）として使用される場合、PSKを侵害した攻撃者は認証鍵を
侵害することなく、接続間でauthenticatorを移植できます。
さらに、early exporterはserver-to-client暗号化鍵を生成するために使用すべきではありません
(SHOULD NOT)。なぜなら、それはそれらの鍵の再利用を伴うためです。これは、early application
traffic keyをclient-to-server方向でのみ使用することと並行しています。
Rescorla Standards Track [Page 151]
RFC 8446 TLS 2018年8月
E.6. PSK Identity Exposure
実装は無効なPSK binderに応答してハンドシェイクを中止するため、攻撃者が特定のPSK
アイデンティティが有効かどうかを検証できる可能性があります。具体的には、サーバーが
external-PSKハンドシェイクと証明書ベースハンドシェイクの両方を受け入れる場合、有効な
PSKアイデンティティはハンドシェイク失敗をもたらしますが、無効なアイデンティティは単に
スキップされ、成功した証明書ハンドシェイクをもたらします。PSKハンドシェイクのみを
サポートするサーバーは、有効なPSKアイデンティティがない場合と、アイデンティティはあるが
無効なbinderを持つ場合を同一に扱うことで、この形式の攻撃に抵抗できる可能性があります。
E.7. Sharing PSKs
TLS 1.3は、PSKを特定のKDFに結び付けることで保守的なアプローチを取ります。対照的に、
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を再利用しないことにより、cross-protocol related output
からの安全性を保証できます。
E.8. Attacks on Static RSA
TLS 1.3はRSA key transportを使用しないため、Bleichenbacher型攻撃 [Blei98]に直接影響を
受けませんが、TLS 1.3サーバーが以前のTLSバージョンの文脈でstatic RSAもサポートする場合、
TLS 1.3接続に対してサーバーになりすますことが可能になる可能性があります [JSS15]。
TLS 1.3実装は、すべてのTLSバージョンにわたってstatic RSAのサポートを無効にすることで、
この攻撃を防止できます。原理上、実装はstatic RSA復号用とRSA署名用で異なるkeyUsageビットを
持つ証明書を分離できる可能性もありますが、この手法は、digitalSignatureビットが設定されて
いない証明書内の鍵を使用する署名をクライアントが拒否することに依存しており、多くの
クライアントはこの制限を強制しません。
Rescorla Standards Track [Page 152]
RFC 8446 TLS 2018年8月
Contributors
Martin Abadi
University of California, Santa Cruz
abadi@cs.ucsc.edu
Christopher Allen
(co-editor of TLS 1.0)
Alacrity Ventures
ChristopherA@AlacrityManagement.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 [RFC7627])
INRIA
karthikeyan.bhargavan@inria.fr
Simon Blake-Wilson
(co-author of [RFC4492])
BCI
sblakewilson@bcisse.com
Nelson Bolyard
(co-author of [RFC4492])
Sun Microsystems, Inc.
nelson@bolyard.com
Ran Canetti
IBM
canetti@watson.ibm.com
Rescorla Standards Track [Page 153]
RFC 8446 TLS 2018年8月
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 [RFC7627])
INRIA
antdl@microsoft.com
Tim Dierks
(co-author of TLS 1.0, co-editor of TLS 1.1 and 1.2)
Independent
tim@dierks.org
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
Rescorla Standards Track [Page 154]
RFC 8446 TLS 2018年8月
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 [RFC4492])
Sun Microsystems Laboratories
vipul.gupta@sun.com
Chris Hawk
(co-author of [RFC4492])
Corriente Networks LLC
chris@corriente.net
Kipp Hickman
Alfred Hoenes
David Hopwood
Independent Consultant
david.hopwood@blueyonder.co.uk
Rescorla Standards Track [Page 155]
RFC 8446 TLS 2018年8月
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 [RFC7627])
Google
agl@google.com
Olivier Levillain
ANSSI
olivier.levillain@ssi.gouv.fr
Rescorla Standards Track [Page 156]
RFC 8446 TLS 2018年8月
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 [RFC4492])
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
Rescorla Standards Track [Page 157]
RFC 8446 TLS 2018年8月
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 [RFC7627])
INRIA
alfredo.pironti@inria.fr
Andrei Popov
Microsoft
andrei.popov@microsoft.com
Marsh Ray
(co-author of [RFC7627])
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
Rescorla Standards Track [Page 158]
RFC 8446 TLS 2018年8月
Sam Scott
Royal Holloway, University of London
me@samjs.co.uk
Thomas Shrimpton
University of Florida
teshrim@ufl.edu
Dan Simon
Microsoft, Inc.
dansimon@microsoft.com
Brian Smith
Independent
brian@briansmith.org
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
Rescorla Standards Track [Page 159]
RFC 8446 TLS 2018年8月
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
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
Author's Address
Eric Rescorla
Mozilla
Email: ekr@rtfm.com
Rescorla Standards Track [Page 160]