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

本文書は、TLSで通信を保護して以下を達成したいオーディエンスに対する推奨事項を提供します:

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

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

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

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

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

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

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

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

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