4. Recommendations - Cipher Suites (推奨事項 - 暗号スイート)

4. Recommendations: Cipher Suites (推奨事項: 暗号スイート)

TLS とその実装は暗号スイートの選択において相当な柔軟性を提供します。残念ながら, 利用可能な暗号スイートの一部は安全でなく, 一部は対象のセキュリティサービスを提供せず, 一部はもはや十分なセキュリティを提供していません。サーバーを誤って構成するとセキュリティがないか低下します。このセクションには暗号スイートの選択とネゴシエーションに関する推奨事項が含まれています。

4.1. General Guidelines (一般的なガイドライン)

暗号アルゴリズムは暗号解析が改善されるにつれて時間とともに弱体化します。かつて強力と見なされたアルゴリズムは弱くなります。そのようなアルゴリズムは時間をかけて段階的に廃止し, より安全な暗号スイートに置き換える必要があります。これにより, 望ましいセキュリティプロパティが依然として保持されることが保証されます。SSL/TLS はほぼ 20 年間存在しており, SSL/TLS のさまざまなバージョンで推奨されてきた暗号スイートの多くは現在弱いと見なされているか, 少なくとも望ましいほど強力ではありません。したがって, このセクションは暗号スイート選択に関する推奨事項を現代化します。

実装は NULL 暗号化を使用する暗号スイートをネゴシエーションしてはなりません (MUST NOT)。

理論的根拠: NULL 暗号スイートはトラフィックを暗号化しないため, 機密性サービスを提供しません。ネットワーク内で接続にアクセスできる任意のエンティティが, クライアントとサーバーによって交換されるコンテンツのプレーンテキストを表示できます。(それにもかかわらず, 本文書は NULL 暗号スイートの実装をソフトウェアに実装することを妨げません。テストやデバッグに有用な場合があるためです。)
実装は RC4 暗号スイートをネゴシエーションしてはなりません (MUST NOT)。

理論的根拠: RC4 ストリーム暗号には [RFC7465] に文書化されているようにさまざまな暗号的弱点があります。DTLS は RC4 の使用をすでに具体的に禁止していることに注意してください。
実装は 112 ビット未満のセキュリティを提供する暗号スイート (いわゆる「エクスポートレベル」暗号化 (40 または 56 ビットのセキュリティを提供) を含む) をネゴシエーションしてはなりません (MUST NOT)。

理論的根拠: [RFC3766] に基づいて, 少なくとも 112 ビットのセキュリティが必要です。40 ビットと 56 ビットのセキュリティは今日では安全でないと見なされています。TLS 1.1 と 1.2 は 40 ビットまたは 56 ビットのエクスポート暗号をネゴシエーションしません。
実装は 128 ビット未満のセキュリティを提供するアルゴリズムを使用する暗号スイートをネゴシエーションすべきではありません (SHOULD NOT)。

理論的根拠: 112 ビットから 128 ビットのセキュリティを提供する暗号スイートは現時点では弱いとは見なされていません。ただし, その有用な寿命は現時点でより強力な暗号スイートをサポートすることを正当化するのに十分短いと予想されます。128 ビット暗号は少なくとも数年間安全であり続けることが期待され, 256 ビット暗号は次の根本的な技術的ブレークスルーまで安全です。いわゆる「中間一致」攻撃 [Multiple-Encryption] のため, 一部のレガシー暗号スイート (たとえば, 168 ビット 3DES) は名目上の鍵長よりも小さい有効鍵長 (3DES の場合 112 ビット) を持つことに注意してください。そのような暗号スイートは有効鍵長に従って評価されるべきです。
実装は RSA 鍵トランスポート (別名「静的 RSA」) に基づく暗号スイートをネゴシエーションすべきではありません (SHOULD NOT)。

理論的根拠: これらの暗号スイートは文字列「TLS_RSA_WITH_*」で始まる割り当てられた値を持ち, いくつかの欠点があります。特に前方秘匿性をサポートしていないという事実があります。
実装は, Ephemeral Diffie-Hellman および Elliptic Curve Ephemeral Diffie-Hellman (「DHE」および「ECDHE」) ファミリーなど, 前方秘匿性を提供する暗号スイートをサポートし, ネゴシエーションを優先しなければなりません (MUST)。

理論的根拠: 前方秘匿性 (「完全前方秘匿性」と呼ばれることもあります) は, 古いセッション鍵で暗号化された情報の回復を防ぎ, 攻撃が成功する時間を制限します。詳細な議論についてはセクション 6.3 を参照してください。

4.2. Recommended Cipher Suites (推奨される暗号スイート)

前述の考慮事項を考えると, 以下の暗号スイートの実装とデプロイが推奨されます (RECOMMENDED):

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

これらの暗号スイートは認証暗号化 (AEAD) アルゴリズム [RFC5116] であるため, TLS 1.2 でのみサポートされています。

通常, これらのスイートを優先するには, サーバーソフトウェアでスイートの順序を明示的に構成する必要があります。(有用なデプロイガイドラインについては [BETTERCRYPTO] を参照してください。ただし, その推奨事項はいくつかの詳細で現在の文書とは異なることに注意してください。) サーバーソフトウェア実装がデフォルトでこれらのスイートを優先することが理想的です。

一部のデバイスには AES-GCM のハードウェアサポートがあるが AES-CCM のサポートがないため, 暗号スイートに関する前述の推奨事項に従うことができません。公開鍵暗号をまったくサポートしないデバイスも存在しますが, それらは完全に範囲外です。

4.2.1. Implementation Details (実装の詳細)

クライアントは, サーバーが TLS 1.2 client_hello メッセージに応答できないという事前の知識がない限り, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 を任意のサーバーへの最初の提案として含めるべきです (SHOULD)。

サーバーは, 最初の提案でない場合でも, 提案された場合は常に, より弱い暗号スイートよりもこの暗号スイートを優先しなければなりません (MUST)。

クライアントはもちろん, AES-256 を使用するなど, より強力な暗号スイートを提供することができます。その場合, サーバーは, やむを得ない理由 (たとえば, 深刻なパフォーマンスの低下) がない限り, より強力な暗号スイートを優先すべきです (SHOULD)。

本文書は TLS で規定されている実装必須の TLS 暗号スイートを変更しません。相互運用性を最大化するため, RFC 5246 は TLS_RSA_WITH_AES_128_CBC_SHA 暗号スイートの実装を義務付けています。これはここで推奨される暗号スイートよりも大幅に弱いものです。(GCM モードは AEAD 動作モードを使用するため, TLS における MAC-then-Encrypt の順序によって引き起こされる同じ弱点 [Krawczyk2001] に悩まされません。) 実装者は TLS_RSA_WITH_AES_128_CBC_SHA 暗号スイートをデプロイする際, 相互運用性の利点とセキュリティの損失を考慮すべきです。他のアプリケーションプロトコルは実装必須 (MTI) として他の暗号スイートを指定しています。

TLS 1.2 の一部のプロファイルは異なる暗号スイートを使用することに注意してください。たとえば, [RFC6460] は TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 および TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 暗号スイートを使用するプロファイルを定義しています。

[RFC4492] はクライアントとサーバーが ECDH パラメータ (曲線) をネゴシエーションすることを許可しています。クライアントとサーバーの両方が「Supported Elliptic Curves」拡張 [RFC4492] を含めるべきです (SHOULD)。相互運用性のため, クライアントとサーバーは NIST P-256 (secp256r1) 曲線 [RFC4492] をサポートすべきです (SHOULD)。さらに, クライアントは単一の要素「uncompressed」を持つ ec_point_formats 拡張を送信すべきです (SHOULD)。

4.3. Public Key Length (公開鍵長)

本文書で推奨される暗号スイートを使用する場合, TLS ハンドシェイクでは通常 2 つの公開鍵が使用されます。1 つは Diffie-Hellman 鍵交換用, もう 1 つはサーバー認証用です。クライアント証明書が使用される場合, 3 番目の公開鍵が追加されます。

モジュラー指数 (MODP) Diffie-Hellman グループ (「DHE」暗号スイート) に基づく鍵交換では, 少なくとも 2048 ビットの DH 鍵長が推奨されます (RECOMMENDED)。

理論的根拠: さまざまな理由から, 実際には DH 鍵は通常 2 のべき乗の長さで生成されます (たとえば, 2^10 = 1024 ビット, 2^11 = 2048 ビット, 2^12 = 4096 ビット)。1228 ビットの DH 鍵は約 80 ビットの対称鍵とほぼ同等であるため [RFC3766], 「DHE」ファミリーの暗号スイートにはそれよりも長い鍵を使用する方が良いです。1926 ビットの DH 鍵は約 100 ビットの対称鍵とほぼ同等であり [RFC3766], 2048 ビットの DH 鍵は少なくとも今後 10 年間は十分かもしれません [NIST.SP.800-56A]。TLS での MODP Diffie-Hellman の使用に関する追加情報についてはセクション 4.4 を参照してください。

[RFC3766] で述べられているように, TWIRL マシンの出現を補正すると, 1024 ビット DH 鍵は約 65 ビットの等価強度を生成し, 2048 ビット DH 鍵は約 92 ビットの等価強度を生成することになります。

ECDH 鍵に関して, IANA「EC Named Curve Registry」(「Transport Layer Security (TLS) Parameters」レジストリ [IANA-TLS] 内) には, わずか 80 ビットの対称鍵とほぼ同等と見なされる 160 ビット楕円曲線が含まれています [ECRYPT-II]。192 ビット未満の曲線は使用すべきではありません (SHOULD NOT)。

RSA を使用する場合, サーバーは公開鍵に対して少なくとも 2048 ビットのモジュラスを持つ証明書を使用して認証すべきです (SHOULD)。さらに, SHA-256 ハッシュアルゴリズムの使用が推奨されます (RECOMMENDED) (詳細については [CAB-Baseline] を参照)。クライアントは TLS 1.2 で定義されている「Signature Algorithms」拡張を使用して, SHA-256 を要求することをサーバーに示すべきです (SHOULD)。

4.4. Modular Exponential vs. Elliptic Curve DH Cipher Suites

すべての TLS 実装が, セクション 4.2 で要求されているように, モジュラー指数 (MODP) と楕円曲線 (EC) Diffie-Hellman グループの両方をサポートしているわけではありません。一部の実装は DH 値の長さに深刻な制限があります。そのような実装に対応する必要がある場合, 以下が推奨されます (RECOMMENDED) (優先順):

適切にネゴシエーションされたパラメータ (たとえば, 使用する曲線) と HMAC-SHA1 よりも強力なメッセージ認証コード (MAC) アルゴリズムを持つ楕円曲線 DHE [RFC5289]
2048 ビット Diffie-Hellman パラメータを持つ TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288]
1024 ビットパラメータを持つ TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

理論的根拠: 楕円曲線暗号は広く展開されていますが, その採用がいくつかの理由から制限されているコミュニティがあります。複雑さがモジュラー演算と比較して複雑であること, および IPR の懸念に関する長年の認識 (その大部分は現在解決されています [RFC6090]) が含まれます。ECDHE 暗号スイートは RSA 証明書と ECDSA 証明書の両方に存在するため, ECDHE 暗号スイートに移行しても RSA ベースの証明書から離れる必要はないことに注意してください。一方, TLS で MODP Diffie-Hellman 暗号スイートの効果的な使用を妨げる 2 つの関連する問題があります:

クライアントとサーバーがサポートする DH グループまたはパラメータ長をネゴシエーションするための標準化され広く実装されたプロトコルメカニズムがありません。
多くのサーバーは 1024 ビット以下の DH パラメータを選択します。
受信した DH パラメータが 1024 ビットより長い場合に拒否する広く展開されたクライアント実装があります。さらに, いくつかの実装はグループパラメータの適切な検証を実行せず, [RFC7457] のセクション 2.9 で参照されている攻撃に対して脆弱です。

DHE および ECDHE 暗号スイートでは, TLS マスター鍵は Diffie-Hellman パラメータにのみ依存し, RSA 証明書の強度には依存しないことに注意してください。さらに, 1024 ビット MODP DH パラメータは現時点では一般的に不十分と見なされています。

MODP ephemeral DH を使用する場合, デプロイ担当者は TLS エンドポイントを構成する際に相互運用性とセキュリティの考慮事項を慎重に評価すべきです。

4.5. Truncated HMAC

実装は [RFC6066] のセクション 7 で定義されている Truncated HMAC 拡張を使用してはなりません (MUST NOT)。

理論的根拠: この拡張は上記で推奨される AEAD 暗号スイートには適用されません。ただし, 他のほとんどの TLS 暗号スイートには適用されます。その使用は [PatersonRS11] で安全でないことが示されています。