Zusammenfassung

  • Das SEP-Bit kennzeichnet den vorgesehenen betrieblichen Einsatz eines DNSKEY-Schlüssels. Es kann Werkzeuge bei der DS-Erzeugung unterstützen, beweist aber weder Authentizität noch eine Vertrauenskette.
  • RFC 4034 und RFC 4035 verbieten Validierern, ihr Prüfverhalten wegen des gesetzten Bits 15 zu ändern. Ein SEP-markierter Schlüssel benötigt weiterhin das Zone-Key-Bit, um Signaturen über Resource-Record-Sets zu prüfen.
  • Edward Lewis ist einer von drei Mitautoren von RFC 3757. Belegt ist dieser Beitrag zur Spezifikation; daraus folgen weder alleinige Urheberschaft noch Verantwortung für eine bestimmte Implementierung oder eine heutige Beschäftigung.

Was ein Flag entscheiden darf

DNSSEC verbindet zwei Veröffentlichungen: Die untergeordnete Zone veröffentlicht DNSKEY-Einträge, die übergeordnete Zone kann mit einem DS-Eintrag den Delegationsbezug zu einem Schlüssel herstellen. Dazwischen liegt ein wichtiger Unterschied. Die Absicht eines Betreibers ist keine kryptografische Bestätigung. Das Secure-Entry-Point-Bit (SEP) hilft bei der ersten Aufgabe, nicht bei der zweiten.

RFC 3757 erschien im April 2004, verfasst von Olaf Kolkman, Jakob Schlyter und Edward Lewis. Sie ergänzte das DNSKEY-Flagfeld um SEP für Schlüssel, die als sichere Einstiegspunkte behandelt werden sollten. Als praktische Beispiele nennt sie die Unterstützung bei der Erzeugung von DS-Einträgen und die Kennzeichnung statisch zu konfigurierender Schlüssel. Zugleich hält sie ausdrücklich fest, dass das DNS-Verifikationsprotokoll SEP nicht verwendet. Der Name ist daher kein Gütesiegel für die Echtheit eines Schlüssels.

Bei der DS-Erzeugung kann ein Signaturwerkzeug einen SEP-markierten Schlüssel aus dem DNSKEY-Satz der untergeordneten Zone auswählen. Danach bleiben zwei eigenständige Kontrollen: Stimmen Schlüssel und berechneter DS überein, und veröffentlicht die übergeordnete Zone den richtigen DS? Ein Flag in der Kindzone kann die Handlung des Elternbetreibers nicht bestätigen. Es macht auch eine Signatur nicht gültig. Der validierende Resolver muss die DNSSEC-Regeln anwenden, unabhängig davon, welchen Schlüssel ein Werkzeug bevorzugt hat.

Die 2005 veröffentlichten RFCs 4034 und 4035 lösten RFC 3757 ab und bewahrten diese Grenze. RFC 4034 beschreibt SEP als Hinweis für Signier- und Debugging-Software. RFC 4035 schreibt vor, dass sich das Validierungsverhalten durch das gesetzte SEP-Bit nicht ändern darf. Außerdem ersetzt SEP nicht das Zone-Key-Bit: Für die Prüfung von RRset-Signaturen muss der DNSKEY-Schlüssel auch dieses Bit tragen. SEP sagt etwas über die gewünschte Behandlung; Zone Key über eine Protokollrolle bei der Signaturprüfung.

RFC 6781 erklärt, weshalb das Flag im Betrieb dennoch nützlich bleibt. Häufig ist SEP bei einem Key-Signing-Key (KSK) gesetzt, der in den Austausch mit der übergeordneten Zone eingeht, beim Zone-Signing-Key (ZSK) dagegen nicht. Manche Betriebsmodelle nutzen jedoch nur einen Schlüsseltyp für Aufgaben, die das KSK/ZSK-Modell trennt. Werkzeuge, die zwei Typen voraussetzen, können Einträge dann unpassend auswählen oder darstellen. RFC 6781 warnt vor möglicher Verwirrung in bestimmten Signierwerkzeugen. Das rechtfertigt einen Test der konkret eingesetzten Software, belegt aber keinen tatsächlichen Validierungsfehler.

SEP ist auch nicht mit dem REVOKE-Bit aus RFC 5011 gleichzusetzen. Diese Spezifikation definiert automatische Aktualisierungen von Trust Anchors und dafür einen eigenen Widerrufsstatus. Die beiden Flags gehören zu getrennten Abläufen. Ihre Vermischung würde aus einer Betriebshilfe fälschlich ein Widerrufs- oder Vertrauenssignal machen.

Auch die biografische Aussage über Lewis braucht eine enge Beleggrundlage. RFC 3757 nennt ihn als einen von drei Autoren; sein IETF-Datatracker-Profil führt die Spezifikation auf, und seine Autorenseite bei Internet Society liefert begrenzten beruflichen Kontext. Diese Quellen zeigen nicht, dass er SEP allein entworfen oder eine konkrete Software implementiert hat. ARIN in der RFC ist eine historische Zugehörigkeitsangabe, kein Nachweis einer heutigen Stelle. Die Normtexte liefern ebenso wenig Zahlen zu Verbreitung, Fehlerraten oder Vorfällen.

Belastbar ist nur: SEP kann den Umgang mit Schlüsseln organisieren; Vertrauen entsteht erst durch die DS-Beziehung und die regelgerechte Validierung.

Quellen