短命鍵交換とNULL暗号化を備えたTLS暗号スイートとは
次の暗号の利点について疑問に思います。
- TLS_ECDHE_PSK_WITH_NULL_SHA256
- TLS_ECDHE_ECDSA_WITH_NULL_SHA
そもそも暗号化したくないのに、なぜ完全転送秘密にすべきなのですか？ Authenticity/Integrityに行きたいだけです。
これらの暗号がレジストリに記載されているのはなぜですか？完全を期すためですか、それとも重要なユースケースを見落としているのですか？
NULL暗号化はRFC 4785の後に導入されました。RFC4785は、さまざまなインポート制限のサポートを導入しました。
RFCの引用：
機密性が許可されない場合もあります。たとえば、一部の国では輸入制限を満たさなければならない実装などです。暗号化は使用されていませんが、これらの暗号スイートは、クライアントとサーバーの相互認証とメッセージの整合性をサポートしています。
リファレンス： https://tools.ietf.org/html/rfc4785
このドキュメントで定義されている暗号スイートは、通常は非常に少数のクライアントとサーバーしか関与しない、かなり限定されたアプリケーションセットを対象としています。このような環境でも、他の代替手段がより適切な場合があります。
私が知る限り、それらは完全性のためにのみ存在します。 RFC 5489 で最初に定義されたPSK暗号スイート（およびそのいくつか）は、意味のあるコメントなしで、以下のみです。
次の暗号スイートは、セクション3.1で定義された暗号スイートと一致しますが、NULL暗号化でスイートを定義する点が異なります。
および同様。
ECDHE_ECDSA暗号スイートの定義は、コメントがまったくないため、さらに冗長ではありませんが、 RFC 4492 の定義を見ると、状況は同じです。定義される暗号スイートのリストは、サポートされている鍵交換、認証、および暗号化アルゴリズム（NULLを含む）の各組み合わせを列挙する単純な繰り返しリストです。