メインコンテンツまでスキップ

1. Introduction (はじめに)

TLSの主な目標は, 通信する2つのピア間にセキュアチャネル (Secure Channel) を提供することです。基盤となるトランスポートに対する唯一の要件は, 信頼性があり順序付けられたデータストリームです。具体的には, セキュアチャネルは以下の特性を提供する必要があります:

  • Authentication (認証): チャネルのサーバー側は常に認証され, クライアント側はオプションで認証されます。認証は非対称暗号 (Asymmetric Cryptography) (例: RSA [RSA], 楕円曲線デジタル署名アルゴリズム (ECDSA) [ECDSA], またはEdwards曲線デジタル署名アルゴリズム (EdDSA) [RFC8032]) または対称事前共有鍵 (PSK) を介して行うことができます。

  • Confidentiality (機密性): 確立後にチャネルを介して送信されるデータは, エンドポイントのみに可視です。TLSは送信するデータの長さを隠しませんが, エンドポイントはTLSレコードにパディングを追加して長さを難読化し, トラフィック分析技術に対する保護を改善できます。

  • Integrity (完全性): 確立後にチャネルを介して送信されるデータは, 検出されずに攻撃者によって変更されることはできません。

これらの特性は, [RFC3552]で説明されているように, 攻撃者がネットワークを完全に制御している場合でも成立する必要があります。関連するセキュリティ特性のより完全な説明については, 付録Eを参照してください。

TLSは2つの主要コンポーネントで構成されます:

  • Handshake Protocol (ハンドシェイクプロトコル) (セクション4), 通信当事者を認証し, 暗号化モードとパラメータを交渉し, 共有鍵材料を確立します。ハンドシェイクプロトコルは改ざんに耐性があるように設計されており, アクティブな攻撃者は接続が攻撃を受けていない場合とは異なるパラメータをピアに強制的に交渉させることができないようになっています。

  • Record Protocol (レコードプロトコル) (セクション5), ハンドシェイクプロトコルによって確立されたパラメータを使用して, 通信ピア間のトラフィックを保護します。レコードプロトコルはトラフィックを一連のレコードに分割し, それぞれがトラフィック鍵を使用して独立して保護されます。

TLSはアプリケーションプロトコルに依存しません。上位層プロトコルはTLS上に透過的に層状化できます。ただし, TLS標準はプロトコルがTLSでセキュリティを追加する方法を規定していません。TLSハンドシェイクを開始する方法と交換された認証証明書を解釈する方法は, TLS上で実行されるプロトコルの設計者と実装者の判断に委ねられています。

この文書はTLSバージョン1.3を定義します。TLS 1.3は以前のバージョンと直接互換性はありませんが, すべてのバージョンのTLSにはバージョニングメカニズムが組み込まれており, 両方のピアがサポートする場合, クライアントとサーバーが共通バージョンを相互運用可能に交渉できます。

この文書は, バージョン1.2 [RFC5246]を含むTLSの以前のバージョンを置き換え, 廃止します。また, [RFC5077]で定義されたTLSチケットメカニズムを廃止し, セクション2.2で定義されたメカニズムに置き換えます。TLS 1.3は鍵の導出方法を変更するため, セクション7.5で説明されているように[RFC5705]を更新します。また, オンライン証明書ステータスプロトコル (OCSP) メッセージの運搬方法を変更するため, セクション4.4.2.1で説明されているように[RFC6066]を更新し, [RFC6961]を廃止します。

1.1 Conventions and Terminology (規約と用語)​

この文書のキーワード「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」は議論の主題ではないエンドポイントを指します。

receiver (受信者): レコードを受信しているエンドポイント。

sender (送信者): レコードを送信しているエンドポイント。

server (サーバー): TLS接続を開始しなかったエンドポイント。

1.2 Major Differences from TLS 1.2 (TLS 1.2との主な違い)​

以下は, TLS 1.2とTLS 1.3の間の主な機能上の違いのリストです。これは網羅的ではなく, 多くの細かい違いがあります。

  • サポートされる対称暗号化アルゴリズムのリストから, レガシーと見なされるすべてのアルゴリズムが削除されました。残っているのはすべて関連データ付き認証暗号 (AEAD) アルゴリズムです。Cipher Suite (暗号スイート) の概念が変更され, 認証と鍵交換メカニズムをレコード保護アルゴリズム (秘密鍵長を含む) および鍵導出関数とハンドシェイクメッセージ認証コード (MAC) で使用されるハッシュから分離しました。

  • Zero Round-Trip Time (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は, 各曲線に単一のポイント形式を使用するため, ポイント形式の交渉を削除しました。

  • 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 Updates Affecting TLS 1.2 (TLS 1.2に影響する更新)​

この文書は, TLS 1.3をサポートしない実装を含む, TLS 1.2実装にオプションで影響を与えるいくつかの変更を定義します:

  • バージョンダウングレード保護メカニズムがセクション4.1.3で説明されています。

  • RSASSA-PSS署名スキームがセクション4.2.3で定義されています。

  • "supported_versions" ClientHello拡張を使用して, ClientHelloのlegacy_versionフィールドよりも優先的に使用するTLSバージョンを交渉できます。

  • "signature_algorithms_cert"拡張により, クライアントはX.509証明書で検証できる署名アルゴリズムを示すことができます。

さらに, この文書は以前のバージョンのTLSに対するいくつかの適合要件を明確にしています。セクション9.3を参照してください。

に最終更新