Cloudflareは、DNSSEC公開リゾルバー1.1.1.1で、ML-DSA-44アルゴリズムを使用したDNSSEC署名の検証を有効にした。これは、強力な量子コンピューターによって現在の署名アルゴリズムが破られる可能性がある段階に、ドメインネームシステムが備えられているかを検証することを目的とした取り組みである。同社によれば、この措置はより長期的な移行の始まりであり、ポスト量子DNSSECセキュリティを完全に実装するものではない。
米国国立標準技術研究所（NIST）は、ML-DSA-44を標準化アルゴリズムの一つとして公開しており、このアルゴリズムはIANAからDNSSECアルゴリズム番号18を割り当てられている。Cloudflareは、2029年までに完全なポスト量子セキュリティを実現することを計画している。これまでの取り組みの大部分は、TLSにおける鍵合意に焦点を当てていた。
DNSの一般的なパケットより大きい一つの署名
最大の実務上の障害は、署名のサイズである。ML-DSA-44の署名は2,420バイトで、ECDSA P-256の署名は64バイトである。また、公開鍵のサイズは1,312バイトに達する。そのため、レコード、ドメイン名、プロトコルヘッダー、その他のDNSSECレコードを追加する前から、署名だけでUDP経由のDNS応答における一般的な制限を超える。
DNS実装では、UDPパケットに対して1,232バイトという保守的な上限が頻繁に使用される。これはIPv6の最小パスMTUに関連する上限である。パケットに収まらない場合、権威サーバーは切り詰められた応答を返し、リゾルバーに別のプロトコル、通常はTCPで再試行させる必要がある。信頼性の低いUDPフラグメンテーションに依存することはできない。この問題は、ゾーンの検証に必要な鍵を運ぶDNSKEY応答で明確に現れ、従来型とポスト量子の鍵を同時に公開する場合や、鍵をローテーションする際にはさらに大きくなる可能性がある。
従来型署名へのフォールバックを防ぐ
従来型アルゴリズムを直ちに停止することはできない。古いリゾルバーは、ML-DSA-44だけを公開するゾーンを検証できないためである。しかし、両方の経路を併存させると、セキュリティダウングレードへの経路が開く可能性がある。ECDSAのような従来型アルゴリズムが量子コンピューターに対して安全でなくなった後、攻撃者は、リゾルバーがML-DSA-44を利用できる場合でも、それに依存する応答を偽造できる可能性がある。
これに対処するため、1.1.1.1は親ゾーンに公開されたDSレコードを利用する。検証済みのDSセットに、サポートされているポスト量子アルゴリズムのレコードが含まれている場合、Cloudflareはより厳格なローカル検証ポリシーを適用し、ML-DSA-44を使用した有効な検証経路の存在を要求する。従来型の経路だけでは不十分である。同社は、これはまだDNSSECにおける通常の検証メカニズムではないが、RFC 4035が認めるローカルポリシー権限に基づいていると説明している。
実際には何が変わるのか？
1.1.1.1のユーザーは何も変更する必要がない。ゾーンが必要なDNSSECレコードを公開すると、検証は自動的に行われる。既存のゾーンは引き続き通常どおり動作する。Cloudflareによれば、1.1.1.1へのクエリの約85%はUDP経由で到達しており、より大きな応答の測定とTCP経由での再試行は、運用テストの重要な一部となる。
しかし、リゾルバーで検証を有効にしても、完全なポスト量子の信頼チェーンが構築されるわけではない。権威サーバーがゾーンへの署名をサポートし、レジストラが適切なDSレコードを受け入れ、親ゾーンのレジストリがそれらを公開し、最終的にDNSルートまで到達する必要がある。ポスト量子保護を欠くレベルは、依然としてダウングレードの潜在的なポイントとなる。
certi.newsの見解
この発表の本質的な価値は、エンドユーザー向けのオプションを追加することではなく、ML-DSA-44を暗号標準から大規模な運用テストへと移行させることにある。Cloudflareが明らかにした問題は二重である。通常よりはるかに大きなメッセージを転送することと、古いアルゴリズムが何年も存続する間も検証の厳格性を維持することである。未解決の問題は、DNS全体のチェーンにおけるアルゴリズムの採用速度と、帯域幅コストおよびTCP利用増加の測定に関係している。Cloudflareは今後、Cloudflare Authoritative DNSへのML-DSA-44署名サポートと、Cloudflare RegistrarにおけるDSレコードのサポートを顧客向けに無料で追加する予定であり、これにより完全な経路をテストできるようになる。