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

5. Applicability Statement (適用性宣言)

5. Applicability Statement (適用性宣言)

本文書の推奨事項は主に, 今日インターネット上で TLS および DTLS と最も一般的に使用されるアプリケーションプロトコルの実装とデプロイに適用されます。例には以下が含まれますが, これらに限定されません:

  • TLS で HTTP トラフィックを保護したい Web ソフトウェアとサービス。

  • TLS で IMAP, POP3, または SMTP トラフィックを保護したい電子メールソフトウェアとサービス。

  • TLS で Extensible Messaging and Presence Protocol (XMPP) または Internet Relay Chat (IRC) トラフィックを保護したいインスタントメッセージングソフトウェアとサービス。

  • DTLS で Secure Realtime Transport Protocol (SRTP) トラフィックを保護したいリアルタイムメディアソフトウェアとサービス。

本文書は TLS または DTLS を使用する既存のアプリケーションプロトコルによって規定される実装とデプロイの推奨事項 (たとえば, 実装必須暗号スイート) を変更しません。そのようなアプリケーションプロトコルを使用するコミュニティが, ここで推奨されるベストプラクティスと一致するように TLS または DTLS の使用を現代化したい場合, 既存のアプリケーションプロトコル定義を明示的に更新する必要があります (一例は [TLS-XMPP] で, [RFC6120] を更新します)。

Internet Standards Process [RFC2026] を通じて開発された新しいアプリケーションプロトコルの設計者は, やむを得ない理由のドキュメントを提供しない限り (たとえば, 必要なアルゴリズムのサポートが不足している制約のあるデバイスでの広範なデプロイ), 最低限ここで推奨されるベストプラクティスに準拠することが期待されます。

5.1. Security Services (セキュリティサービス)

本文書は, 以下を達成するために TLS で通信を保護したい聴衆に推奨事項を提供します:

  • 機密性 (Confidentiality): すべてのアプリケーション層通信は暗号化され, 意図された受信者以外の誰もそれを復号化できないことが目標です。

  • データ整合性 (Data integrity): 転送中に通信に加えられた変更は受信者によって検出可能です。

  • 認証 (Authentication): TLS 通信のエンドポイントは, 通信することを意図されたエンティティとして認証されます。

認証に関して, TLS は通信における一方または両方のエンドポイントの認証を可能にします。日和見セキュリティ [RFC7435] のコンテキストでは, TLS は認証なしで使用されることがあります。セクション 5.2 で説明されているように, 日和見セキュリティの考慮事項は本文書の範囲外です。

デプロイ担当者が本文書で与えられた推奨事項から逸脱する場合, 前述のセキュリティサービスの 1 つへのアクセスを失う可能性があることを認識する必要があります。

本文書は機密性が必要な環境にのみ適用されます。転送中のデータの秘密性を強制するアルゴリズムと構成オプションを推奨します。

本文書はまた, データ整合性保護が常にデプロイの目標の 1 つであることを前提としています。整合性が必要ない場合, そもそも TLS を使用することは意味がありません。機密性のみの保護に対する攻撃があり, 整合性の欠如を利用して機密性も破ります (たとえば, IPsec のコンテキストで [DegabrieleP07] を参照)。

本文書は TLS および DTLS と共にインターネット上で最も一般的に使用されるアプリケーションプロトコルを対象としています。通常, TLS クライアントと TLS サーバー間のすべての通信には上記の 3 つのセキュリティサービスすべてが必要です。これは TLS クライアントが Web ブラウザや電子メールソフトウェアなどのユーザーエージェントである場合に特に当てはまります。

本文書は上記の 3 つのプロパティの 1 つが望ましくないまれなデプロイシナリオには対処しません。たとえば, 以下のセクション 5.2 で説明されているユースケースなどです。機密性が必要ないもう 1 つのシナリオとして, それぞれのトラフィックドメインを担当する当局が暗号化されていない (プレーンテキスト) トラフィックへの完全なアクセスを要求し, ユーザーが協力してトラフィックをクリアで送信する監視ネットワークを考えてみてください。

5.2. Opportunistic Security (日和見セキュリティ)

TLS の使用がオプショナルであるいくつかの重要なシナリオがあります。つまり, クライアントが特定のサーバーで TLS を使用するかクリアで接続するかを動的に (「日和見的に」) 決定します。このプラクティスは「日和見セキュリティ」と呼ばれることが多く, [RFC7435] で詳しく説明されており, レガシーデプロイとの下位互換性を望むことによって動機付けられることが多いです。

これらのシナリオでは, 本文書の推奨事項の一部は厳格すぎる可能性があります。それらに従うことがクリアテキストへのフォールバックを引き起こす可能性があるためです。これは古いプロトコルバージョンや暗号スイートで TLS を使用するよりも悪い結果です。

本文書は TLS 全般のベストプラクティスを指定します。日和見セキュリティでの TLS の使用に関する推奨事項を含む別の文書は将来完成される予定です。