5. 適用性声明

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

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

• IMAP、Post Office Protocol バージョン 3 (POP3)、または SMTP トラフィックを TLS で保護したい電子メールソフトウェアおよびサービス。

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

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

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

インターネット標準化プロセス [RFC2026] を通じて開発された新しいアプリケーションプロトコルの設計者は、そのような適合を妨げる説得力のある理由の文書 (たとえば、必要なアルゴリズムのサポートが不足している制約のあるデバイスへの広範な展開など) を提供しない限り、少なくともここで推奨されているベストプラクティスに適合することが期待されます。

ここで提供される推奨事項の多くは、TLS 1.3 ハンドシェイクプロトコルを使用する限り QUIC にも適用される可能性がありますが、QUIC およびその他のそのような安全なトランスポートプロトコルは本書の範囲外です。QUIC については、特に読者は [RFC9001] のセクション 9.2 を参照してください。

本書では、制約のあるノードネットワーク [RFC7228] での TLS の使用については触れていません。電力、メモリ、および処理リソースに厳しい制約がある小型デバイス向けの TLS および DTLS のプロファイリングに関する推奨事項については、読者は [RFC7925] および [IOT-PROFILE] を参照してください。

5.1. セキュリティサービス

本書は、TLS との通信を保護して以下を達成したいと考えている人々向けの推奨事項を提供します。

機密性: すべてのアプリケーション層通信は、意図された受信者以外の当事者が復号化できないように暗号化されます。

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

認証: TLS 通信のエンドポイントは、通信する意図されたエンティティとして認証されます。

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

展開者が本書に記載されている推奨事項から逸脱する場合、前述のセキュリティサービスの 1 つへのアクセスを失う可能性があることに注意する必要があります。

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

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

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

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

5.2. 日和見セキュリティ

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

これらのシナリオでは、本書の推奨事項の一部が厳しすぎる可能性があります。それらに準拠すると、古いプロトコルバージョンまたは暗号スイートで TLS を使用するよりも悪い結果である平文へのフォールバックが発生する可能性があるためです。