Kann mir jemand, der informiert ist, bitte eine ausführliche Antwort zu den Unterschieden und Vor-/Nachteilen beider Ansätze geben?
Ich bin kein DNS-Experte und auch kein Programmierer. Ich habe ein gutes Grundverständnis von DNS und genug Wissen, um zu verstehen, wie Dinge wie der Kaminsky-Bug funktionieren. Soweit ich weiß, hat DNSCurve eine stärkere Verschlüsselung, ist viel einfacher einzurichten und insgesamt eine bessere Lösung.
DNSSEC ist unnötig kompliziert und verwendet eine knackbare Verschlüsselung, bietet jedoch End-to-End-Sicherheit, was DNSCurve nicht bietet. Viele der Artikel, die ich gelesen habe, schienen jedoch darauf hinzuweisen, dass End-to-End-Sicherheit wenig nützt oder keinen Unterschied macht.
Was ist also richtig? Welche Lösung ist besser und welche Nachteile bzw. Vorteile hat jede Lösung?
bearbeiten:
Ich wäre dankbar, wenn mir jemand erklären könnte, was durch die Verschlüsselung des Nachrichteninhalts erreicht wird, wenn das Ziel eher die Authentifizierung als die Vertraulichkeit ist.
Der Beweis, dass es sich bei den Schlüsseln um 1024-Bit-RSA-Schlüssel handelt, istHier.
Antwort1
DNSCurve bietet eine tatsächliche Verschlüsselung für DNS-Pakete, allerdings nur auf Hop-für-Hop-Basis und insbesondere auf dem Hop zwischen dem rekursiven Server und dem autoritativen Server.
Bei Verwendung auf diesem Pfad kann es eine Authentifizierung der Zonendaten bereitstellen. Ein weiter unten liegender Client kann jedoch nicht von dieser Authentifizierung profitieren, da die Sicherheit nur „Hop-by-Hop“ erfolgt. Ein böswilliger Resolver, der sich in der Mitte des Auflösungspfads befindet, kann immer noch falsche Daten bereitstellen.
DNSSEC hingegen bietet eine durchgängig verifizierbare kryptografische Signatur, die beweist, dass die empfangenen Daten mit denen auf dem autoritativen Server übereinstimmen. DNSSEC verwendet kryptografische Techniken, verschlüsselt jedoch keinen DNS-Verkehr.
Die Verwendung von elliptischen Kurvenverschlüsselungsalgorithmen durch DNSCurve ermöglicht die Verwendung viel kleinerer Schlüssel als bei RSA, um dieselbe kryptografische Stärke zu erreichen. Es gibt jedoch Vorschläge, ähnliche Algorithmen in die von DNSSEC vorgeschlagene Liste aufzunehmen.
DNSSEC ist von der IETF standardisiert (RFC 4034 und RFC 4035, aktualisiert durch RFC 5155) und in mehreren sehr beliebten Nameserver-Implementierungen implementiert, darunter BIND (natürlich) und NSD/Unbound. PowerDNS wird DNSSEC in Kürze unterstützen.
DNSSEC ist zugegebenermaßen kompliziert, aber es gibt Bemühungen, es zu vereinfachen (siehe z. B.http://opendnssec.org/) und die Verbreitung nimmt ständig zu. Verschiedene TLDs (.se, .br, .org, .gov usw.) sind bereits mit DNSSEC signiert und es wurde angekündigt, dass die Root-Zone bis Ende des Jahres DNSSEC-signiert sein wird.
DNSCurve ist recht interessant, aber aufgrund der unabhängigen Entwicklung ist die Wahrscheinlichkeit, dass es zu einem größeren Einsatz kommt, sehr gering.nullChance, jemals auf den Root-Servern bereitgestellt zu werden.
Übrigens scheint Ihre Behauptung, DNSSEC verwende eine „knackbare Verschlüsselung“, völlig unbegründet zu sein. Auf welcher Grundlage sagen Sie das?
Zonensignaturschlüssel sind normalerweise (aber nicht notwendigerweise) 1024 Bit lang. Diese Schlüssel werden normalerweise etwa einmal im Monat neu erstellt, und nach aktuellen Schätzungen würde es mindestens ein paar Jahre dauern, bisrohe Gewaltein 1024-Bit-Schlüssel.
Zum jetzigen Zeitpunkt würde ein Brute-Force-Angriff auf 1024-Bit-RSA etwa zwei Jahre dauern und mehrere Millionen Rechenkerne mit mehreren zehn Gigabyte Speicher pro Prozessor oder Mainboard erfordern.
was nicht gerade ein typisches Botnetz ist. Aus demselben Artikel:
Betrachtet man als nächstes Spezialhardware, so geht der optimistischste Ansatz davon aus, dass das Sieben eines 1024-Bit-RSA-Moduls in einem Jahr für etwa 10.000.000 US-Dollar zuzüglich einmaliger Entwicklungskosten von etwa 20.000.000 US-Dollar und mit vergleichbarem Zeit- und Kostenaufwand für die Matrix durchgeführt werden kann. Unserer Meinung nach ist die (allgemeine) Skepsis, die solchen Designs entgegenschlägt, nebensächlich. Solche Zahlen sollten nicht als Obergrenzen interpretiert werden, d. h.: „Seien Sie vorsichtig, 1024-Bit-RSA kann in zwei Jahren für etwa zwanzig Millionen Dollar geknackt werden (bei kostenloser Entwicklung)“, sondern als Untergrenzen, d. h.: „Kein Grund zur Sorge: Selbst unter sehr günstigen Angriffsbedingungen erfordert das Faktorisieren eines 1024-Bit-RSA-Moduls immer noch enorme Ressourcen.“ Die Schätzungen sollten daher nicht als bedrohlich, sondern als vertrauenerweckend verstanden werden.
Oder von einem EinjährigenPCPro-Artikel:
Um das ins Verhältnis zu setzen: Um einen RSA-1.024-Bit-Schlüssel zu knacken, müsste man laut Kaspersky etwa 15 Millionen Computer ein Jahr lang auf Hochtouren laufen lassen, um erfolgreich zu sein.
Ehrlich gesagt wird niemand so viel Aufwand betreiben, um den ZSK einer Domäne zu knacken!
Außerdem liegt die wahre Sicherheit in den Schlüsselsignaturschlüsseln, und diese sind normalerweise mindestens 2048 Bit lang und oft länger (4096 Bit). Die Zeit, die zum Knacken eines RSA-Schlüssels benötigt wird, steigt exponentiell mit der Schlüssellänge, nicht linear.
Antwort2
AKommentar zu LWNAnsprüche
DNSCurve sichert den Kanal, nicht die Nachricht. Es kann nicht zum Schutz vor bösartigen Caches verwendet werden und ist kein funktionales Äquivalent zu DNSSEC.
und Links zu einemDiskussion auf Französisch.
Antwort3
Es ist wichtig zu verstehen, dass der Schlüssel zur Sicherheit eher im „Vertrauen“ als in der „Verschlüsselung“ liegt. Sie können mit jemandem, der „Verschlüsselung“ verwendet, ein „sicheres“ Gespräch führen, aber was nützt Ihnen das, wenn die Person am anderen Ende nicht die ist, für die Sie sie halten?
Der größte Unterschied zwischen DNSSec und DNSCurve besteht darin, dass DNSSec alles signiert und eine klare Vertrauenskette von der Wurzel bis hinauf zu den Host-Datensätzen besteht, die von den DNS-Servern der einzelnen Betreiber bereitgestellt werden.
DNSCurve signiert NICHTS, es gibt überhaupt keine Vertrauenskette. Der Fokus von DNSCurve beschränkt sich darauf, die passive oder blinde Manipulation von DNS-Antworten zu verhindern.
Es läuft auf die praktische Seite hinaus... DNSSec bringt enorme operative Herausforderungen mit sich - wie erstellt man praktisch einen Vertrauensanker in der Größe des Planeten? Welche Mechanismen werden verwendet, um beim Signieren von Millionen und Abermillionen von Domänen Vertrauen zu schaffen, dass das zum Fälschen einer Signatur erforderliche Schlüsselmaterial nicht in die falschen Hände gerät oder nicht missbraucht wird? Vertrauen im großen Maßstab ist aus operativer Sicht sehr schwer herzustellen und aufrechtzuerhalten.
DNSCurve versucht es nicht einmal.
Nachdem ich nun die grundlegende Frage beantwortet habe, hier meine Ansicht dazu, was das zu lösende Problem eigentlich ist und welche der beiden Technologien besser geeignet ist.
Das Internet ist von Natur aus sowohl ein Medium für Unsinn als auch für wichtige Diskussionen und Aufklärung. Meiner Ansicht nach ist ein vollständig vertrauenswürdiges Internet kein vernünftiges oder erreichbares Ziel, und wenn es eines werden sollte, hätte dies wahrscheinlich negative Auswirkungen in Bezug auf Freiheiten und anonyme Rede und Handlungen.
Meiner Meinung nach ist alles, was wir brauchen, eine DNS-Lösung, dieam wenigstenso vertrauenswürdig wie der zugrunde liegende Transport. Es muss praktisch verhindern, dass DNS-Einträge durch Angreifer vergiftet werden, die blind falsche Nachrichten einschleusen oder passiv Anfragen abhören und UDP-Antworten fälschen. Darüber hinaus muss es KEINE Sicherheit garantieren. Auf diese Weise leitet das Internet weiterhin Pakete weiter und stellt DNS-Dienste auf zuverlässige, aber nicht unbedingt sichere Weise bereit.
DNSSec und seine globalen Vertrauensanker sind meiner Meinung nach ein sinnloses Unterfangen, das sich fast ausschließlich auf die Lösung eines Problems konzentriert, das gar nicht existiert. (Alle Ende-zu-Ende-Verschlüsselungssysteme, die über das Internet verwendet werden können, verfügen bereits über eigene Methoden zur Identitätsüberprüfung.)
DNSSec ist langsam, teuer und wird die offensichtlichen und aktuellen Probleme mit DNS erheblich verzögern, die, wie die Umstellung auf IPv6, eigentlich schon gestern hätten gelöst werden sollen.
DNSCurve schützt das Netzwerk, sodass der Namensdienstam wenigstenso zuverlässig wie der zugrunde liegende Transport von Paketen über das Netzwerk, aber nicht zuverlässiger. Meiner Ansicht nach löst es genau das Problem, mit dem es in der realen Welt tatsächlich konfrontiert ist. DNSCurve verhindert passives MITM, schützt aber praktisch nicht vor aktivem MITM ohne Signatur-Caching im SSH-Stil „Leap-of-Faith“.
Um den Advocatus Diaboli zu spielen: Die großflächige Einführung von DNSSec kann möglicherweise positive Auswirkungen haben. Die PKI-Infrastruktur kann die SSL-Secure-Server-CAs ersetzen und eine gewisse Vertrauensbindung für IPSec und andere verschlüsselte Konversationen zwischen Peers bereitstellen.
Antwort4
Ich bin zu dem Schluss gekommen, dass DNSCurve die bessere Option ist.
Weil:
DNSSEC verwendet 1024-Bit-RSA-Schlüssel zur Signatur, die schon 2003 als unknackbar für große Netzwerke, Botnetze, galten. Das ist auch heute noch so.
Für eine korrekte Implementierung muss viel Code neu geschrieben werden.
Die Root-Server signieren nicht die komplette Datenbank und bieten daher keinen vollständigen Schutz.
Bis zu 30 Tage nach Ablauf einer Domain sind Replay-Angriffe möglich.
Um Sicherheit zu erreichen, ist es notwendig, alle Domänennamen offenzulegen.
DNSCurve hat diese Probleme nicht und ermöglicht Authentifizierung, Verfügbarkeit und Vertraulichkeit (d. h., es müssen keine Namen offengelegt werden), was bei DNSSEC nicht der Fall ist. Darüber hinaus sind keine Codeänderungen erforderlich, sondern nur zusätzliche Software.
Es bietet außerdem Schutz vor gefälschten Paketen, was bei DNSSEC nicht der Fall ist, sowie Schutz vor Replay-Angriffen aufgrund der Verwendung von Nonces. DNSCurve kann einem MITM-Angriff ausgesetzt sein, was bei DNSSec nicht der Fall ist, aber meines Wissens wäre dies nicht der Fall, wenn DNSCurve bis zur Wurzel implementiert wäre.