4. 推奨事項: 暗号スイート

TLS 1.2 は、暗号スイートの選択においてかなりの柔軟性を提供しました。残念ながら、これらの暗号スイートの一部のセキュリティは時間の経過とともに低下し、一部は安全でないことがわかっています (これは TLS 1.3 がそのような柔軟性を制限した理由の 1 つです)。サーバーを誤って構成すると、セキュリティがないか、セキュリティが低下します。このセクションには、暗号スイートの選択とネゴシエーションに関する推奨事項が含まれています。

4.1. 一般的なガイドライン

暗号解読が向上するにつれて、暗号化アルゴリズムは時間の経過とともに弱くなります。かつて強力と見なされていたアルゴリズムが弱くなります。その結果、弱いアルゴリズムを使用する暗号スイートは段階的に廃止し、より安全な暗号スイートに置き換える必要があります。これにより、望ましいセキュリティプロパティが引き続き保持されることが保証されます。SSL/TLS は 20 年以上存在しており、SSL/TLS のさまざまなバージョンで推奨されている暗号スイートの多くは、現在では弱いか、少なくとも望ましいほど強力ではないと見なされています。したがって、このセクションでは、暗号スイートの選択に関する推奨事項を最新化します。

• 実装は NULL 暗号化の暗号スイートをネゴシエートしてはなりません (MUST NOT)。

  理由: NULL 暗号スイートはトラフィックを暗号化しないため、機密性サービスを提供しません。接続にアクセスできるネットワーク内のエンティティは、クライアントとサーバーによって交換されているコンテンツの平文を表示できます。それにもかかわらず、本書はソフトウェアが NULL 暗号スイートを実装することを推奨しません。これは、テストやデバッグに役立つ可能性があるためです。

• 実装は RC4 暗号スイートをネゴシエートしてはなりません (MUST NOT)。

  理由: RC4 ストリーム暗号には、[RFC7465] に文書化されているように、さまざまな暗号化の弱点があります。DTLS はすでに RC4 の使用を具体的に禁止していることに注意してください。

• 実装は、「輸出レベル」の暗号化 (40 ビットまたは 56 ビットのセキュリティを提供する) を含め、112 ビット未満のセキュリティを提供する暗号スイートをネゴシエートしてはなりません (MUST NOT)。

  理由: [RFC3766] に基づくと、少なくとも 112 ビットのセキュリティが必要です。40 ビットと 56 ビットのセキュリティ (いわゆる「輸出暗号」に見られる) は、今日では安全ではないと見なされています。

• 実装は、128 ビット未満のセキュリティを提供するアルゴリズムを使用する暗号スイートをネゴシエートすべきではありません (SHOULD NOT)。

  理由: 112 ビット以上 128 ビット未満のセキュリティを提供する暗号スイートは、現時点では弱いとは見なされません。ただし、それらの有用な寿命は、現時点でより強力な暗号スイートをサポートすることを正当化するのに十分短いと予想されます。128 ビット暗号は少なくとも数年間は安全であり、256 ビット暗号は次の基本的な技術革新まで安全であると予想されます。いわゆる「中間一致」攻撃 [Multiple-Encryption] により、一部のレガシー暗号スイート (例: 168 ビット Triple DES (3DES)) の有効鍵長はその公称鍵長 (3DES の場合は 112 ビット) よりも小さいことに注意してください。このような暗号スイートは、有効鍵長に従って評価する必要があります。

• 実装は、RSA 鍵転送、別名「静的 RSA」に基づく暗号スイートをネゴシエートすべきではありません (SHOULD NOT)。

  理由: これらの暗号スイートは、文字列 "TLS_RSA_WITH_*" で始まる値が割り当てられており、いくつかの欠点、特に前方秘匿性をサポートしていないという事実があります。

• 実装は、非一時的 (静的) 有限体 Diffie-Hellman (DH) 鍵合意に基づく暗号スイートをネゴシエートすべきではありません (SHOULD NOT)。同様に、実装は非一時的 Elliptic Curve DH 鍵合意をネゴシエートすべきではありません (SHOULD NOT)。

  理由: 前者の暗号スイートは "TLS_DH_" という接頭辞が付いた値が割り当てられており、いくつかの欠点、特に前方秘匿性をサポートしていないという事実があります。後者 ("TLS_ECDH_") も前方秘匿性を欠いており、無効曲線攻撃 [Jager2015] の対象となります。

• 実装は、前方秘匿性を提供する暗号スイートをサポートし、優先してネゴシエートしなければなりません (MUST)。ただし、TLS 1.2 実装は、一時的有限体 Diffie-Hellman 鍵合意に基づく暗号スイート (つまり "TLS_DHE_*" スイート) をネゴシエートすべきではありません (SHOULD NOT)。これは、構成の既知の脆弱性 ([RACCOON] を参照) と、非常に限られた利用しか見られない [RFC7919] の使用を含むネゴシエーションに関する制限によって正当化されます。

  理由: 前方秘匿性 (「完全前方秘匿性」と呼ばれることもある) は、古いセッション鍵で暗号化された情報の回復を防ぎ、攻撃が成功したときにデータをどれだけ遡って復号化できるかを制限します。詳細な議論については、セクション 7.3 および 7.4 を参照してください。

4.2. TLS 1.2 の暗号スイート

前述の考慮事項を念頭に置いて、以下の暗号スイートの実装と展開が推奨されます (RECOMMENDED)。

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

これらは Authenticated Encryption with Associated Data (AEAD) アルゴリズム [RFC5116] であるため、これらの暗号スイートは TLS 1.2 でのみサポートされ、以前のプロトコルバージョンではサポートされません。

通常、これらのスイートを優先するには、サーバーソフトウェアでスイートの順序を明示的に構成する必要があります。サーバーソフトウェアの実装がデフォルトでこれらのスイートを優先するのが理想的です。

一部のデバイスには AES Counter Mode with CBC-MAC (AES-CCM) のハードウェアサポートがありますが、AES Galois/Counter Mode (AES-GCM) のサポートはないため、暗号スイートに関する前述の推奨事項に従うことができません。公開鍵暗号化をまったくサポートしていないデバイスさえありますが、これらは完全に範囲外です。

encrypt_then_mac 拡張 [RFC7366] も正常にネゴシエートされない限り、CBC (暗号ブロック連鎖) モードで動作する暗号スイート (例: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) を使用すべきではありません (SHOULD NOT)。この要件は、クライアントとサーバーの両方の実装に適用されます。

TLS ピアの認証に ECDSA 署名を使用する場合、実装は NIST 曲線 P-256 を使用することが推奨されます (RECOMMENDED)。さらに、(長期署名鍵を明らかにする可能性のある) 予測可能または繰り返しの nonce を回避するために、実装は [RFC6979] で指定され、[RFC8446] の推奨事項に沿って「決定論的 ECDSA」を実装することが推奨されます (RECOMMENDED)。

「決定論的 ECDSA」の実装は、まさにその決定性のために、特定のサイドチャネルおよびフォールトインジェクション攻撃に対して脆弱である可能性があることに注意してください。文献で説明されているほとんどのフォールトインジェクション攻撃は、デバイスへの物理的アクセスを想定しており (したがって、物理的セキュリティが不十分または存在しない Internet of Things (IoT) 展開でより関連性が高い)、一部はリモートで実行できます [Poddebniak2017]。たとえば、Rowhammer [Kim2014] バリアントとしてです。サイドチャネル攻撃とフォールトインジェクション攻撃が懸念される展開では、署名鍵の抽出が成功するリスクを回避するために、ランダム性と決定性の両方を組み合わせた実装戦略 (たとえば、[CFRG-DET-SIGS] で説明されているように) を使用できます。

4.2.1. 実装の詳細

クライアントは、TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 を任意のサーバーへの最初の提案として含めるべきです (SHOULD)。サーバーは、この暗号スイートが提案された場合は常に、最初の提案でなくても、より弱い暗号スイートよりも優先しなければなりません (MUST)。もちろん、クライアントはより強力な暗号スイート (例: AES-256 の使用) を自由に提供できます。そうする場合、サーバーは、そうしない説得力のある理由 (例: パフォーマンスの大幅な低下) がない限り、より強力な暗号スイートを優先すべきです (SHOULD)。

TLS 推奨事項の以前のバージョン [RFC7525] では、古い RFC 5246 実装必須暗号スイート TLS_RSA_WITH_AES_128_CBC_SHA が暗黙的に許可されていました。執筆時点では、この暗号スイートは、非常に古いクライアントを除いて、追加の相互運用性を提供しません。前方秘匿性を提供しない他の暗号スイートと同様に、実装はこの暗号スイートをサポートすべきではありません (SHOULD NOT)。他のアプリケーションプロトコルは、他の暗号スイートを実装必須 (MTI) として指定しています。

[RFC8422] により、クライアントとサーバーは ECDH パラメータ (曲線) をネゴシエートできます。クライアントとサーバーの両方が「Supported Elliptic Curves Extension」[RFC8422] を含めるべきです (SHOULD)。クライアントとサーバーは、NIST P-256 (secp256r1) [RFC8422] および X25519 (x25519) [RFC7748] 曲線をサポートすべきです (SHOULD)。[RFC8422] は、非圧縮ポイント形式以外のすべてを廃止していることに注意してください。したがって、クライアントが ec_point_formats 拡張を送信する場合、ECPointFormatList には単一の要素 "uncompressed" を含めなければなりません (MUST)。

4.3. TLS 1.3 の暗号スイート

本書では、TLS 1.3 の暗号スイートを指定していません。読者は、暗号スイートの推奨事項について [RFC8446] のセクション 9.1 を参照してください。

4.4. 鍵使用の制限

すべての暗号には、任意の特定の鍵で安全に保護できるトラフィック量に上限があります。AEAD 暗号スイートの場合、鍵ごとに 2 つの個別の制限が維持されます。

1. 機密性制限 (CL)、つまり暗号化できるレコードの数。

2. 整合性制限 (IL)、つまり認証に失敗することが許可されるレコードの数。

後者は DTLS (および QUIC) に適用されますが、TLS 自体には適用されません。これは、TLS 接続が最初の復号化失敗で切断されるためです。

送信者が CL に近づいている場合、実装は新しいハンドシェイクを開始して (TLS 1.3 では、これは確立されたセッションで KeyUpdate メッセージを送信することで実現できます) セッション鍵をローテーションすべきです (SHOULD)。受信者が IL に達した場合、実装は接続を閉じるべきです (SHOULD)。これらの推奨事項はベストプラクティスですが、実装者は、レイヤー境界を越えた調整を導入せずに TLS/DTLS 上に構築されたプロトコルでこれらを達成することは必ずしも容易ではないことに注意する必要があります。鍵の更新をサポートするために QUIC で暗号レイヤーとトランスポートレイヤーの間で必要だった協力の例については、[RFC9001] のセクション 6 を参照してください。一般に、アプリケーションプロトコルは、TLS/DTLS との相互作用がより制約されているため、その方法をエミュレートできない可能性があることに注意してください。これらの複雑さの結果として、これらの推奨事項は必須ではありません。

すべての TLS 1.3 暗号スイートについて、読者は CL および IL の値について [RFC8446] のセクション 5.5 を参照してください。すべての DTLS 1.3 暗号スイートについて、読者は [RFC9147] のセクション 4.5.3 を参照してください。

本書で TLS 1.2 および DTLS 1.2 に推奨されるすべての AES-GCM 暗号スイートについて、CL は、対応するパラメータを [AEAD-LIMITS] のセクション 6.1 の不等式に代入することで導出できます。これは、ランダムな部分的に暗黙の nonce、つまり TLS 1.2 で使用される nonce 構造に適用されます。得られた数値は TLS 1.3 の数値よりもわずかに大きいですが、両方のバージョンで同じ 2^24.5 レコードの制限を使用することが推奨されます (RECOMMENDED)。

DTLS 1.2 に推奨されるすべての AES-GCM 暗号スイートの場合、IL (上記の同じ不等式から得られる) は 2^28 です。

4.5. 公開鍵の長さ

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

モジュラー指数 (MODP) Diffie-Hellman グループ ("DHE" 暗号スイート) に基づく鍵交換の場合、少なくとも 2048 ビットの DH 鍵長が必須です (REQUIRED)。

理由: さまざまな理由から、実際には、DH 鍵は通常、2 の累乗の長さ (例: 2^10 = 1024 ビット、2^11 = 2048 ビット、2^12 = 4096 ビット) で生成されます。1228 ビットの DH 鍵は 80 ビットの対称鍵 [RFC3766] とほぼ同等に過ぎないため、"DHE" ファミリの暗号スイートにはそれよりも長い鍵を使用することをお勧めします。1926 ビットの DH 鍵は、100 ビットの対称鍵 [RFC3766] とほぼ同等になります。執筆時点での [NIST.SP.800-56A] の最新リビジョンで許可されている最小値は、2048 ビットの DH 鍵 (112 ビットの対称鍵に相当) です (特にそのドキュメントの付録 D を参照)。

[RFC3766] で述べられているように、The Weizmann Institute Relation Locator (TWIRL) マシン [TWIRL] の出現を補正すると、1024 ビットの DH 鍵は約 61 ビットの同等の強度をもたらし、2048 ビットの DH 鍵は約 92 ビットの同等の強度をもたらすことを意味します。Logjam 攻撃 [Logjam] は、1024 ビットの Diffie-Hellman パラメータを回避すべきであることをさらに示しています。

ECDH 鍵に関して、実装者は "Transport Layer Security (TLS) Parameters" レジストリ [IANA_TLS] 内の IANA "TLS Supported Groups" レジストリ (以前は "EC Named Curve Registry" として知られていました) を参照し、特に "recommended" グループを参照してください。224 ビット未満の曲線を使用してはなりません (MUST NOT)。この推奨事項は、[NIST.SP.800-56A] の最新リビジョンに沿っています。

RSA を使用する場合、サーバーは、公開鍵に少なくとも 2048 ビットのモジュラスを持つ証明書を使用して認証しなければなりません (MUST)。さらに、SHA-256 ハッシュアルゴリズムの使用が推奨され (RECOMMENDED)、SHA-1 または MD5 は使用してはなりません (MUST NOT) [RFC9155] (詳細については [CAB-Baseline] も参照してください。執筆時点での現在のバージョンは 1.8.4 です)。クライアントは、TLS 1.2 で定義されている「署名アルゴリズム」拡張を使用して SHA-256 を要求することをサーバーに示す必要があります (MUST)。TLS 1.3 の場合、同じ要件が [RFC8446] ですでに指定されています。

4.6. トリムされた HMAC

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

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