Zusammenfassung

  • RFC 9934 definiert eine PEM-Datei mit keinem oder einem privaten PKCS-#8-Schlüssel und genau einer ECHConfigList; ist das Geheimnis enthalten, muss mindestens eine öffentliche Konfiguration dazu passen.
  • Diese Übereinstimmung gilt innerhalb der Datei. Sie belegt weder das geladene Schlüsselpaar im Server noch den veröffentlichten DNS-Wert, den Client-Cache, die ECH-Annahme oder die erreichte Privatsphäre.

Bei einem Schlüsselwechsel können sechs Teams dasselbe Wort benutzen und sechs verschiedene Zustände meinen. Für das Schlüsselmanagement ist „neu“ das erzeugte Paar. Für die Plattform ist es die verteilte Datei. Für den TLS-Prozess ist es der geladene Satz. Für DNS ist es das autoritative RRSet. Für einen Resolver ist es die noch gültige Cachekopie. Für den Client ist es die Konfiguration, mit der er gerade einen Versuch startet. Ein grüner Status ohne diesen Bezug sagt wenig über Kohärenz.

RFC 9934 beseitigt zunächst eine konkrete Reibung: ECH-Material soll zwischen Schlüsselverwaltung und Servern mit unterschiedlichen TLS-Bibliotheken in einem gemeinsamen Format übergeben werden können. Die Datei enthält keinen oder einen privaten Schlüssel und danach genau eine ECHConfigList. Der private Schlüssel steht, falls vorhanden, zuerst als PKCS-#8-PrivateKey unter dem Label PRIVATE KEY. Der öffentliche Block folgt unter ECHCONFIG und trägt die base64-Darstellung desselben binären Listenwerts, der in einem HTTPS Resource Record veröffentlicht werden kann.

Die eingebaute Beziehung ist streng, aber klein. Enthält die Datei ein Geheimnis, muss der öffentliche Schlüssel mindestens einer ECHConfig aus der Liste dazu passen. Nachfolgender Inhalt soll ignoriert werden. Ein Parser kann damit Blockzahl, Reihenfolge, Dekodierung und diese Übereinstimmung prüfen. Er kann nicht feststellen, ob ein bestimmter Prozess die Datei gelesen hat, ob ein Reload wirksam wurde oder welche Konfigurationen der Server für retry_configs gewählt hat.

Die zulässige Datei ohne privaten Schlüssel verdeutlicht die Veröffentlichungsgrenze. Die ECHConfigList darf nach DNS projiziert werden; der private Schlüssel aus einer geheimnistragenden Datei darf dort niemals erscheinen. Ein tragfähiger Ablauf erzeugt deshalb zwei Artefakte derselben Generation mit unterschiedlichen Berechtigungen: eine geschützte Serverlieferung und eine öffentliche Service-Binding-Projektion. Wer beides als ein einziges publizierbares Paket behandelt, schafft ein Leckrisiko. Wer es ohne gemeinsame, nicht geheime Identität trennt, kann die Übereinstimmung später nicht beweisen.

Auch „die Liste“ ist nicht zwingend ein einzelner Kandidat. Sie kann mehrere ECHConfig-Werte mit verschiedenen Erweiterungen oder public_name-Werten in absteigender Präferenz enthalten. Ein Server kann mehrere Dateinamen verwenden und nur Teilmengen der jeweiligen Listen für Wiederholungsversuche anbieten. Dass ein vorhandener privater Schlüssel zu einem Listenelement passt, besagt nicht, dass jedes veröffentlichte Element im aktiven Prozess entschlüsselbar ist.

Die Textkonventionen aus RFC 7468 und die base64-Regeln aus RFC 4648 reduzieren Unterschiede zwischen Implementierungen. Erfolgreiches Dekodieren ist jedoch kein Nachweis enger Verwahrung. Neben dem nominellen Dateieigentümer können Backup-Dienste, Snapshots, Deployment-Agenten und Supportzugänge praktisch über das Geheimnis verfügen. Die Zugriffsfläche muss anhand realer Lesefähigkeit beschrieben werden, nicht anhand eines Organigramms.

Der schwierigere Teil ist die Zeit. RFC 9849 empfiehlt clientnahen Servern, aktuell veröffentlichte Konfigurationen und frühere Werte zu behalten, die Clients noch über eine DNS-TTL oder länger besitzen können. Kann der Server den inneren ClientHello entschlüsseln, kann ECH angenommen und der innere Handshake fortgesetzt werden. Andernfalls verarbeitet er den äußeren ClientHello, lehnt ECH ab und kann aktuelle Wiederholungskonfigurationen senden. Die Annahme wird vom Client bestätigt; eine abgelehnte Verbindung ist nicht einfach eine fertige Anwendungsverbindung.

Eine Rotation ist daher eine Überlappung, keine atomare Ersetzung. Erzeugung, geheime Verteilung, Serveraktivierung, autoritative DNS-Veröffentlichung, rekursive Cachealterung und der Wiederholungszustand von Clients haben eigene Uhren. Wird der alte Schlüssel beim DNS-Update sofort entfernt, können korrekt cacheende Clients ausfallen. Bleibt er unbegrenzt, wachsen Verwahrungsfläche und Entschlüsselungsaufwand. Die sichere Spanne muss als Annahme benannt und durch Beobachtung bestätigt werden.

Ein belastbarer Datensatz hält die Verknüpfungen fest, ohne den Schlüssel zu kopieren: nicht geheime Generationskennung, Dateihash, Parser-, Kardinalitäts- und Match-Ergebnis, tatsächliche Leser, Verteilungs- und Reload-Quittung, Hashes des aktiven Serversatzes, autoritatives HTTPS/SVCB-RRSet, ausgewählte rekursive Beobachtungen samt Alter, clientseitige Liste und config_id, ECH-Angebot und Annahme oder Ablehnung, Hash der Retry-Liste, Zertifikatsprüfung, Finished und eine harmlose Anwendungsbeobachtung.

Dieser Nachweis darf trotzdem nicht zu einem pauschalen Datenschutzsiegel werden. RFC 9848 beschreibt, wie gemischte RRSets aus ECH-fähigen und nicht ECH-fähigen Endpunkten durch selektives Blockieren herabgestuft werden können. Klartext-DNS, eine unterscheidbare IP-Adresse, Verkehrsanalyse oder eine kleine Anonymitätsmenge können weiterhin das Ziel einengen. RFC 9460 standardisiert die öffentliche Service-Binding-Fläche, beobachtet aber weder das Servergeheimnis noch die Entscheidung des Clients.

Heng Lus Running-Code Primacy gibt jedem Beobachter eine begrenzte, dafür belastbare Aussage. Der Dateiprüfer spricht über Bytes und interne Bindung. Der Server spricht über seinen geladenen Satz. Autorität und Resolver sprechen über ihre jeweilige DNS-Sicht. Der Client spricht über Angebot und Annahme. Eine Anwendungsprobe spricht über den späteren Effekt. Keine dieser Aussagen muss abgewertet werden; sie darf nur nicht für die anderen stehen.

Auch die Minimum Initial Specification passt hier. Das gemeinsame Format sollte klein bleiben, damit unabhängige Implementierungen interoperieren können. Es muss keinen universellen Key Manager, keine feste TTL, keinen Reloadmechanismus und keine weltweite Datenschutzpolitik bestimmen. Die Betreiber behalten diese Entscheidungen, weil sie deren lokale Folgen sehen und umkehren können. Damit übernehmen sie zugleich die Pflicht, ihre Übergänge nachweisbar zu machen.

Für die Freigabe zählt deshalb nicht die Frage „Ist die Datei gültig?“, sondern: Welche öffentliche Konfiguration erreichte welche Clientpopulation, welcher geschützte Schlüssel war zu diesem Zeitpunkt aktiv, wie entschied der Handshake und welcher Beobachter kann die abschließende Datenschutzaussage tragen?

Quellen