ECDSA：DNSSECに欠けている部分

Cloudflareは、世界最大の マネージドDNSプロバイダーです。当社が本当に望まないのは、DNSSECサーバーを分散型サービス拒否（DDoS）攻撃の増幅ベクトルに変えてしまうことです。DNSSECサーバーにレコードを要求するたびに、そのレコードに関連付けられた署名と、その署名を検証するために使用される公開鍵が返されます。これは膨大な情報量になる可能性があります。

DNSSECクエリの応答サイズを可能な限り小さくすることは、攻撃しようとしている者からDNSインフラストラクチャが悪用されることを防ぐための重要な要件です。ECDSAの鍵や署名のサイズが小さいことは、この目的に大きく貢献します。

ECDSAで128bitのセキュリティを実現するには256bitの鍵が必要ですが、同等のRSA鍵は3072bitです。これは、鍵だけで12倍の増幅率ということになります。暗号鍵のサイズが異なる理由については、こちらのブログ記事で詳しく解説しています。

しかし、ほとんどのRSA鍵は3072ビットではないため、12倍の増幅率は最も現実的な数字とは言えないかもしれません。DDoS増幅の現実的な最悪のシナリオであるネガティブレスポンス（NSECレコード）について見てみましょう。Cloudflare（ECDSA署名とDNSSECのホワイト・ライを使用）の後にあるドメインの場合、一般的なDNSSECの応答は377バイトです。これを、ECDSAまたはDNSSECのホワイト・ライを使用していないドメインの1075バイトと比較します。

他のすべての大規模なDNSSEC実装がRSA署名に依存しているという事実を考慮すると、攻撃者が当社のDNSSECインフラストラクチャをDDoSの攻撃ベクトルとして利用するのは魅力的ではありません。

ECDSAにはトレードオフがないわけではありません。Roland van Rijswijk-Deij et alによると、ECDSA検証をサポートしているリゾルバは80%に過ぎないとのことです。この数は増加傾向にありますが、この使用率では今すぐDNSSECインターネット全体をECDSAに切り替えた場合、毎日何百万人ものインターネットユーザーに対するDNSSEC検証が失敗し、検証されていないDNSレコードを返すことになります。

さらに、ECDSA署名の作成はRSAより高速ではあるものの、署名の検証は実際にはかなり低速になります。Roland van Rijswijk-Deijらは、我々がOpenSSLに貢献したECDSAの最適化をもってしても、ECDSAは1024ビットRSA（ゾーン署名鍵に最もよく使われるアルゴリズム）よりも6.6倍遅いことを示しました。DNSリゾルバーに過負荷をかけると、インターネット全体が遅くなる可能性があるため、これは深刻な問題です。

このAlgorithm 13の議論には1点、任意の容量でDNSSECをサポートしているWebプロパティはわずか1.5%しかないという非常に重要な注意点があります。すべてのレジストラがDNSSECをサポートしているわけではなく、サポートを追加することは容易ではありません。レジストラはユーザーがDSレコードをアップロードできるようにする必要があり、このレコードはレジストラによってレジストリにアップロードされる必要があります。私たちは、これを自動化プロセスにすることで、登録者がDSレコードをアップロードする必要さえないように努めていますが、それでも登録者の介入が必要です。

そのような中での明るい知らせは、私たちが正しい方向へ向かっているということです。過去12ヶ月の間、DNSSECは全般的にかなりの成長を遂げてきました。また、公開されているDNSSECのベータ版からユニバーサルDNSSECの発表までの3週間の間にレジストリ、Hover、OVH、Metaname、Internet.bs、.NZが、アルゴリズム13をサポートするようになりました。

私たちは、DNSSECが現代のWebにとって不可欠な技術であり、ECDSAによってグローバルなDNSSECの採用が現実的なものになると考えています。願わくば、今後も大小さまざまなレジストラやレジストリでアルゴリズム13がサポートされることを望みます。