Cloudflareの1.1.1.1がML-DSA-44 DNSSECを検証、署名は2,420バイト

Cloudflareのパブリックリゾルバは現在、NISTが2024年に標準化したポスト量子署名アルゴリズムML-DSA-44で作られたDNSSEC署名を検証する。これを実運用で行うリゾルバは初めてであり、意図的なストレステストだ。同社はパケットサイズとダウングレードのバグを2030年ではなく今見つけたいと考えている。

動機は即時の脅威ではなく調整にある。今日、量子コンピュータはRSAもECDSAも破れない。しかしDNSSECの変更には権威サーバー、レジストリ、レジストラ、検証リゾルバ間の合意が必要であり、移行は最終的にルートゾーンにまで到達しなければならない。そこでは署名鍵が1つ復元されるだけで、攻撃者がその下のすべてのゾーンへの検証経路を偽造できる。Cloudflareの言い方は率直だ。一度破れば、どこでも偽造できる。

署名サイズがすべてである理由

ECDSA P-256はDNSSECレコードに64バイトで署名する。ML-DSA-44署名は2,420バイトで、約38倍の大きさだ。公開鍵は1,312バイト。どちらもDNS-over-UDP応答に快く収まるものではない。

DNSはもともとUDPメッセージを512バイトに制限していた。EDNS(0)によりリゾルバはより大きなバッファを通知できるようになり、多くの実装はIPv6の最小MTU 1,280バイト内に収まるよう保守的な1,232バイトのペイロードに落ち着いた。後にRFC 9715は1,400バイトの上限を推奨した。ML-DSA-44署名が1つあるだけで、署名対象のRRset、ドメイン名、ヘッダー、その他のDNSSECレコードを加える前に、これらすべてを超えてしまう。

UDPの断片化は誤った答えだ。Cloudflareは信頼できないものとして文書化している。正しい動作は、権威サーバーが切り詰め応答を返し、リゾルバにTCP、DoT、またはDoHでの再試行を強制することだ。Cloudflareによれば、1.1.1.1へのクエリの約85%はUDPで到着し、同社のBig Pineapple DNSプラットフォーム上の全サービスでは約60%だ。残りはすでにコネクション指向のトランスポートを使っており、再試行経路は異例ではない。ただしトラフィックは増える。

DNSKEY応答が最悪のケースだ。リゾルバがゾーンを検証するために必要な鍵を運ぶため、移行期間中は従来の鍵と署名、ポスト量子の鍵と署名の両方を含む可能性がある。鍵ロールオーバーが加われば、応答はさらに大きくなる。

誰も話したがらないダウングレード問題

ゾーンはML-DSA-44だけを公開できない。古いリゾルバは単純に検証に失敗する。実用的な道は両方のアルゴリズムを並べて公開することだ。互換性は保たれるが、それ自体ではポスト量子セキュリティを提供しない。

RFC 6840は、バリデータは任意の単一の有効な経路を受け入れるべき(SHOULD)としている。このルールが、リゾルバがサポートするアルゴリズムを選べるようにしている。そしてECDSAが破られた暁には、これがダウングレードの媒介にもなる。攻撃者がECDSAのみの応答を偽造し、ポスト量子対応のリゾルバがそれでも受け入れてしまう。

Cloudflareの修正は、RFCが要求するより厳しいローカルポリシーだ。親ゾーンからの認証済みDS RRsetがサポート対象のポスト量子アルゴリズムを含む場合、1.1.1.1は少なくとも1つの有効なML-DSA-44経路を要求する。従来の経路だけではもはや十分ではない。ポスト量子経路が検証されなければ、検証は失敗する。RFC 4035はリゾルバがどの署名を検証すべきかについてローカルポリシーを設定することを認めているため、これは合法だ。しかし通常のDNSSEC動作ではなく、ダウングレード信号がトラストアンカーからチェーン内のすべての委任を通じて及ぶ場合にのみ機能する。

ゾーン鍵をより頻繁にローテーションしても助けにはならない。攻撃者は階層のより上位にある脆弱な鍵を狙い、その下のすべてを偽造できる。

これが実際に証明するもの

Cloudflareの2029年ポスト量子ロードマップは主にTLSに関するものだった。DNSSECはより難しい標的だ。プロトコルのパケットサイズ前提が数十年分のネットワークソフトウェアに染み込んでおり、互換性の話がプロトコルではなくポリシーで塞がなければならないセキュリティホールを生むからだ。1.1.1.1の規模でML-DSA-44検証を動かすことは、エコシステムがどのリゾルバ、ミドルボックス、権威サーバーが壊れるかを知る方法だ。