1. Einführung (Introduction)
Die „DNS Security Extensions (DNSSEC)" [RFC9364] werden verwendet, um die Authentifizierung von DNS-Daten bereitzustellen. Die DNSSEC-Signaturalgorithmen sind durch verschiedene RFCs definiert, darunter [RFC4034], [RFC4509], [RFC5155], [RFC5702], [RFC5933], [RFC6605] und [RFC8080].
Um Interoperabilität sicherzustellen, ist ein Satz „mandatory-to-implement" DNS Public Key (DNSKEY)-Algorithmen in [RFC8624] definiert. Um den aktuellen Status der Algorithmen leichter zugänglich und verständlich zu machen und zukünftige Änderungen an diesen Empfehlungen einfacher zu veröffentlichen, verschiebt dieses Dokument den kanonischen Status der Algorithmen von [RFC8624] zu den IANA DNSSEC-Algorithmusregistern. Dieses Dokument integriert auch die überarbeiteten IANA DNSSEC-Überlegungen aus [RFC9157]. Zusätzlich fügt es als Rat an Betreiber Empfehlungen für die Bereitstellung und Verwendung dieser Algorithmen hinzu.
Dies ähnelt dem Prozess, der für das Register „TLS Cipher Suites" [TLS-ciphersuites] verwendet wird, wo die kanonische Liste der Cipher Suites im IANA-Register ist und RFCs auf das IANA-Register verweisen.
1.1. Dokumentzielgruppe (Document Audience)
Die zu den IANA-Registern „DNS Security Algorithm Numbers" [DNSKEY-IANA] und „Digest Algorithms" [DS-IANA] hinzugefügten Spalten richten sich an DNSSEC-Betreiber und -Implementierer.
Implementierungen müssen hohe Sicherheitserwartungen erfüllen und gleichzeitig Interoperabilität zwischen verschiedenen Implementierungen und mit verschiedenen Versionen bieten.
Das Feld der Kryptographie entwickelt sich kontinuierlich weiter. Neue, stärkere Algorithmen erscheinen, und bestehende Algorithmen können sich als weniger sicher erweisen als ursprünglich angenommen. Daher müssen Algorithmusimplementierungsanforderungen und Nutzungsanleitungen von Zeit zu Zeit aktualisiert werden, um die neue Realität widerzuspiegeln und einen reibungslosen Übergang zu sichereren Algorithmen sowie die Veraltung von Algorithmen zu ermöglichen, die als nicht mehr sicher gelten.
Implementierungen müssen bei der Auswahl der von ihnen implementierten Algorithmen konservativ sein, um sowohl die Codekomplexität als auch die Angriffsfläche zu minimieren.
Die Perspektive der Implementierer kann sich von der eines Betreibers unterscheiden, der DNSSEC nur mit dem sichersten Algorithmus bereitstellen und konfigurieren möchte. Daher fügt dieses Dokument auch neue Empfehlungen hinzu, welche Algorithmen unabhängig vom Implementierungsstatus bereitgestellt werden sollten. Im Allgemeinen wird erwartet, dass die Bereitstellung alternder Algorithmen in der Regel reduziert werden sollte, bevor Implementierungen aufhören, sie zu unterstützen.
1.2. Aktualisierung der Algorithmusanforderungsebenen (Updating Algorithm Requirement Levels)
Zu dem Zeitpunkt, an dem ein DNSSEC-kryptographischer Algorithmus zur obligatorischen Implementierung gemacht wird, sollte er bereits in den meisten Implementierungen verfügbar sein. Dieses Dokument definiert eine IANA-Registrierungsänderung, um zukünftigen Dokumenten zu ermöglichen, die Implementierungsempfehlungen für jeden Algorithmus zu spezifizieren, da sich der Empfehlungsstatus jedes DNSSEC-kryptographischen Algorithmus im Laufe der Zeit voraussichtlich ändern wird. Zum Beispiel gibt es keine Garantie, dass neu eingeführte Algorithmen in Zukunft obligatorisch zu implementieren werden. Ebenso sind veröffentlichte Algorithmen kontinuierlich kryptographischen Angriffen ausgesetzt und können zu schwach werden oder sogar vollständig gebrochen werden und erfordern in Zukunft eine Veraltung.
Es wird erwartet, dass die Veraltung eines Algorithmus schrittweise durchgeführt wird. Dies gibt Implementierungen Zeit, ihre implementierten Algorithmen zu aktualisieren und dabei interoperabel zu bleiben. Sofern keine starken Sicherheitsgründe vorliegen, wird erwartet, dass ein Algorithmus von MUST auf NOT RECOMMENDED oder MAY herabgestuft wird, anstatt direkt von MUST auf MUST NOT. Ebenso wird erwartet, dass ein Algorithmus, der nicht als obligatorisch zu implementieren erwähnt wurde, zunächst als RECOMMENDED anstatt als MUST eingeführt wird.
Da die Wirkung der Verwendung eines unbekannten DNSKEY-Algorithmus darin besteht, dass die Zone als unsicher behandelt wird, wird empfohlen, dass Algorithmen, die auf NOT RECOMMENDED oder niedriger herabgestuft wurden, nicht von autoritativen Nameservern und DNSSEC-Signierern verwendet werden, um neue DNSKEYs zu erstellen. Dies stellt sicher, dass die Verwendung veralteter Algorithmen im Laufe der Zeit abnimmt. Sobald ein Algorithmus ein ausreichend niedriges Bereitstellungsniveau erreicht hat, kann er als MUST NOT markiert werden, damit rekursive Resolver die Unterstützung für seine Validierung entfernen können.
Validierende rekursive Resolver werden ermutigt, die Unterstützung für alle Algorithmen beizubehalten, die nicht als MUST NOT markiert sind.
1.3. Anforderungsnotation (Requirements Notation)
Die Schlüsselwörter „MUST", „MUST NOT", „REQUIRED", „SHALL", „SHALL NOT", „SHOULD", „SHOULD NOT", „RECOMMENDED", „NOT RECOMMENDED", „MAY" und „OPTIONAL" in diesem Dokument sind wie in BCP 14 [RFC2119] [RFC8174] beschrieben zu interpretieren, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.
[RFC2119] betrachtet den Begriff SHOULD als gleichwertig mit RECOMMENDED und SHOULD NOT als gleichwertig mit NOT RECOMMENDED. Dieses Dokument hat sich dafür entschieden, die Begriffe RECOMMENDED und NOT RECOMMENDED zu verwenden, da dies die Empfehlungen an Implementierer klarer ausdrückt.