詳しい方、両方のアプローチの違いや利点/欠点について、詳しく回答していただけませんか?
私は DNS の専門家でもプログラマーでもありません。DNS についての基礎知識は十分あり、カミンスキー バグなどの仕組みを理解するのに十分な知識があります。私の理解では、DNSCurve は暗号化が強力で、セットアップがはるかに簡単で、全体的に優れたソリューションです。
DNSSEC は不必要に複雑で、解読可能な暗号化を使用しますが、DNSCurve にはないエンドツーエンドのセキュリティを提供します。しかし、私が読んだ記事の多くは、エンドツーエンドのセキュリティはほとんど役に立たないか、何の違いももたらさないことを示しているようです。
では、どちらが真実でしょうか? どちらがより良い解決策でしょうか、あるいは、それぞれの欠点と利点は何でしょうか?
編集：
目標が機密性ではなく認証である場合、メッセージの内容を暗号化することで何が得られるのかを説明していただけると幸いです。
鍵が1024ビットRSA鍵であることの証明はここ。
答え1
DNSCurve は、ホップバイホップベースでのみ、具体的には再帰サーバーと権限サーバー間のホップで、DNS パケットに実際の暗号化を提供します。
このパスで使用すると、ゾーン データの認証を提供できます。ただし、セキュリティは「ホップバイホップ」のみであるため、下流のクライアントはこの認証の恩恵を受けることができません。解決パスの途中に悪意のあるリゾルバが存在すると、依然として偽のデータを提供できます。
一方、DNSSEC は、受信したデータが権威サーバー上のデータと同じであることを証明する、エンドツーエンドの検証可能な暗号署名を提供します。DNSSEC は暗号化技術を使用しますが、実際に DNS トラフィックを暗号化するわけではありません。
DNSCurve の楕円曲線暗号化アルゴリズムの使用により、RSA を使用する場合よりもはるかに小さなキーを使用して、同じレベルの暗号化強度を実現できます。ただし、DNSSEC で想定されているリストに同様のアルゴリズムを含めるという提案があります。
DNSSEC は IETF (RFC 4034 および RFC 4035、RFC 5155 で更新) によって標準化されており、BIND (もちろん) や NSD/Unbound など、いくつかの非常に一般的なネーム サーバー実装に実装されています。PowerDNS はまもなく DNSSEC をサポートする予定です。
DNSSECは確かに複雑ですが、これを簡素化する取り組みが進行中です（例：http://opendnssec.org/) が導入され、導入はますます増えています。さまざまな TLD (.se、.br、.org、.gov など) がすでに DNSSEC で署名されており、ルート ゾーンも年末までに DNSSEC で署名されることが発表されています。
DNSCurveは非常に興味深いものですが、独自に開発されたため、大きな展開が期待できる可能性はほとんどありません。ゼロルート サーバーに展開される可能性はほとんどありません。
ところで、DNSSEC が「解読可能な暗号化」を使用しているというあなたの主張は、まったく根拠がないように思えます。何を根拠にそうおっしゃるのですか?
ゾーン署名キーは通常（必ずしもそうとは限りませんが）1024ビットの長さです。これらのキーは通常1か月ごとに更新され、現在の推定では少なくとも2年はかかるとされています。強引な1024 ビットのキー。
現時点では、1024ビットRSAに対するブルートフォース攻撃には、プロセッサまたはマザーボードあたり数十ギガバイトのメモリを備えた数百万のコンピューティングコアで約2年かかります。
これは典型的なボットネットとはまったく異なります。同じ論文から引用します。
次に、専用ハードウェアについて考えると、最も楽観的なアプローチでは、1024 ビット RSA 係数のふるい分けは、約 10,000,000 米ドル、1 回限りの開発コスト約 20,000,000 米ドル、マトリックスの時間とコストで、1 年で実行できると示唆しています。私たちの意見では、このような設計に対する (一般的な) 懐疑論は的外れです。このような数字は、上限、つまり「注意してください。1024 ビット RSA は、約 2000 万ドル (無料開発と仮定) で 2 年で破ることができます」と解釈されるべきではなく、下限、つまり「心配しすぎる必要はありません。非常に有利な攻撃条件下でも、1024 ビット RSA 係数を因数分解するには膨大なリソースが必要です」と解釈されるべきです。したがって、推定値は脅迫的なものとしてではなく、自信を抱かせるものとして解釈されるべきです。
あるいは1歳児からPCProの記事:
これを概観すると、RSA 1,024ビットキーを解読するには、カスペルスキーの推定では、1500万台のコンピューターを1年間フル稼働させる必要がある。
率直に言って、1 つのドメインの ZSK を解読するために、それほどの労力を費やす人はいません。
さらに、実際のセキュリティはキー署名キーにあります。キー署名キーは通常 2048 ビット以上で、多くの場合はそれ以上 (4096 ビット) です。RSA キーを解読するのにかかる時間は、キーの長さに応じて直線的ではなく指数関数的に増加します。
答え2
あLWNにコメントする請求
DNSCurve はメッセージではなくコンジットを保護します。悪意のあるキャッシュから保護するために使用することはできず、DNSSEC と機能的に同等ではありません。
そして、フランス語での議論。
答え3
セキュリティの鍵は「暗号化」ではなく「信頼」であることを理解することが重要です。「暗号化」を使用して誰かと「安全な」会話をすることはできますが、相手があなたが思っている人物でなかったら何の役にも立ちません。
DNSSec と DNSCurve の主な違いは、DNSSec がすべてを署名し、ルートから各オペレータの DNS サーバーによって提供されるホスト レコードに至るまで明確な信頼チェーンが存在することです。
DNSCurve は何も署名せず、信頼チェーンはまったく存在しません。DNSCurve の焦点は、DNS 応答のパッシブまたはブラインド ポイズを防止することに限定されています。
結局のところ、実用性の問題です... DNSSec には運用上の大きな課題があります。地球規模のトラスト アンカーを実際にどのように作成するのでしょうか。何百万ものドメインが署名されている場合、署名を偽造するために必要なキー マテリアルが悪意のある人物の手に渡ったり、不適切に使用されたりしないという信頼を植え付けるためにどのようなメカニズムが使用されるのでしょうか。運用の観点から、大規模な信頼を実現して維持することは非常に困難です。
DNSCurve は試みさえしません。
さて、基本的な質問に答えたところで、実際に解決すべき問題は何なのか、そして 2 つのテクノロジーのどちらがより適しているのかという私の見解を述べたいと思います。
インターネットは本質的に、重要な議論や啓蒙が行われる場であると同時に、ナンセンスの場でもある。私の見解では、完全に信頼できるインターネットは、合理的でも達成可能な目標でもなく、もしそうなったとしても、自由や匿名の発言や行動の面でマイナスの影響が出る可能性が高い。
私の意見では、必要なのはDNSソリューションだけです。少しでも基盤となるトランスポートと同じくらい信頼できる必要があります。盲目的に偽のメッセージを挿入したり、受動的にリクエストをスニッフィングして UDP 応答を偽造したりする攻撃者による DNS レコードの改ざんを実質的に防止する必要があります。それ以上のセキュリティを保証する必要はありません。このようにして、インターネットはパケットをルーティングし、DNS サービスを信頼性が高く、必ずしも安全ではない方法で提供し続けます。
DNSSec とそのグローバル トラスト アンカーは、存在しない問題を解決することにほぼ完全に重点を置いた愚かな試みだと私は考えています。(インターネットで使用できるすべてのエンドツーエンド暗号化システムには、すでに ID を検証するための独自の方法があります)
DNSSec は遅く、高価であり、IPv6 への移行など、昨日解決されているはずだった DNS の明白かつ現在の問題を大幅に遅らせます。
DNSCurveはネットワークを保護し、ネーミングサービスが少しでもネットワーク上のパケットの基盤となる転送と同じくらい信頼性がありますが、それ以上ではありません。私の見解では、これは現実世界で実際に直面している問題を正確に解決します。DNSCurve は受動的な MITM を防ぎますが、SSH スタイルの「信頼の飛躍」署名キャッシュなしでは、能動的な MITM から実質的に保護することはできません。
敢えて言えば、DNSSec の大規模な導入は、プラスの影響をもたらす可能性があります。PKI インフラストラクチャは、SSL セキュア サーバー CA を置き換え、ピア間の IPSec やその他の暗号化された会話に信頼バインディングを提供できます。
答え4
DNSCurve の方がより良い選択肢であるという結論に達しました。
なぜなら：
DNSSEC は署名に 1024 ビットの RSA キーを使用しますが、これは 2003 年にはすでに大規模ネットワークやボットネットによって破られないと考えられていました。これは現在でも当てはまります。
正しく実装するには、多くのコードを書き直す必要があります。
ルート サーバーは完全なデータベースに署名しないため、完全な保護は提供されません。
ドメインの有効期限が切れてから最大 30 日以内にリプレイ攻撃が行われる可能性があります。
セキュリティを実現するには、すべてのドメイン名を公開する必要があります。
DNSCurve にはこれらの問題がなく、DNSSEC では不可能な方法で認証、可用性、機密性 (名前を公開する必要がない) を実現します。さらに、コードの変更は不要で、追加のソフトウェアのみが必要です。
また、DNSSEC にはない偽造パケットに対する保護機能や、ナンスの使用によるリプレイ攻撃に対する保護機能も備えています。DNSCurve は、DNSSec にはない MITM 攻撃を受ける可能性がありますが、DNSCurve がルートまで実装されていれば、このような事態にはならないと私は理解しています。