Anhang C. Besondere Betrachtungen

Die folgenden Absätze erläutern bestimmte Verhaltensweisen und besondere Aspekte für Implementierungen.

C.1. Salzen

Das Ergänzen ursprünglicher Eigentümernamen um einen Salt-Wert vor dem Hashing erhöht den Aufwand für ein Wörterbuch vorab berechneter Hash-Werte. Für jedes Bit des Salt-Werts verdoppelt sich der Aufwand für ein vorab berechnetes Wörterbuch, weil es für jedes Wort in Verbindung mit jedem möglichen Salt-Wert einen Eintrag geben muss. Der NSEC3-RR kann höchstens 2040 Bit (255 Oktette) Salt verwenden und vervielfacht den Aufwand damit um 2^2040. Ein Angreifer muss das Wörterbuch daher in der Praxis bei jeder Änderung des Salt-Werts neu berechnen.

Die Verwendung eines Salt-Werts beeinflusst, unabhängig von dessen Größe, nicht den Aufwand zum Erzeugen von NSEC3-RRs. Sie erhöht jedoch die Größe des NSEC3-RR.

Es MUSS mindestens einen vollständigen Satz von NSEC3-RRs für die Zone geben, der denselben Salt-Wert verwendet.

Der Salt-Wert SOLLTE regelmäßig geändert werden, um Vorabberechnungen für einen einzelnen Salt-Wert zu verhindern. Es wird EMPFOHLEN, den Salt-Wert bei jeder erneuten Signierung zu ändern.

Dies kann dazu führen, dass ein Resolver für dieselbe Zone RRs mit unterschiedlichen Salt-Werten sieht. Das ist unbedenklich, da jeder RR für sich allein steht: Er verneint die Menge von Eigentümernamen, deren Hashes bei Verwendung des im NSEC3-RR enthaltenen Salt-Werts zwischen den beiden Hashes im NSEC3-RR liegen. Nur der Server benötigt einen vollständigen Satz von NSEC3-RRs mit demselben Salt-Wert, um jede mögliche Anfrage beantworten zu können.

Es ist nicht verboten, innerhalb derselben Zone NSEC3-RRs mit unterschiedlichen Salt-Werten zu haben. Damit autoritative Server überdeckende NSEC3-RRs jedoch konsistent finden können, MUSS der autoritative Server beim Auswählen von NSEC3-RRs einen einzigen Parametersatz verwenden: Algorithmus, Salt und Iterationen.

C.2. Hash-Kollision

Hash-Kollisionen treten auf, wenn unterschiedliche Nachrichten denselben Hash-Wert besitzen. Bei einem Hash der Länge n Bit beträgt die erwartete Anzahl von Domainnamen, die für eine Wahrscheinlichkeit von 1 zu 2 für eine einzelne Kollision erforderlich ist, etwa 2^(n/2), für SHA-1 also 2^80. Obwohl diese Wahrscheinlichkeit äußerst gering ist, behandeln die folgenden Absätze die Vermeidung von Kollisionen und die Bewertung möglicher Schäden bei einem Angriff unter Ausnutzung von Hash-Kollisionen.

C.2.1. Vermeidung von Hash-Kollisionen bei der Erzeugung

Bei der Erzeugung von NSEC3-RRs werden Hash-Werte als eindeutig vorausgesetzt. Tritt im akademischen Fall dennoch eine Kollision auf, MUSS ein anderer Salt-Wert gewählt und MÜSSEN alle Hash-Werte neu erzeugt werden.

C.2.2. Analyse der Anforderung an zweite Urbilder

Eine kryptografische Hash-Funktion besitzt die Eigenschaft der Resistenz gegen zweite Urbilder. Diese Eigenschaft bedeutet, dass es rechnerisch nicht durchführbar ist, zu einer gegebenen Nachricht eine andere Nachricht mit demselben Hash-Wert zu finden: Zu einem gegebenen Urbild X ist also kein zweites Urbild X' != X auffindbar, für das hash(X) = hash(X') gilt. Der Arbeitsaufwand zum Finden eines zweiten Urbilds liegt bei SHA-1 in der Größenordnung von 2^160. Um einen Angriff unter Verwendung eines vorhandenen NSEC3-RR durchzuführen, muss ein Angreifer ein zweites Urbild finden.

Angenommen, ein Angreifer könnte einen solch extremen Angriff durchführen, bestünde der tatsächliche Schaden darin, dass eine Antwortnachricht erzeugt werden kann, die behauptet, ein bestimmter QNAME, also das zweite Urbild, existiere, obwohl der QNAME tatsächlich nicht existiert. Dies ist ein falsch positives Ergebnis und führt entweder dazu, dass ein sicherheitsbewusster Resolver die Anfrage nach dem nicht vorhandenen Namen erneut stellt, oder dass die ursprüngliche Anfrage fehlschlägt. Der Angreifer kann diesen Angriff nicht auf einen vorhandenen Namen anwenden, sondern nur auf einen Namen, den er nicht wählen kann und der noch nicht existiert.