1. はじめに

Transport Layer Security (TLS) および Datagram Transport Layer Security (DTLS) は、HTTP [RFC9112] [RFC9113]、IMAP [RFC9051]、Post Office Protocol (POP) [STD53]、SIP [RFC3261]、SMTP [RFC5321]、Extensible Messaging and Presence Protocol (XMPP) [RFC6120] など、多種多様なアプリケーションプロトコル上で交換されるデータを保護するために使用されます。このようなプロトコルは、TLS または DTLS ハンドシェイクプロトコルと、TLS または DTLS レコードレイヤーの両方を使用します。TLS ハンドシェイクプロトコルは、別のレコードレイヤーと一緒に使用して安全なトランスポートプロトコル（最も顕著な例は QUIC [RFC9000]）を定義することもできますが、そのようなトランスポートプロトコルは本書の範囲に直接含まれません。それにもかかわらず、そのようなプロトコルが TLS ハンドシェイクプロトコルを使用する限り、ここの推奨事項の多くが適用される可能性があります。

2015年に至るまでの数年間、業界は TLS および DTLS に対する深刻な攻撃を目の当たりにしてきました。これには、最も一般的に使用される暗号スイートとその動作モードに対する攻撃が含まれます。たとえば、かつて最も広く展開されていた暗号である AES-CBC [RFC3602] と RC4 [RFC7465] 暗号化アルゴリズムは、TLS のコンテキストで攻撃されました。2015年以前に知られていた攻撃に関する詳細情報は、TLS 推奨事項の以前のバージョン [RFC7525] の関連ドキュメント [RFC7457] に記載されており、読者がここで提供される推奨事項の背後にある根拠を理解するのに役立ちます。そのドキュメントは本書と合わせて更新されていません。その代わりに、新しい攻撃とそれらの攻撃に対する緩和策が本書で説明されています。

TLS コミュニティは、[RFC7457] で説明されている攻撃に対していくつかの方法で対応しました。

• 初期のプロトコルバージョンとともに、TLS 1.2 [RFC5246] および DTLS 1.2 [RFC6347] の使用に関する詳細なガイダンスが公開されました。このガイダンスは元の [RFC7525] に含まれており、この改訂版でも大部分が保持されています。このガイダンスは、2015年の RFC 7525 の発行以来、業界で大部分採用されていることに注意してください。

• 1.2 以前の TLS バージョンは廃止されました [RFC8996]。

• TLS のバージョン 1.3 [RFC8446] がリリースされ、続いて DTLS のバージョン 1.3 [RFC9147] がリリースされました。これらのバージョンは、記載されている攻撃を大幅に緩和または解決します。

TLS および TLS ベースのプロトコルを実装および展開する人々は、それらを安全に使用する方法に関するガイダンスを必要としています。本書は、実装者が自分のコードがセクション 5 で定義された環境に展開されることを期待していると仮定して、展開済みサービスとソフトウェア実装の両方に対するガイダンスを提供します。展開に関しては、本書は幅広い対象者、つまり通信に認証（一方向のみまたは相互）、機密性、およびデータ整合性保護を追加したいすべての展開者を対象としています。

ここでの推奨事項は、さまざまなメカニズムのセキュリティ、技術的な成熟度と相互運用性、および執筆時点での実装における普及率を考慮に入れています。推奨事項が TLS のみに適用されるか、DTLS のみに適用されることが明示的に呼びかけられていない限り、各推奨事項は TLS と DTLS の両方に適用されます。

本書は、TLS 1.2 実装への新しいガイダンスを最小限に抑えるよう努めており、全体的なアプローチはシステムに TLS 1.3 への移行を促すことです。ただし、これが常に実用的であるとは限りません。新しく発見された攻撃やエコシステムの変更により、TLS 1.2 環境に適用されるいくつかの新しい要件が必要になりました。これらは付録 A にまとめられています。

当然のことながら、将来の攻撃の可能性があり、本書はそれらに対処できません。TLS/DTLS および TLS/DTLS に基づくプロトコルを実装および展開する人々は、将来の動向に注意を払うことを強くお勧めします。特に、量子コンピュータの作成が暗号化プリミティブとそれらを使用する技術のセキュリティに大きな影響を与えることが知られていますが、現在、耐量子暗号は進行中の作業であり、推奨を行うには時期尚早です。関連する仕様が IETF またはその他の場所で標準化されたら、その時点でのベストプラクティスを反映するように本書を更新する必要があります。

前述のように、TLS 1.3 仕様は本書にリストされている脆弱性の多くを解決します。TLS 1.3 を展開するシステムは、TLS 1.2 以下よりも脆弱性が少ないはずです。したがって、本書は [RFC7525] を置き換え、TLS 1.2 の使用の大部分を TLS 1.3 に移行することを奨励するという明確な目標を持っています。

これらは、認証されていない TLS（セクション 5 を参照）を除き、実装および展開シナリオの大部分で TLS を使用するための最小限の推奨事項です。本書を参照する他の仕様には、特定の状況（たとえば、特定のアプリケーションプロトコルでの使用など）に基づいて、プロトコルの 1 つ以上の側面に関連するより厳しい要件がある場合があります。その場合、実装者はそれらのより厳しい要件に従うことをお勧めします。さらに、本書は天井ではなく床を提供します。可能な場合、サービスの管理者は、実装で利用可能な最小限のサポートを超えて、可能な限り強力なセキュリティを提供することをお勧めします。たとえば、既存のアプリケーションプロトコルの展開ベースに関する知識と、セキュリティの強度対相互運用性に関する費用対効果分析に基づいて、特定のサービスプロバイダーは TLS 1.2 を完全に無効にし、TLS 1.3 のみを提供することを決定する場合があります。

さまざまなアルゴリズムの強度と実行可能な攻撃に関するコミュニティの知識は急速に変化する可能性があり、経験上、セキュリティに関するベストカレントプラクティス (BCP) ドキュメントは、その時点での声明です。読者は、本書に適用される誤植や更新を探すことをお勧めします。

本書は、[Boeck2016] 攻撃を考慮して [RFC5288] を更新します。詳細はセクション 7.2.1 を参照してください。

本書は、[ALPACA] 攻撃を考慮して [RFC6066] を更新します。詳細はセクション 3.7 を参照してください。