Zusammenfassung

  • RFC 9558 ordnet GOST R 34.10-2012 die DNSSEC-Algorithmusnummer 23 und GOST R 34.11-2012 den DS-Digest-Typ 5 zu und definiert ein enges Binärprofil.
  • Das Dokument ist eine Informational Independent Submission ohne IETF-Konsens; es bescheinigt weder kryptografische Eignung noch Implementierungs- oder Marktabdeckung.
  • Belastbare Aussagen benötigen einzelne Belege für Registrierung, Signer-Unterstützung, Veröffentlichung, Eltern-DS, Validator-Fähigkeit, geprüfte Kette und Anwendungsergebnis.

Ein Resolver sah eine signierte Zone, der andere eine unsignierte

Die Zonendaten waren identisch. DNSKEY mit Algorithmus 23, passende RRSIGs, DS-Digest-Typ 5 beim Parent. Der erste rekursive Resolver unterstützte GOST 2012 und baute eine sichere Kette. Der zweite konnte weder den Schlüsselalgorithmus noch den Digest verarbeiten und behandelte die Child-Zone wie eine unsignierte Delegation.

Diese Abweichung ist keine Randnotiz, sondern die zentrale Betriebsgrenze. Nach den von RFC 6840 präzisierten Regeln werden authentifizierte DS-Einträge mit unbekannten oder nicht unterstützten Algorithmen bei der Pfadsuche verworfen. Bleibt kein unterstützter Pfad, ist das Ergebnis Insecure statt einer geprüften GOST-Signatur.

IANA hat in diesem Moment nichts falsch gemacht. Das Register hat den Gegenstand eindeutig benannt. Es hat nur keine Software auf dem zweiten Resolver installiert. Koordination und Ausführung sind verschiedene Autoritätsflächen.

Der Publikationsstrom begrenzt den Anspruch

RFC 9558 erschien im April 2024 als Informational im Independent Submission stream. Es ist kein Internet Standards Track-Dokument, hat keinen Konsens der IETF-Community und wird vom IETF-Standardisierungsprozess nicht gebilligt. Der RFC Editor trifft mit der Veröffentlichung keine Aussage zum Wert für Implementierung oder Deployment.

Auch die kryptografische Warnung ist eindeutig: Die Eigenschaften der russischen Nationalstandards GOST R 34.10-2012 und GOST R 34.11-2012 wurden in diesem Zusammenhang nicht unabhängig verifiziert. Weder IETF noch IRTF haben ihre Eignung für eine konkrete Anwendung untersucht.

Das ist keine pauschale Ablehnung. Es trennt die nachweisbare Leistung des Dokuments von einer nicht vorhandenen Empfehlung. RFC 9558 koordiniert die Darstellung für freiwillige Implementierer. Die Akzeptanzentscheidung bleibt beim Betreiber und bei der vertrauenden Partei.

Interoperabilität hängt an 64 Oktetten

Das Profil wählt die 256-Bit-Signaturvariante, den 256-Bit-Digest und Parametersatz A. Der Kurvenpunkt Q=(x,y) wird in DNSKEY als genau 64 Oktette abgelegt: 32 Oktette little-endian für x, danach 32 für y. Öffentlicher Schlüssel und Signatur haben jeweils 512 Bit, der Digest 256 Bit.

Wer die Byte-Reihenfolge vertauscht, kann intern mit einem gültigen mathematischen Punkt arbeiten und auf der Leitung trotzdem ein unbrauchbares Objekt erzeugen. Für bestehende GOST-fähige X.509-APIs gibt RFC 9558 ein festes 30-Byte-ASN.1-Präfix an. Diese Hülle konvertiert ein Format; sie ist weder Zertifikat noch Vertrauensentscheidung.

Für RRSIG wird die Signiereingabe nach RFC 4034 mit GOST R 34.11-2012 gehasht und mit GOST R 34.10-2012 signiert. Das veröffentlichte k des Beispiels macht den Test reproduzierbar und darf ausdrücklich nicht produktiv wiederverwendet werden. Ein bestandener Testvektor belegt keine sichere Nonce-Erzeugung.

Die Nummern 23 und 5 schließen verschiedene Lücken

IANA führt ECC-GOST12 als DNSSEC-Algorithmus 23. In einem anderen Register steht GOST R 34.11-2012 als DS-Digest-Typ 5 mit Status OPTIONAL. Nummer 23 beschreibt DNSKEY und RRSIG; Typ 5 beschreibt die Verdichtung, mit der der Parent auf den Child-Key verweist.

Eine gültige Signatur ohne brauchbaren DS verbindet das Kind nicht mit dem Parent. Ein passender DS ohne Algorithmus-Support verbindet nichts mit dem Validator. Selbst bei Support können alte Caches, andere Trust Anchors oder eine abgelaufene Signatur das Ergebnis verändern.

Ein Auditbeleg muss deshalb DNSKEY-, RRSIG- und DS-RRsets, Parent- und Child-Beobachtung, Seriennummer, Signaturfenster, TTL, Trust Anchor, Validator-Version und Algorithmusinventar zusammenhalten. „DNSSEC an“ ist kein reproduzierbarer Befund.

Nicht unterstützt ist nicht Bogus

Wenn ein Validator alle möglichen Pfade wegen fehlender Unterstützung verwirft, behandelt er die Zone unter diesen Regeln wie unsigniert. Bogus bezeichnet dagegen einen Pfad, dessen prüfbare Signaturen oder Beziehungen scheitern. Beide Zustände verlangen andere Maßnahmen.

Eine erneute Signatur installiert keinen fehlenden Algorithmus beim Empfänger. Ein Software-Upgrade repariert keine tatsächlich falsche RRSIG. Darum muss ein Vorfall festhalten, welcher Validator mit welchem Versions- und Algorithmusstand welche RRsets zu welchem Zeitpunkt gegen welchen Trust Anchor bewertete.

Der erfolgreiche Test eines Teams beweist nur seinen Beobachtungspunkt. Er ist keine Stichprobe für die gesamte Resolver-Landschaft.

Duale KSKs schaffen Übergangszeit und zusätzlichen Zustand

RFC 9558 empfiehlt eine Zone mit zwei KSK-Algorithmen, solange GOST-fähige DNSSEC-Software nicht weit verbreitet ist, sofern GOST-only nicht ausdrücklich beabsichtigt ist. Ein zweiter Pfad hält die Authentifizierung für Validatoren offen, die Algorithmus 23 nicht kennen.

Gleichzeitig müssen mehr Schlüssel, DS-Einträge, Signaturen, Zeitfenster, Parent-Änderungen und Caches koordiniert werden. RFC 6840 empfiehlt, jede gültige RRSIG als ausreichend zu akzeptieren und erst bei Scheitern aller Signaturen Bogus zu erklären. Restriktivere lokale Richtlinien und zeitlich versetzte Caches bleiben mögliche Spaltstellen.

Vor dem Entfernen des alten Pfads müssen unabhängige Messpunkte den neuen Parent-Child-Pfad über den relevanten Cache-Horizont bestätigen. Zwei sichtbare Schlüssel sind eine Bestandsaufnahme, kein Löschbeleg.

Nach DNSSEC beginnt die Anwendungsentscheidung

Secure belegt, dass ein RRset nach DNSSEC-Regeln relativ zu einem konfigurierten Trust Anchor authentifiziert wurde. Es belegt nicht die juristische Identität des Betreibers, die Verfügbarkeit des Dienstes, universelle kryptografische Eignung oder den Erfolg einer späteren Verbindung.

DO fordert DNSSEC-Daten an, CD verändert die Prüfung, AD transportiert unter Bedingungen den Authentifizierungsstatus. Ein Stub auf einem nicht vertrauenswürdigen Kanal oder eine Anwendung, die den Status ignoriert, besitzt dadurch keinen Ende-zu-Ende-Beleg.

Der letzte Nachweis nennt Resolver, Kanal, Status, angewandte Richtlinie, Entscheidung und beobachtete Wirkung. RFC 9558 standardisiert ein Objekt. Es autorisiert nicht die Handlung, die danach folgt.

Quellen

Quellen