Eine gültige ECH-Datei kann der falschen Grenze dienen

Summary

Eine Prüfung nach RFC 9934 kann nachweisen, dass der private Schlüssel in einer PEM-Datei zu mindestens einer öffentlichen ECHConfig in der enthaltenen Liste passt. Sie weist nicht nach, dass die Datei für den betreffenden DNS-Inhaber, die erreichbare Servergruppe, die Wiederholungskonfiguration, die Anonymitätsmenge oder die gegenwärtige Lebenszyklusphase genehmigt wurde.
Es fehlt keine weitere Schlüsselkopie, sondern ein datensparsamer Richtlinien- und Bereitstellungsbeleg. Er sollte den Konfigurationshash mit dem autorisierten RRSet, der Endpunktkohorte, den Rollen für normalen Betrieb und Wiederholung, dem Überschneidungsfenster, den Rücknahmebedingungen und den verantwortlichen Genehmigern verbinden, ohne private Schlüssel oder eine Namensliste offenzulegen.

Was das grüne Prüfergebnis tatsächlich besagt

Ein Dateiprüfer kann eine angenehm eindeutige Antwort liefern. Die PEM-Begrenzungen stimmen. Der private Schlüssel ist als PKCS #8 gültig. Die ECHConfigList lässt sich dekodieren. Mindestens eine öffentliche Konfiguration in der Liste entspricht dem privaten Schlüssel. Die Datei ist nicht beschädigt, die kryptografische Beziehung besteht, und die Anzeige springt auf Grün.

Dieses Ergebnis ist wertvoll. Ohne ein gemeinsames Format könnten TLS-Bibliotheken, Geheimnisverwaltungen und Server jeweils eigene Behälter für ECH-Schlüsselmaterial verwenden. Rotation und Anbieterwechsel würden von unnötigen Konvertierungen abhängen. RFC 9934 legt fest, dass eine ECH-PEM-Datei null oder einen privaten Schlüssel und eine kodierte ECHConfigList enthält. Ist ein privater Schlüssel vorhanden, muss die Liste eine passende ECHConfig enthalten. Für den öffentlichen Teil gibt es die eigene Kennzeichnung ECHCONFIG; der private Teil darf niemals im DNS veröffentlicht werden.

Das grüne Signal beweist aber nur eine Beziehung innerhalb der Datei: Dieses private Element kann zu einem dieser öffentlichen Elemente gehören. Es beweist nicht, dass der Ersteller die Dienstgrenze festlegen durfte. Es nennt weder den DNS-Inhaber, der die Liste veröffentlichen soll, noch die Frontend-Knoten, die den Schlüssel erhalten dürfen. Es sagt nichts darüber, welche Namen gemeinsam auftreten, welche Dateien in retry_configs gelangen oder wann eine alte Konfiguration endgültig ausscheiden darf.

Kryptografische Evidenz verleitet zu einer Verwechslung des Geltungsbereichs. Für den eng formulierten Satz ist sie stärker als eine gewöhnliche Konfigurationskontrolle. Starke Evidenz für einen kleinen Satz wird jedoch nicht zur Evidenz für jede umliegende Organisationsentscheidung. Eine unterschriebene Paketquittung beweist die Übergabe, nicht die Berechtigung des Gebäudes zum Empfang. Ein passendes Schlüsselpaar wählt keine Datenschutzgrenze.

Die betriebliche Frage lautet deshalb nicht bloß: „Ist die Datei gültig?“ Sie lautet: „Für welchen genehmigten Bereitstellungszustand ist sie gültig?“

Eine Liste enthält mehrere Entscheidungen

RFC 9934 erlaubt absichtlich mehrere ECHConfig-Werte in absteigender Präferenz innerhalb einer ECHConfigList. Die Werte können unterschiedliche Erweiterungen oder unterschiedliche public_name-Angaben tragen. Ein TLS-Server darf zudem mehrere Dateinamen konfigurieren und nur einen Teil davon für die retry_configs auswählen, die er bei einer ECH-Ablehnung zurückgibt.

Diese Flexibilität hat gute Gründe. Mehrere Konfigurationen erleichtern Übergänge. Eine Rangfolge kann die Richtung einer Migration ausdrücken. Getrennte Dateien können dem regulären Betrieb, einer Vorbereitungsphase oder einer Notfalloption dienen. Wiederholungskonfigurationen helfen einem Client, der im DNS eine Konfiguration gesehen hat, die sein Zielserver noch nicht akzeptiert.

Jede Funktion bringt zugleich eine Entscheidung mit, die der interne Abgleich nicht erkennen kann. Wer hat die Reihenfolge genehmigt? Ist der neue Wert lediglich vorgeladen oder bereits bevorzugt? Erweitert eine Änderung von public_name den Kreis der Betreiber, die die äußere Verbindung bearbeiten? Eine zum normalen Entschlüsseln geladene Datei muss nicht automatisch für Wiederholungen beworben werden. Umgekehrt kann eine alte, nicht mehr bevorzugte Datei noch kurzzeitig nötig sein, um zwischengespeicherte Clientinformationen zu bedienen.

Die Feststellung „mindestens eine Übereinstimmung“ unterscheidet diese Rollen nicht. Sie beweist ebenso wenig, dass die Auswahl aus mehreren Dateien die gewünschte Wiederholungsmenge erzeugt. Format, Präferenz, betriebliche Rolle und Berechtigung bleiben getrennte Aussagen.

ECH wirkt über eine Kette, nicht in einer Datei

RFC 9849 beschreibt das ECH-Protokoll, RFC 9848 die DNS-Ermittlung. In einer echten Verbindung greifen beide ineinander. Der Client liest einen HTTPS- oder SVCB-Hinweis, konstruiert äußeren und inneren ClientHello, erreicht einen durch die Verkehrssteuerung gewählten Server und erwartet dort den passenden Schlüssel. Bei einer Ablehnung kann der Server neue Konfigurationen vorschlagen und eine weitere Verbindung auslösen.

Ein korrekter Schritt garantiert nicht die ganze Kette. Das autoritative DNS kann die neue Liste veröffentlichen, bevor sämtliche Standorte den Schlüssel geladen haben. Jeder einzelne Schlüsselcontainer ist gültig, auch das RRSet ist syntaktisch korrekt, doch ein Teil der Clients erreicht Knoten, die die beworbene Konfiguration nicht akzeptieren. Der Fehler erscheint zufällig und bleibt in einem Test gegen nur einen Host unsichtbar.

Auch die umgekehrte Zeitverschiebung ist möglich. Die Server sind bereits weiter, während Caches noch die alte Liste liefern. Wird der alte Schlüssel zu früh entfernt, verändern sich Verfügbarkeit und sichtbares Fehlerverhalten. Bleibt er unbegrenzt erhalten, wachsen Aufbewahrungsdauer und Schadensradius. Die Dateiform entscheidet den Konflikt zwischen Verbreitung, Kompatibilität und Exposition nicht.

Bei mehreren Cloud- oder CDN-Anbietern kann eine Alias- oder TargetName-Änderung Verkehr zu einer anderen Organisation führen. Ob diese Organisation denselben Schlüssel besitzen und derselben Datenschutzmenge angehören darf, ist eine Vertrags- und Dienstentscheidung. Die Fähigkeit, eine portable Datei zu überreichen, ist kein Mandat, die Grenze zu erweitern.

DNS-Veröffentlichung ist eine eigene Befugnis

Clients entdecken die öffentliche Liste gewöhnlich über den Parameter ech in HTTPS- oder SVCB-Einträgen. RFC 9460 liefert dafür das Service-Binding-Modell, die IANA führt die zugehörigen Parameter. Veröffentlicht wird die ECHConfigList, niemals der private Schlüssel aus der Datei. Die DNS-Daten und die Serverdatei müssen zusammenpassen, doch Zusammenpassen ist nicht dasselbe wie Veröffentlichungsbefugnis.

Zoneninhaber, TLS-Betreiber, Schlüsselverwahrer und Diensteigentümer können verschiedenen Organisationen angehören. Das DNS-Team darf vielleicht einen gelieferten Hash einspielen, aber nicht darüber entscheiden, welche Mandanten eine Entschlüsselungsinfrastruktur teilen. Das Plattformteam kann den Schlüssel verteilen, aber keinen externen Anbieter in die Grenze aufnehmen. Der Diensteigentümer wählt Namen, kontrolliert jedoch nicht zwangsläufig jede Adresse hinter dem TargetName.

Auch public_name ist kein erläuternder Kommentar. Der Wert prägt den sichtbaren äußeren Verbindungskontext und den Umgang mit einer Nichtannahme von ECH. Die Regeln zur Dienstidentität in RFC 9525 und die TLS-Grundlage in RFC 8446 machen eine Trennung deutlich: Ein Server kann mit einem Schlüssel entschlüsseln, ohne dazu berechtigt zu sein, jeden Dienst zu vertreten, der diesen äußeren Namen nutzt.

Ein Bereitstellungsbeleg sollte daher den kanonischen Hash des genehmigten RRSet, Zone oder Delegationspfad, erwarteten TargetName und Adressbestand, SVCB/HTTPS-Priorität, Cacheannahme und Veröffentlichungsfenster enthalten. Er ersetzt weder DNSSEC noch Zertifikatsprüfung oder Freigabeprozess. Er zeigt, ob diese eigenständigen Entscheidungen denselben Zustand meinen.

Serverabdeckung ist eine Mengeneigenschaft

Erhält ein Client eine Konfiguration und trifft auf einen Server ohne passenden Schlüssel, entsteht mehr als ein Verfügbarkeitsfehler. Wiederholungen, alternative Pfade und clientseitige Rückfallregeln erzeugen beobachtbare Unterschiede. Ein Teil des Verkehrs kann aus der Menge herausfallen, in der er zuvor nicht leicht unterscheidbar war.

„Die Datei ist installiert“ muss deshalb eine Kohorte beschreiben, nicht einen bevorzugten Host. Dazu gehören IPv4- und IPv6-Ziele, Wiederanlaufregionen, Ersatzanbieter, selten genutzte Reserven, vorübergehende Kapazität und Pools, die nach einer Störung wieder Gewicht erhalten. Während einer rollenden Aktualisierung können sämtliche Dateien für sich gültig sein, obwohl DNS und Server in unvereinbaren Generationen stehen.

Eine statische Instanzliste veraltet schnell. Geeigneter ist eine Kohorte, die durch Load Balancer, Dienstkonto, Region, Anbieter, Konfigurationshash und Bereitstellungsgeneration definiert wird. Der Beleg hält fest, welche Werte sie von wann bis wann akzeptieren soll und welche Prüfung zeigt, dass öffentliche Routen tatsächlich in dieser Kohorte endeten.

Dafür ist keine Überwachung einzelner Nutzer notwendig. Synthetische Prüfungen je Kohorte können öffentlichen Konfigurationshash, Annahmeverhalten, Wiederholungsantwort und laufende Generation erfassen. Gemessen wird die Infrastruktur, für die der Betreiber verantwortlich ist, nicht die Liste innerer Namen, die Menschen aufrufen.

Die Anonymitätsmenge ist keine PEM-Eigenschaft

ECH schützt Angaben im inneren ClientHello, beseitigt aber weder Zieladresse noch Zeitpunkt, Volumen oder sämtliche Merkmale des sichtbaren Verkehrs. Wenn viele Namen einen äußeren Namen, eine Konfiguration und einen Einstieg teilen, können sie eine größere, schwerer unterscheidbare Menge bilden. Eine feine Aufteilung oder ein charakteristischer Fehlerpfad verkleinert sie.

Die Datei kennt die Namen nicht, die gemeinsam in dieser Menge stehen dürfen. Sie kennt auch keine vertraglichen, regulatorischen oder betrieblichen Grenzen zwischen Mandanten. Eine größere Menge kann Beobachtung von außen erschweren, konzentriert jedoch Schlüsselzugriff und Vorfallwirkung. Eine kleinere Menge begrenzt interne Befugnisse, kann aber einzelne Dienste leichter erkennbar machen.

Es gibt daher keine mechanische Regel, nach der Teilen immer gut oder Trennen immer sicher wäre. Diensteigentümer, Datenschutzverantwortliche und Plattformbetreiber müssen eine begründbare Grenze wählen. Die Funktionsfähigkeit des Schlüssels genehmigt diese Wahl nicht.

Auch der Nachweis darf die Privatsphäre nicht unterlaufen. Eine zentrale Prüfdatenbank mit sämtlichen geschützten Namen, Kunden und Servern würde eine empfindliche Karte schaffen. Im Beleg genügen Kennung und Version der Mengenrichtlinie, ein Größenband, Mitgliedsregeln, Isolationsklassen und verbotene Kombinationen. Berechtigte Prüfer gleichen bei Bedarf die Ursprungsdaten ab; gewöhnliche Verifizierer erkennen eine nicht genehmigte Ausweitung oder Verkleinerung, ohne die Namensliste zu erhalten.

Wiederholung ist ein eigener Richtlinienkanal

Ein Server kann bei ECH-Ablehnung retry_configs zurückgeben. RFC 9934 weist darauf hin, dass aus mehreren konfigurierten Dateien nur ein Teil dafür ausgewählt werden kann. Die im Normalbetrieb akzeptierte Menge und die zur Wiederholung beworbene Menge besitzen folglich unterschiedliche Rollen.

Ein neuer Schlüssel kann auf wenigen Knoten vorinstalliert sein, ohne bereits allen Clients empfohlen werden zu dürfen. Ein alter Schlüssel kann aus der DNS-Präferenz verschwunden sein und noch zwischengespeicherte Anfragen annehmen. Eine Notfalldatei kann nur in einer Region verfügbar sein. Automatisierung, die jede gültige Datei in die Wiederholungsantwort setzt, verwechselt Formatgültigkeit mit Publikationsfreigabe.

Eine falsche Wiederholungsantwort kann den Fehler ausweiten. Eine Abweichung, die zunächst nur Clients eines bestimmten RRSet traf, verteilt durch den Server eine andere Konfiguration an zusätzliche Verbindungen. Eine erneute Ablehnung nach dem Wiederholungsversuch ist deshalb ein starkes Signal für geteilte Zustände. Gezählt werden sollte nach Konfigurationsepoche und grober Serverkohorte, ohne Clientkennung oder inneren Namen.

Der Beleg unterscheidet normale Annahme, Wiederholungswerbung, reine Überschneidung, Rückfallbereitschaft und Ruhestand. Dass eine Datei noch auf einem Datenträger liegt, überträgt keine alte Berechtigung in eine neue Rolle.

Derselbe Wert kann zu einer anderen Zeit etwas anderes bedeuten

Eine Rotation durchläuft Erzeugung, Validierung, Vorverteilung, DNS-Veröffentlichung, vollständige Annahme, Überschneidung, Ende der Werbung, Cache-Nachlauf und Vernichtung. Derselbe ECHConfig-Wert und dieselbe gültige Datei können in mehreren Phasen vorkommen, aber der jeweils genehmigte Einsatz ändert sich.

Caches verteilen die Zeitgrenze über Organisationen und Netze. Eine Änderung im autoritativen DNS löscht alte Kopien nicht sofort. Ebenso rechtfertigt die fortbestehende Entschlüsselungsfähigkeit eines Servers keine unbegrenzte Werbung für die alte Liste. TTL, beobachtetes Cacheverhalten, Clientverträglichkeit und Reaktion auf einen Schlüsselvorfall gehören auf eine gemeinsame Zeitlinie.

Auch eine zu frühe Wiederverwendung von Kennungen verdient Aufmerksamkeit. Wiederhergestellte Sicherungen oder Kopien zwischen Umgebungen können eine früher korrekte Datei in der falschen Epoche zurückbringen. Der Änderungszeitpunkt des Dateisystems ist keine ausreichende Herkunft. Inhaltsdigest, Richtlinienversion, Ursprungsumgebung und genehmigtes Zeitfenster bestimmen die betriebliche Identität.

Außerbetriebnahme bedeutet mehr als das Löschen eines Pfades. Dass der private Schlüssel aus Geheimnisspeichern, Build-Caches, Ausweichstandorten und Wartungsgeräten verschwunden ist, ist ein Nachweis. Dass die öffentliche Liste aus DNS- und Aliaspfaden verschwunden ist, ist ein anderer. Private Vernichtung und öffentliche Rücknahme müssen getrennt bestätigt und im Lebenszyklus verbunden werden.

Portabilität verschiebt Verantwortung

RFC 7468 hat textuelle Kapseln für Sicherheitsobjekte verbreitet. Der Anschluss an diese Werkzeugwelt macht ECH in vorhandenen Schlüssel- und Bereitstellungssystemen praktikabler. Je leichter ein Objekt kopiert werden kann, desto weniger darf sein Besitz als Berechtigung gelten.

In einem kleinen Dienst liegen DNS, TLS und Produkteigentum vielleicht in einer Hand. Mit wachsender Größe erzeugt eine zentrale Plattform den Schlüssel, eine andere Gruppe verwaltet die Zone, ein externer Anbieter betreibt die Kante und ein Diensteigentümer legt die Mandantengrenze fest. Der Empfänger kann die interne Konsistenz prüfen, aber aus der Datei nicht lesen, was der Absender tatsächlich genehmigt hat.

Die Lösung ist nicht, das Protokoll mit sämtlichen Organisationsregeln zu belasten. Es braucht eine gesonderte, prüfbare Schicht für institutionelle Tatsachen. Heng Lus Bild eines „Policy Mirror“ lenkt den Blick darauf, ob eine sichtbare Zustandsanzeige die wirkliche Entscheidung spiegelt. Die Idee einer minimalen Anfangsspezifikation spricht dafür, zunächst nur die entscheidenden Verantwortungen zu verbinden, statt sofort eine allumfassende zentrale Instanz zu bauen.

Eine realitätsnahe Darstellung muss Ausnahmen zeigen. Teilbereitstellungen, Notfallrücknahmen und ungeklärte Evidenz dürfen nicht hinter einem grünen Symbol verschwinden. „Datei gültig, Grenze noch nicht nachgewiesen“ ist ein ehrlicher und handlungsfähiger Zustand.

Aufbau eines datensparsamen Belegs

Der erste Block identifiziert das kryptografische Objekt: kanonischer Digest der ECHConfigList, Ergebnis des Schlüsselabgleichs, Konfigurationskennungen und Kryptosuite. Der private Schlüssel wird in der geschützten Prüfumgebung benutzt, aber nicht in den Beleg aufgenommen.

Der zweite Block bezeichnet die Veröffentlichungsabsicht: RRSet-Digest, Zone oder Delegation, public_name, Prioritäten und Zeitfenster. Der dritte definiert die Endpunktkohorte anhand von Load Balancer, Regionen, Anbietern, Dienstidentität, Generation und synthetischer Prüfabdeckung, statt sich auf eine momentane Liste kurzlebiger Instanzen zu verlassen.

Der vierte Block trennt Annahme, Wiederholung, Überschneidung, Rückfall und Ruhestand. Der fünfte beschreibt die Datenschutzmenge mit Richtlinienversion, Größenband und Isolationsklasse, ohne geschützte Namen aufzuzählen. Der sechste nennt Verantwortung: Antragsteller, DNS-Genehmiger, Schlüsselverwahrer, Diensteigentümer, Signaturzeitpunkt, Widerrufsbedingungen und Evidenzverweise.

Der Beleg sollte signierbar, aus kanonischen Eingaben reproduzierbar und widerrufbar sein. Er kann auf eingeschränkt zugängliche Nachweise verweisen, darf aber weder Schlüssel noch vollständige Namensbestände, Clientadressen oder Handshake-Transkripte enthalten. HPKE aus RFC 9180, ECH selbst und die DNS-Ermittlung bleiben die technischen Grundlagen; der Beleg definiert sie nicht neu, sondern dokumentiert ihre konkrete Verwendung.

Automatisierung muss die Garantiegrenze sichtbar lassen

Eine Bereitstellungspipeline soll die RFC-9934-Prüfung weiterhin zuerst ausführen. Falsches Format, unpassender Schlüssel oder nicht dekodierbare Liste stoppen den Vorgang. Nach einem Erfolg fordert sie zusätzlich Richtlinienreferenz und Umgebungsnachweis an.

Ohne genehmigten RRSet-Digest lautet der Zustand „Datei gültig, Veröffentlichung nicht genehmigt“. Fehlen Teile der Kohorte, lautet er „Datei gültig, Abdeckung unvollständig“. Ist eine Mengenänderung noch ungeprüft, lautet er „kryptografische Übereinstimmung, Datenschutzgrenze offen“. Diese Zustände schwächen den Standard nicht; sie schützen seine präzise Aussage.

Nicht jede Rotation muss dadurch zur Sitzung werden. Der Diensteigentümer kann Mitgliedsregeln vorab genehmigen, das DNS-System signierte Änderungsnachweise liefern und die Plattform einen Kohortendigest erzeugen. Die Pipeline setzt den Beleg automatisch zusammen und eskaliert nur Grenzänderungen oder fehlende Evidenz.

Auch ein Rollback erzeugt einen neuen Beleg, statt einen alten Zustand stillschweigend wiederzubeleben. DNS-Caches, Routen und erreichbare Server können sich seit der früheren Freigabe verändert haben. Jede Zustandsänderung muss beantworten, wer auf welcher Grundlage welche Grenze bis wann genehmigte.

Audit darf nicht zum neuen Beobachtungspunkt werden

ECH soll die auf dem Netzpfad sichtbare Namensinformation reduzieren. Ein Audit, das innere Namen, Nutzeranfragen und detaillierte Serverprotokolle zentral sammelt, baut diese Beobachtungsfähigkeit unter anderem Vorzeichen wieder auf. Datensparsamkeit gehört daher in die Kontrolldefinition.

Öffentliche Digests und synthetische Prüfungen belegen Serverkonsistenz. Ein kanonischer RRSet-Digest belegt den DNS-Zustand. Größenbänder oder Bindungswerte beschreiben die Menge. Wiederholungsfehler lassen sich nach Zeit und Kohorte aggregieren. Erst bei einem konkreten Vorfall werden feinere Nachweise in einer beschränkten Umgebung und mit Aufbewahrungsfrist zusammengeführt.

Auch Zugriffsrechte lassen sich teilen. Sicherheit bestätigt die Schlüsselvernichtung, DNS die Veröffentlichung, Datenschutz die Mengenregeln; das normale Bereitstellungssystem sieht nur den Stand der Atteste. Verantwortlichkeit bleibt benannt, ohne sämtliche Geheimnisse einem einzigen Leser auszuhändigen.

Zwei Freigaben für zwei verschiedene Aussagen

RFC 9934 soll ein interoperables Dateiformat definieren, nicht die Mandantengrenze, Genehmigungskette oder Rotationsfrist jedes Betreibers. Das Problem ist nicht eine fehlende RFC-Seite, sondern die betriebliche Umdeutung eines Formatchecks zur umfassenden Freigabe.

Ein künftiges signiertes ECH-Bereitstellungsmanifest könnte Felder vereinheitlichen. Bis dahin reicht ein organisationsspezifischer Beleg, wenn er prüfbar ist, Protokollgarantie und institutionelle Entscheidung trennt und Unsicherheit ausdrücklich festhält.

Legitimität entsteht durch nachvollziehbare Rollen. Die IETF definiert das interoperable Objekt, der DNS-Inhaber die Veröffentlichung, die Plattform die Serverkohorte und der Diensteigentümer die Datenschutzmenge. Der Besitz der Datei überträgt keinem Beteiligten die übrigen Mandate.

Am Ende stehen zwei getrennte Prüfungen. Kryptografische Dateigültigkeit besagt, dass der private Schlüssel zu einer öffentlichen Konfiguration passt. Richtlinienbezogene Bereitstellungsgültigkeit besagt, dass die richtige Liste zur richtigen Zeit über das richtige DNS an die richtigen Server und die richtige Datenschutzmenge gelangt. Die Datei macht ECH portabel. Der Beleg macht die Grenze erklärbar, prüfbar und widerrufbar.

Eine gültige ECH-Schlüsseldatei beweist nicht die richtige Datenschutzgrenze

Warum es wichtig ist