12. Security Considerations (Sicherheitshinweise)

12.1. Hashing Considerations (Überlegungen zum Hashing)

12.1.1. Dictionary Attacks (Wörterbuchangriffe)

NSEC3 RRs bleiben anfällig für Wörterbuchangriffe (d. h. der Angreifer holt alle NSEC3 RRs, berechnet Hashes aller möglichen Domainnamen und vergleicht sie mit den in den NSEC3 RRs gefundenen Hashwerten, um die Zone aufzuzählen). Diese Angriffe sind wesentlich teurer als die Aufzählung ursprünglicher NSEC RRs; in jedem Fall kann ein solcher Angriff auch direkt gegen den Nameserver durch Abfragen aller möglichen Namen gerichtet werden, was jedoch leichter zu erkennen ist. Die Kosten eines solchen Offline-Angriffs können durch die Wahl der Iterationsanzahl in den NSEC3 RRs beeinflusst werden.

Zonen sind außerdem anfällig für vorberechnete Wörterbuchangriffe – d. h. einmalige Berechnung einer Hash-Liste für alle möglichen Namen und regelmäßiges Scannen der NSEC3 RRs gegen diese vorberechneten Hashwerte. Regelmäßige Salt-Änderungen können solche Angriffe verhindern.

Das Salt SOLLTE mindestens 64 Bit lang und unvorhersagbar sein, damit der Angreifer den Salt-Wert nicht vor Veröffentlichung der Zone erraten und das nächste Wörterbuch vorberechnen kann.

12.1.2. Collisions (Kollisionen)

Zwischen QNAME und dem Owner-Namen eines NSEC3 RR können Hash-Kollisionen auftreten. Tritt eine auf, kann die Nichtexistenz des kollidierenden QNAME nicht bewiesen werden. Für SHA-1 ist dies jedoch extrem unwahrscheinlich (Größenordnung 1/2^160). DNSSEC setzt bereits voraus, dass kryptographische Hash-Funktionen zweite-Präimage-resistent (second preimage resistant) sind, da diese Funktionen zur Erzeugung und Verifikation von Signaturen und DS RRs verwendet werden.

12.1.3. Transitioning to a New Hash Algorithm (Übergang zu einem neuen Hash-Algorithmus)

Obwohl die NSEC3- und NSEC3PARAM-RR-Formate einen Hash-Algorithmus-Parameter enthalten, definiert dieses Dokument kein spezifisches Verfahren für einen sicheren Übergang von einem NSEC3-Hash-Algorithmus zu einem anderen. Wird ein neuer Hash-Algorithmus für NSEC3 spezifiziert, MUSS gleichzeitig ein Übergangsverfahren definiert werden. Möglicherweise ist der einzig praktikable und akzeptable Übergang ein Zwischenzustand der Unsicherheit oder ein Zustand mit NSEC- statt NSEC3-Datensätzen.

12.1.4. Using High Iteration Values (Hohe Iterationswerte)

Da Validatoren Antworten mit NSEC3 RRs mit hohen Iterationswerten als unsicher behandeln sollen, kann bereits ein einzelner signierter NSEC3 RR mit hohem Iterationswert in der Zone einem Angreifer eine mögliche Downgrade-Attacke ermöglichen.

Der Angriff besteht darin, vorhandene NSEC3 RRs aus der Antwort zu entfernen und durch einen (oder mehrere) NSEC3 RR(s) mit hohem Iterationswert zu ersetzen oder hinzuzufügen. Der Validator muss die Antwort dann als unsicher behandeln. Der Angriff wirkt nur, wenn alle folgenden Bedingungen gelten:

In der Zone existiert mindestens ein signierter NSEC3 RR mit hohem Iterationswert.
Der Angreifer hat Zugriff auf einen oder mehrere dieser NSEC3 RRs. Dies ist offensichtlich, wenn solche NSEC3 RRs in typischen Antworten zurückgegeben werden, kann aber auch zutreffen, wenn der Angreifer die Zone per AXFR, IXFR oder anderweitig erhält.

Hohe Iterationszahlen erhöhen zudem das DoS-Risiko für Server, da der Server für jede negative oder Wildcard-Antwort mehrere Hashes berechnen muss.

12.2. Opt-Out Considerations (Überlegungen zu Opt-Out)

Das Opt-Out-Flag (O) erlaubt unsignierte Namen (in Form von Delegationen zu unsignierten Zonen) innerhalb anderer signierter Zonen. Per Definition sind alle unsignierten Namen unsicher; ihre Gültigkeit oder Existenz kann nicht kryptographisch bewiesen werden.

Allgemein:

Ressourcendatensätze mit unsignierten Namen (ob vorhanden oder nicht) unterliegen denselben Schwachstellen wie RRs in unsignierten Zonen. Diese werden in [RFC3833] ausführlicher beschrieben (insbesondere Abschnitt 2.3 „Name Chaining“ und Abschnitt 2.6 „Authenticated Denial of Domain Names“).
Ressourcendatensätze mit signierten Namen haben unabhängig von Opt-Out dieselbe Sicherheit.

Hinweis: Unsichere Delegationen können von Angreifern unbemerkt geändert werden, mit oder ohne Opt-Out. Der Hauptsicherheitsunterschied bei Opt-Out ist daher der Verlust der Fähigkeit, innerhalb der Spanne eines Opt-Out-NSEC3 RR die Existenz oder Nichtexistenz unsicherer Delegationen zu beweisen.

Insbesondere kann eine böswillige Instanz RRs mit unsignierten Namen einfügen oder entfernen. Dies sind typischerweise NS RRs, umfasst aber auch signierte Wildcard-Expansionen (obwohl die Wildcard-RR selbst signiert ist, sind die expandierten Namen unsignierte Namen).

Hinweis: Das Hinzufügen einer Delegation ist funktional gleichbedeutend mit dem Hinzufügen beliebiger RR-Typen: Der Angreifer fälscht eine Delegation zu einem Nameserver unter seiner Kontrolle und platziert am Kindzonenapex die gewünschten RRs.

Obwohl dies in Einzelfällen kein großes Sicherheitsrisiko darstellt, sollte es im Allgemeinen nicht leichtfertig ignoriert werden. Opt-Out sollte daher mit Vorsicht eingesetzt werden. Insbesondere SOLLTE Zonensignierungssoftware Opt-Out nicht standardmäßig verwenden und KANN Opt-Out gar nicht unterstützen.

12.3. Other Considerations (Weitere Überlegungen)

Das Durchlaufen der NSEC3-RR-Kette offenbart die Gesamtzahl der RRs in der Zone (plus leere Nicht-Endknoten) sowie welche Typen existieren. Dies lässt sich durch Scheineinträge mildern, eine obere Grenze ist jedoch weiterhin ableitbar.