DNSSEC ist ein kompliziertes Thema. Noch verwirrender wird es dadurch, dass es mehrere Standard-Sicherheitsalgorithmen zum Signieren von DNS-Einträgen gibt, die von der IANA definiert wurden. Algorithmus 13 ist eine Variante des Elliptic Curve Digital Signing Algorithm (ECDSA). Obwohl es derzeit von weniger als 0,01 % der Domains verwendet wird, möchten wir behaupten, dass ECDSA dazu beigetragen hat, die letzten beiden Hindernisse für eine weitflächige Adoption von DNSSEC zu beseitigen: Zone Enumeration und DDoS-Amplification.
Nach Lektüre dieses Artikels können Sie Folgendes:
Link zum Artikel kopieren
DNSSEC ist ein kompliziertes Thema. Noch verwirrender wird es dadurch, dass es mehrere Standard-Sicherheitsalgorithmen zum Signieren von DNS-Einträgen gibt, die von der IANA definiert wurden. Algorithmus 13 ist eine Variante des Elliptic Curve Digital Signing Algorithm (ECDSA). Obwohl es derzeit von weniger als 0,01 % der Domains verwendet wird, möchten wir behaupten, dass ECDSA dazu beigetragen hat, die letzten beiden Hindernisse für eine weitflächige Adoption von DNSSEC zu beseitigen: Zone Enumeration und DDoS-Amplification.
Zone Enumeration wird durch Live-Signierung verhindert, und diese ist nur mit der schnellen Signaturerstellung von ECDSA effizient zu berechnen. Elliptische Kurven erzeugen auch wesentlich kleinere Schlüssel und Signaturen als ihre RSA-Gegenstücke, was bedeutet, dass die Antworten auf DNS-Anfragen kleiner sind. Dadurch wird der Verstärkungsfaktor von DNS-basierten DDoS-Angriffen erheblich reduziert.
DNSSEC führt über NSEC- und NSEC3-Datensätze ein authentifiziertes Denial-of-Existence ein. Wie wir jedoch im Beitrag „Komplexe DNSSEC-Faktoren und Überlegungen“ erörtert haben, erlauben sowohl NSEC als auch NSEC3 Angreifern, die Zone zu umgehen. Die Lösung ist eine clevere Technik namens „DNSSEC white lies“ (beschrieben in den RFCs 4470 und 4471), aber sie kann nur implementiert werden wenn DNSSEC-Einträge sofort signiert werden.
RSA ist der am weitesten verbreitete Signieralgorithmus in DNSSEC, zum Teil deshalb, weil es der einzige vom Protokoll vorgeschriebene Algorithmus ist. Leider ist das Live-Signieren mit RSA unerschwinglich teuer.
ECDSA bringt eine gewaltige Performancesteigerung. Die Erstellung einer ECDSA-Signatur ist 10x weniger rechenaufwendig als eine vergleichbare RSA-Signatur. Dies macht Live-Signatur (Live-Signing und „DNSSEC White Lies“) möglich, sogar in großem Maßstab.
Während unserer DNSSEC-Betaphase (mit weniger als 1.000 signierten Domains) hat Cloudflare Zehntausende von DNSSEC-Anfragen pro Sekunde beantwortet. Das sind über 1 Milliarde Abfragen pro Tag, und wir signieren alle erforderlichen RRSIG-Datensätze sofort. Ein Algorithmus, der 10x schneller als RSA ist, macht einen großen Unterschied, wenn es um die Auslastung unserer DNSSEC-Server geht.
Als wir mit ECDSA zu arbeiten begannen, war die von uns verwendete OpenSSL-Implementierung in Go. In Anbetracht der vielen Signiervorgänge, die wir durchführen, war die Optimierung der Signaturerstellung eine hohe Priorität. Darum haben wir die ECDSA-Implementierung in hardwarenahen Code (Low-Level Assembly) umgeschrieben, und jetzt ist sie über 20-mal schneller als in Go. Dieser Code ist Open-Source und wird in Go 1.7 einfließen, so dass die gesamte Kryptographie-Community von unseren Optimierungen profitieren kann. Mehr dazu
Cloudflare ist der größte verwaltete DNS-Anbieter der Welt. Was wir wirklich nicht wollen, ist, dass unsere DNSSEC-Server zu einem Verstärkungsvektor für verteilte Denial-of-Service-Angriffe (DDoS) werden. Jedes Mal, wenn Sie einen Datensatz von einem DNSSEC-Server anfordern, sendet dieser auch die mit diesem Datensatz verbundene Signatur sowie den zur Überprüfung dieser Signatur verwendeten öffentlichen Schlüssel zurück. Das sind potenziell eine Menge Informationen.
Eine wichtige Voraussetzung, um den Missbrauch unserer DNS-Infrastruktur durch Möchtegern-Angreifer zu verhindern, ist es, die Antwortgröße für DNSSEC-Abfragen so klein wie möglich zu halten. Die geringe Größe von ECDSA-Schlüsseln und -Signaturen kommt diesem Ziel sehr entgegen.
Um mit ECDSA eine 128-Bit-Sicherheit zu erreichen, ist ein 256-Bit-Schlüssel erforderlich, während ein vergleichbarer RSA-Schlüssel 3072 Bit umfassen würde. Das ist ein 12-facher Verstärkungsfaktor allein durch die Schlüssel. Weitere Informationen darüber, warum kryptografische Schlüssel unterschiedlich groß sind, finden Sie in diesem Blogbeitrag.
Die meisten RSA-Schlüssel bestehen jedoch nicht aus 3072 Bits, so dass ein 12-facher Verstärkungsfaktor möglicherweise nicht die realistischste Zahl ist. Betrachten wir das schlimmste reale Szenario für eine DDoS-Verstärkung, nämlich eine negative Reaktion (NSEC-Eintrag). Für eine Domain hinter Cloudflare (die ECDSA-Signaturen und DNSSEC-Whitelies verwendet) ist eine typische DNSSEC-Antwort 377 Byte groß. Vergleichen Sie dies mit 1075 Bytes für eine Domain, die weder ECDSA noch DNSSEC-White Lies verwendet.
Wenn man bedenkt, dass jede andere groß angelegte DNSSEC-Implementierung auf RSA-Signaturen beruht, ist es für einen Angreifer wenig attraktiv, unsere DNSSEC-Infrastruktur als DDoS-Vektor zu nutzen.
ECDSA löst wichtige Probleme bei DNSSEC, wird aber von der weltweiten DNSSEC-Community kaum genutzt. Wir haben einen kurzen Blick auf die Einführung von ECDSA in der Root-DNS-Zone und die Alexa One Million geworfen.
Zunächst haben wir die Root-DNS-Zone untersucht, um festzustellen, welche DNSSEC-Algorithmen Top-Level-Domains verwenden. Die folgende Tabelle zeigt die Sicherheitsalgorithmen, die von den DS-Einträgen in der Root-Zone angegeben werden:
curl -s http://www.internic.net/domain/root.zone | awk '$4 == "DS" { print $6}' | sort -n | uniq -c
Wir haben eine ähnliche Analyse für die eine Million Alexa-Besucher durchgeführt, was einen guten Querschnitt des weltweiten Internet-Traffics gibt:
| Algorithmus | Anzahl der signierten DS-Datensätze |
|---|---|
| 1 (RSA/MD5) | 1 |
| 3 (DSA/SHA1) | 10 |
| 5 (RSA/SHA-1) | 3322 |
| 7 (RSASHA1-NSEC3-SHA1) | 5083 |
| 8 (RSA/SHA-256) | 7003 |
| 10 (RSA/SHA-512) | 201 |
| 13 (ECDSA-Kurve P-256 mit SHA-256) | 23 |
Die auffälligste Erkenntnis ist, dass nur 15.643 der 1.000.000 Websites DNSSEC in jeglicher Form aktiviert haben. Von diesen 1,5 % sind nur 23 Zonen mit Algorithmus 13 gekennzeichnet. Und über die Hälfte dieser Algorithmus-13-Zonen befinden sich hinter dem Cloudflare-Netzwerk. Das bedeutet, dass es weniger als ein Dutzend Zonen in der Alexa-Million gibt, die ECDSA außerhalb von Cloudflare verwenden. Dies stützt die Ergebnisse von Roland van Rijswijk-Deij et al., wonach 99,99 % der signierten Domains in .com, .net, und .org RSA verwenden.
Warum also ist die Nutzung von Algorithmus 13 so gering, vor allem angesichts der Tatsache, dass er so große Probleme bei DNSSEC löst? Nun, RSA wurde mit DNSSEC gleich zu Beginn des Protokolls eingeführt. ECDSA ist ein neuer kryptografischer Algorithmus, und Auflösung, Registrare und Registrierstellen müssen noch nachziehen.
ECDSA hat auch seine Nachteile. Laut Roland van Rijswijk-Deij et al., unterstützen nur 80 % der Auflösung die ECDSA-Validierung. Diese Zahl wächst zwar, heißt aber auch: Würden wir jetzt das gesamte DNSSEC-Internet auf ECDSA umstellen, würde die DNSSEC-Validierung für Millionen von Nutzern jeden Tag fehlschlagen und auf die Rückgabe ungeprüfter DNS-Einträge zurückfallen.
Darüber hinaus ist die Erstellung von ECDSA-Signaturen zwar schneller als die von RSA, die Validierung von Signaturen ist jedoch wesentlich langsamer. Roland van Rijswijk-Deij et al. haben gezeigt, dass ECDSA selbst mit den ECDSA-Optimierungen, die wir zu OpenSSL beigetragen haben, immer noch 6,6-mal langsamer ist als 1024-Bit RSA (der am häufigsten verwendete Algorithmus für Zonensignaturschlüssel). Dies ist ein ernsthaftes Problem, da eine Überlastung der DNS-Auflösung das gesamte Internet verlangsamen könnte.
Es gibt allerdings einen sehr wichtigen Haken am Algorithmus 13: Nur 1,5 % der Websites unterstützen DNSSEC in jeglicher Form. Nicht alle Registrare unterstützen DNSSEC; die Unterstützung einzuführen ist alles andere als leicht. Die Registrare müssen ihren Nutzern erlauben, DS-Einträge hochzuladen, die wiederum vom Registrar in das Register hochgeladen werden müssen. Wir arbeiten daran, diesen Prozess zu automatisieren, damit der Registrant den DS-Datensatz nicht mehr hochladen muss. Dennoch muss der Registrar weiterhin eingreifen.
Die gute Nachricht ist, dass wir auf dem richtigen Weg sind. In den letzten 12 Monaten ist die Adoption von DNSSEC stark gestiegen. Und in den drei Wochen zwischen unserer öffentlichen DNSSEC-Beta und unserer Ankündigung von Universal DNSSEC haben Hover, OVH, Metaname, Internet.bs, und das .NZ-Register die Unterstützung für Algorithmus 13 implementiert.Wir glauben, dass DNSSEC eine unverzichtbare Technologie für das moderne Web ist und dass ECDSA eine weltweite Einführung von DNSSEC realistisch werden lässt. Es bleibt zu hoffen, dass Algorithmus 13 auch weiterhin von großen und kleinen Registraren und Registern unterstützt wird.