Zusammenfassung

  • Revision 12 ist ein aktiver experimenteller Internet-Draft, kein RFC und kein Beleg für Implementierung oder Einsatz.
  • Das HTTPS-authentifizierte JSON beschreibt einen gewünschten Zustand; Einschreibung und Richtlinie der Zone Factory behalten die DNS-Schreibautorität.
  • Endpunkttest, erzeugter RRset, autoritative Veröffentlichung, Cache-Ablauf, Clientauswahl, ECH und Anwendungsergebnis sind eigene Quittungen.
  • regeninterval ist eine mögliche Erzeugungsfrequenz, kein globaler Ablaufzeitpunkt.

Ein Test endet vor der Verteilung

SVCB- und HTTPS-Records verteilen Verbindungsparameter über DNS. Weil ECH-Konfigurationen häufiger wechseln können als traditionelle Zonenprozesse, schlägt der Entwurf einen Übergang vor: Der Ursprung veröffentlicht JSON, eine Zone Factory ruft es ab, prüft es und erzeugt unter lokaler Richtlinie DNS-Daten.

Für ECH soll sie vor der Veröffentlichung testen, ob die präsentierten Werte mit dem Backend funktionieren. Dafür kann ein spezieller TLS-Client nötig sein, der noch nicht im DNS veröffentlichte ECHConfigList-Werte verwendet und den tatsächlichen ECH-Erfolg beobachtet.

Der Test beweist jedoch nur seinen Pfad und Zeitpunkt. Er beweist keinen Zone-Commit, keine Übernahme durch alle autoritativen Server und keinen Ablauf alter Resolver-Caches. Ein vollständiger Nachweis verbindet Testergebnis, RRset-Hash, Zonenserial, autoritative Proben, TTL und Beobachtungen aus Clientpfaden.

Ein Dokument äußert Wunsch, keine DNS-Anweisung

Eine erfolgreiche HTTPS-Abfrage belegt, dass ein bestimmter Ursprung unter einem akzeptierten Zertifikat ein Dokument geliefert hat. Sie belegt nicht, dass die Zone Factory diesen Ursprung eingeschrieben, den Owner-Namen genehmigt, den Inhalt verstanden oder eine Zonenänderung vorgenommen hat.

Der Entwurf hält die Synthese standardmäßig ausgeschaltet. Ihre Aktivierung soll eine Konfigurationsänderung des Betreibers erfordern. Damit wird ein öffentlich auffindbares Well-Known-Dokument nicht überraschend zur DNS-Delegation.

Die Einschreibung braucht Ursprung, Port, Owner-Name, Record-Typ, Prüfpolicy, Verantwortlichen und Policy-Epoche. Für beliebige SVCB-kompatible Namen existiert im Allgemeinen kein HTTP-Ursprung, der von sich aus zu ihrer Kontrolle berechtigt wäre. Eine explizite Zuordnung zu URL oder lokaler Quelle bleibt nötig.

Der Port gehört zur Autorität

Ein Ursprung kann nur für sich selbst sprechen. Betrifft der Dienst Port 8443, muss die Zone Factory den Well-Known-Pfad dieses Ursprungs verwenden, wenn sie den portpräfixierten HTTPS-Namen bearbeitet. Ein Dokument auf Port 443 entdeckt nicht automatisch weitere Dienste derselben Maschine.

AliasMode und Vermittler lösen diese Grenze nicht auf. Nutzt ein Ursprung CDN oder andere Zwischenstellen, bleibt er dafür verantwortlich, dass sein JSON deren aktuelle Konfiguration abbildet.

Im ECH-Split-Mode kommen zwei Vertrauensübergänge hinzu: Das Backend bezieht Parameter vom Client-Facing Server und stellt anschließend sein gewähltes Dokument der Zone Factory bereit. Die HTTPS-Authentisierung des Backend-Dokuments belegt nicht rückwirkend, wie die vorgelagerten Werte gewonnen wurden.

Gültiges JSON kann abgelehnt werden

Das Objekt enthält regeninterval und endpoints; unbekannte Schlüssel auf oberster Ebene werden ignoriert. Eine leere Endpoint-Liste ist ein Fehler. ServiceMode, AliasMode, Priorität, Target und Parameter müssen nach der Umwandlung weiterhin den SVCB- und HTTPS-Regeln entsprechen.

Kann ein SvcParamKey nicht umgesetzt werden oder fällt die Zonenprüfung durch, darf DNS nicht aktualisiert werden. Der Ursprung sieht diese Ablehnung möglicherweise nicht. Ein Dashboard, das nur HTTP 200 erfasst, schreibt dann eine richtige Verweigerung als Veröffentlichungserfolg.

Der Kontrollbeleg enthält Zertifikatsidentität, Body-Hash, Parsergebnis, normalisierte Endpoints, abgelehnte Felder, erzeugten RRset-Hash, Policy-Version und Entscheidung. „Unverändert“, „geändert und ungültig“ sowie „gültig, aber lokal verweigert“ sind getrennte Zustände.

Prüfabdeckung muss zur Veröffentlichung passen

Ein ECHConfigList kann absichtlich nicht funktionierende GREASE-Werte enthalten. Deshalb ist weder „alle Elemente müssen funktionieren“ noch „ein Element genügt“ eine vollständige Regel. Erwartete und unerwartete Fehlschläge brauchen Kennzeichnung.

In Multi-CDN-Umgebungen erreicht die Zone Factory vielleicht nur eine Adresse. Weichen ipv4hint oder ipv6hint von A/AAAA ab, soll sie die webPKI-Authentisierung an allen relevanten Adressen prüfen. Ein erfolgreicher Pfad genehmigt nicht automatisch andere Familien, Ports oder Anbieter.

Die Prüftabelle nennt Endpoint, Adresse, ECHConfig-Index, GREASE-Erwartung, Zertifikatsnamen, ALPN, Port, Zeitpunkt und Ergebnis. Nur so besitzt „ECH erfolgreich“ einen belastbaren Nenner.

regeninterval ist keine Verfallszeit

Der Wert beschreibt, wie häufig Ersatz erzeugt werden kann. Er ist kein präzises notAfter. Die Zone Factory sollte eine kürzere TTL setzen und vor diesem Zeitpunkt erneut abrufen und erzeugen.

Trotzdem laufen Ursprungserzeugung, Polling, Zonencommit, autoritative Replikation, rekursive Caches und Client-Caches nach eigenen Uhren. retry_configs erlaubt zudem bewusste Versionsüberlappung. Der Zeitpunkt der JSON-Änderung kann deshalb keine globale Rotation bescheinigen.

Bei mehreren Zone Factories kann eine Instanz einen Parameter verstehen, während eine andere ihn ablehnt. Lokale Korrekturen oder TTL-Anpassungen können ebenfalls abweichen. Zur Abstimmung gehören semantische RRset-Hashes und autoritative Sonden, nicht nur Textvergleiche.

Rückzug ist mehr als ein fehlgeschlagener Abruf

Revision 12 definiert weder das Hinzufügen oder Entfernen von Ursprüngen aus der Polling-Liste noch eine Anforderung des Client-Facing Servers zur Löschung aller HTTPS-Records. Bleibt nach dem Austritt altes JSON erreichbar, kann unerwünschte Veröffentlichung weitergehen.

Ein 404 darf dennoch nicht automatisch DNS löschen; er kann vorübergehend oder fehlgeleitet sein. Unendliches Beibehalten konserviert wiederum veraltete Endpoints. Rückzug braucht Autorität, Wirksamkeitszeit, Ersatz- oder Löschplan, Zonenserial und Beobachtung des Cache-Abbaus.

Die gewünschte Fehlerlage kann sich für ECH, Adresshinweise und Aliase unterscheiden. Sie muss vorab regiert werden und darf nicht aus dem Zufall eines Cronjobs entstehen.

Der Well-Known-Pfad ist keine Client-Abkürzung

Allgemeine HTTP-Clients sollen das öffentliche Dokument nicht statt einer HTTPS/SVCB-Abfrage über ihren bevorzugten Resolver verwenden. Der Bootstrap könnte ECH noch nicht einsetzen und würde genau den Namen offenlegen, den ECH schützen soll.

Außerdem könnte der Ursprung einem einzelnen Abrufenden eine eindeutige Konfiguration liefern. DNS-Verteilung und Caching besitzen andere Aggregations- und Policy-Eigenschaften als individuelle HTTPS-Antworten.

Clientbelege halten Resolverpfad, RRset-Generation, Cachealter, gewählten Endpoint, ECHConfig, Handshake und Anwendungsergebnis fest. Der JSON-Abruf bleibt im Kontrollpfad der Zone Factory.

Kurzer Zugriff kann lange Wirkung haben

Falsche DNS-Werte können Privatsphäre verlieren lassen oder durch wiederholte retry_configs den Dienst verschlechtern. Da webPKI DNS oder HTTP zur Namenskontrolle nutzen kann, könnte ein zeitweiliger Angreifer mit JSON-Zugriff bei schwacher Prüfkette länger wirkende DNS- oder Zertifikatskontrolle vorbereiten.

Das ist ein Risikomodell, kein beobachteter Angriff. Abweichende Adresshinweise müssen mit A/AAAA verglichen und an allen relevanten Adressen authentisiert werden. CAA-Historie kann weitere Trennung schaffen. Routing und Identität dürfen nicht mit derselben kompromittierbaren Eingabe geschlossen werden.

Auch die Dateiauslieferung braucht Grenzen. Verzeichnisdurchquerung oder Enumeration darf niemals private ECH-Schlüssel neben dem öffentlichen JSON erreichbar machen.

Quellen und Grenzen

Das eingefrorene Paket umfasst Revision 12 mit Akte, Historie und Referenzen; die TLS-Arbeitsgruppe; SVCB/HTTPS; ECH-Bootstrap; ECH; Well-Known-URIs; TLS 1.3; ACME; CAA; IANA-Register und Key-Share-Prediction.

Die Quellen belegen Protokoll-, Register- und Risikoaussagen. Sie belegen keine eingesetzte Zone Factory, DNS-Publikation, ECH-Verbindung, Cache-Konvergenz, Zertifikatsausstellung, Verfolgung, Kompromittierung oder Anwendungsauswirkung. Der Einstieg ist ein konstruierter Fall.

Quellen