12. Security Considerations (セキュリティに関する考慮事項)

12.1. Hashing Considerations (ハッシュに関する考慮事項)

12.1.1. Dictionary Attacks (辞書攻撃)

NSEC3 RR は依然として辞書攻撃 (dictionary attacks) の影響を受けやすい (つまり, 攻撃者がすべての NSEC3 RR を取得し, すべての可能性の高いドメイン名のハッシュを計算し, NSEC3 RR で見つかったハッシュと比較することによって, ゾーンを列挙します)。これらは元の NSEC RR を列挙するよりもかなり高価であり, いずれにしても, そのような攻撃はすべての可能性の高い名前のクエリを実行することによってネームサーバー自体に対して直接使用することもできますが, これは明らかにより検出可能です。このオフライン攻撃のコストは, NSEC3 RR の反復回数 (iterations) を設定することで調整できます。

ゾーンは事前計算された辞書攻撃 (pre-calculated dictionary attack) の影響も受けやすい -- つまり, すべての可能性の高い名前のハッシュのリストが一度計算され, その後 NSEC3 RR が定期的にスキャンされ事前計算されたハッシュと比較されます。この攻撃は定期的にソルトを変更することによって防がれます。

ソルトは少なくとも 64 ビット長で予測不可能であるべきであり, 攻撃者がソルトの値を予測し, ゾーンが公開される前に次の辞書セットを計算できないようにします。

12.1.2. Collisions (衝突)

QNAME と NSEC3 RR のオーナー名の間でハッシュ衝突 (hash collisions) が発生する可能性があります。発生した場合, 衝突する QNAME の非存在を証明することは不可能になります。ただし, SHA-1 では, これは非常にありそうにありません (約 1 in 2^160 のオーダー)。DNSSEC はすでに暗号ハッシュ関数が第二原像抵抗性 (second pre-image resistant) であるという前提に依存していることに注意してください, これらのハッシュ関数は署名と DS RR の生成と検証に使用されているためです。

12.1.3. Transitioning to a New Hash Algorithm (新しいハッシュアルゴリズムへの移行)

NSEC3 および NSEC3PARAM RR フォーマットにはハッシュアルゴリズムパラメータが含まれていますが, この文書は 1 つの NSEC3 ハッシュアルゴリズムから別のものへ安全に移行するための特定のメカニズムを定義していません。NSEC3 で使用する新しいハッシュアルゴリズムを指定する場合, 移行メカニズムも定義しなければなりません。唯一の実用的で受け入れ可能な移行メカニズムは, 安全でない状態への中間移行, または NSEC3 の代わりに NSEC レコードを使用する状態への移行を必要とする可能性があります。

12.1.4. Using High Iteration Values (高いイテレーション値の使用)

バリデータは高いイテレーション値を含む NSEC3 RR を含むレスポンスを安全でないものとして扱うべきであるため, ゾーン内に高いイテレーション値を持つ署名された NSEC3 RR が 1 つだけ存在することは, 攻撃者に可能なダウングレード攻撃 (downgrade attack) を提供します。

攻撃は単純にレスポンスから既存の NSEC3 RR を削除し, 高いイテレーション値を使用する単一の (または複数の) NSEC3 RR をレスポンスに置き換えまたは追加することです。バリデータはその後レスポンスを安全でないものとして扱うことを強制されます。この攻撃は次のすべての条件が満たされた場合にのみ有効です:

ゾーン内に高いイテレーション値を使用する署名された NSEC3 RR が少なくとも 1 つ存在する。
攻撃者がこれらの NSEC3 RR の 1 つ以上にアクセスできる。これは, 高いイテレーション値を持つ NSEC3 RR が典型的なレスポンスで返されている場合には自明に真ですが, 攻撃者が AXFR または IXFR クエリ経由でまたはその他の方法でゾーンにアクセスできる場合にも真である可能性があります。

高い数のイテレーションを使用することは, サーバーに対する追加のサービス拒否の機会 (denial-of-service opportunity) も導入します, サーバーは否定またはワイルドカードレスポンスごとに複数のハッシュを計算しなければならないためです。

12.2. Opt-Out Considerations (Opt-Out に関する考慮事項)

Opt-Out フラグ (O) は, 未署名ゾーンへの委任の形式で未署名の名前が, その他の署名されたゾーン内に存在することを許可します。すべての未署名の名前は, 定義上安全ではなく, それらの妥当性または存在は暗号学的に証明できません。

一般に:

未署名の名前を持つリソースレコード (存在するかどうかにかかわらず) は, 未署名ゾーンの RR と同じ脆弱性に苦しみます。これらの脆弱性は [RFC3833] でより詳細に説明されています (特にセクション 2.3 "Name Chaining" とセクション 2.6 "Authenticated Denial of Domain Names" に注意してください)。
署名された名前を持つリソースレコードは, Opt-Out が使用されているかどうかにかかわらず同じセキュリティを持ちます。

Opt-Out の有無にかかわらず, 安全でない委任は攻撃者によって検出不可能に変更される可能性があることに注意してください。このため, Opt-Out を使用する際のセキュリティの主な違いは, Opt-Out NSEC3 RR のスパン内で安全でない委任の存在または非存在を証明する能力の喪失です。

特に, これは悪意のあるエンティティが未署名の名前を持つ RR を挿入または削除できる可能性があることを意味します。これらの RR は通常 NS RR ですが, これには署名されたワイルドカード展開 (ワイルドカード RR 自体は署名されていますが, その展開された名前は未署名の名前です) も含まれます。

委任を追加できることは, 任意の RR タイプを追加できることと機能的に同等であることに注意してください: 攻撃者は単に自分のコントロール下にあるネームサーバーへの委任を偽造し, サブゾーン頂点に必要な RR を配置するだけでよいのです。

特定の場合において, この問題は重大なセキュリティ問題を提示しない可能性がありますが, 一般的には軽く扱うべきではありません。したがって, Opt-Out は控えめに使用することを強く推奨します。特に, ゾーン署名ツールは Opt-Out の使用をデフォルトとすべきではなく, Opt-Out を全くサポートしないことを選択してもかまいません。

12.3. Other Considerations (その他の考慮事項)

NSEC3 RR をウォーキングすると, ゾーン内の RR の合計数 (空の非終端を含む), および存在するタイプが明らかになります。これはダミーエントリを追加することで軽減できますが, 確実に上限は常に見つけることができます。