ECDSA: Was DNSSEC bislang fehlte

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 hat auch seine Nachteile. Laut Roland van Rijswijk-Deij et al., unterstützen nur 80% der Resolver 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öser 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, und das Hinzufügen von Unterstützung ist keine triviale Sache. Sie 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, aber der Registrar muss immer noch 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.