Zusammenfassung

  • RFC 9540 führt den leeren Parameter ohttp in SVCB- und HTTPS-Einträgen ein, verweist auf /.well-known/ohttp-gateway auf demselben Host und beschreibt den Abruf der Gateway-Schlüsselkonfiguration.
  • Das Verfahren findet und beglaubigt kein Relay. DNS-Ankündigung, Endpunktprüfung, verwertbarer Schlüssel und erfolgreiche Antwort sind getrennte Belege.
  • Eine nur einem Client zugewiesene Schlüsselkonfiguration, Weiterleitung oder ein eigener dohpath kann Verknüpfbarkeit herstellen; Konsistenz braucht deshalb eine unabhängige Prüfung.

Die Abweichung stand in keinem Fehlerprotokoll. Zwei Clients entdeckten denselben Resolver, akzeptierten das Zertifikat, riefen einen Schlüssel ab und erhielten eine Antwort über ein Relay. Erst der Vergleich mehrerer Beobachtungspunkte zeigte: Einer der beiden hatte eine Schlüsselkonfiguration bekommen, die sonst nirgends vorkam.

Die Verschlüsselung war intakt. Ihre Konfiguration hatte dennoch eine Person aus der Menge herausgelöst.

Die im Februar 2024 veröffentlichte RFC 9540 standardisiert die Erkennung von Oblivious-HTTP-Diensten über Service-Binding-Einträge. Sie bietet damit eine Alternative zu proprietärer Abstimmung zwischen Clients und Gateways. Bemerkenswert ist, dass sie die neue Entdeckungsoberfläche nicht mit dem Datenschutzergebnis verwechselt. Ihre Sicherheitsbetrachtung beschreibt vielmehr, wie genau diese Oberfläche für gezielte Schlüssel und Pfade missbraucht werden kann.

Ein leerer Parameter trifft eine wirksame Auswahl

Der SvcParamKey ohttp muss in Darstellung und Drahtformat leer sein. Seine Anwesenheit bedeutet, dass der beschriebene Dienst über ein zugeordnetes Gateway als OHTTP-Ziel erreichbar ist.

Das leere Feld beeinflusst dennoch die Dienstwahl. Steht es in mandatory, müssen Clients ohne Verständnis des Parameters den Eintrag ignorieren. Fehlt es dort, ist OHTTP eine optionale Zugriffsmöglichkeit. Mehrere Einträge können unterschiedliche Konfigurationen anbieten.

Der daraus entstehende Beleg lautet nur: Diese DNS-Quelle hat zu diesem Zeitpunkt, mit dieser TTL und diesen Auswahlregeln OHTTP angekündigt. Er sagt nicht, dass der Client OHTTP nutzte, das Gateway erreichbar war oder andere Clients dieselbe Konfiguration erhielten. Bei ungeschütztem Klartext-DNS kann ein Angreifer SVCB-Informationen entfernen und einen Downgrade auslösen. Das Prüfen des Well-known-Pfads oder verschlüsseltes DNS zusammen mit DNSSEC mindern dies, bezeugen aber kein späteres Gateway-Verhalten.

Eine belastbare Aufzeichnung enthält daher die rohe Antwort, Resolver und Beobachtungsnetz, TTL und Cache-Alter, DNSSEC-Status, Transport, mandatory, Kandidaten und Auswahlgrund. Ein einzelnes Feld ohttp=true vernichtet Herkunft und Wirkung der Aussage.

Das Relay bleibt außerhalb des Fundstücks

OHTTP teilt Sichtbarkeit auf. Das Relay kennt die Netzidentität des Clients und das Gateway-Ziel, kann aber die gekapselte Nachricht nicht lesen. Das Gateway öffnet die Nachricht, soll jedoch aus einer einzelnen Transaktion nicht die Client-Identität erfahren. Das Ziel verarbeitet die Anwendung.

RFC 9540 entdeckt Ziel und Gateway. Die Relay-Erkennung ist ausdrücklich nicht Gegenstand des Dokuments. Der Client soll bereits ein vertrauenswürdiges Relay besitzen, das Gateways allgemein erreichen oder deren Erreichbarkeit prüfen kann.

Diese Annahme ist eine eigenständige Governance-Entscheidung. Wer wählte das Relay? Welche Protokolle bewahrt es auf? Unter welcher Rechtsordnung arbeitet es? Teilt es Betreiber, Cloud oder wirtschaftliche Interessen mit dem Gateway? Wie verändern Missbrauchsabwehr und Auskunftspflichten die Trennung? Auch eine vollständig konforme Implementierung beantwortet diese Fragen nicht.

Derselbe bekannte Einstieg verlangt zwei unabhängige Wege

Nach der Erkennung verwendet der Client /.well-known/ohttp-gateway auf demselben Host wie das Ziel. Der Server darf von dort weiterleiten. Eine vom Client beim Schlüsselabruf empfangene Redirect-URI darf dieser aber nicht an das Relay weiterreichen.

Sonst könnte das Gateway einen individuellen Wert in die URI schreiben und ihn wiedererkennen, wenn das Relay später mit genau diesem Wert anfragt. Das Relay muss selbst am Well-known-Pfad beginnen und Weiterleitungen unabhängig verfolgen. Einen für alle gemeinsamen Zielort darf es zwischenspeichern; eine persönliche Spur darf es nicht erben.

Auch die Evidenz benötigt deshalb zwei Pfade: die Beobachtungen des Clients beim Konfigurationsabruf und die Beobachtungen des Relays bei der gekapselten Anfrage. Wer nur eine „endgültige Gateway-URL“ speichert, entfernt den Vergleich, der personalisierte Weiterleitungen sichtbar machen könnte.

Der Schlüsselabruf findet vor dem geschützten Austausch statt

Bevor der Client kapseln kann, sendet er einen GET mit Accept: application/ohttp-keys an das Gateway. Ein direkter Abruf legt dem Gateway die IP-Adresse offen. Das kann genügen, wenn lediglich einzelne Abfragen von einer ohnehin bekannten Anschlussadresse getrennt werden sollen. Es widerspricht einem Versprechen, Standort oder Nutzungsvorbereitung zu verbergen, und ermöglicht die Auswahl clientbezogener Schlüssel.

Ein Proxy kann die Adresse verdecken, wird aber selbst zum Beobachter. Vor allem muss der Inhalt der Antwort geprüft werden. Eine syntaktisch und kryptografisch gültige Konfiguration kann einzigartig sein. Da OHTTP-Nachrichten über ihre Schlüsselkonfiguration verknüpft werden können, erzeugt Schlüssel A für einen Client und Schlüssel B für alle anderen eine Ein-Personen-Gruppe, ohne den Algorithmus zu brechen.

RFC 9540 empfiehlt deshalb eine Konsistenztechnik, etwa die Bestätigung über einen gemeinsamen Proxy. Erkennt ein Client gezielte Konfiguration, kann er das Gateway verlassen und melden. Betreiber müssen Vergleichsmenge, Zeitfenster, unabhängige Standorte, reguläre Rotation und Reaktion auf Abweichungen festlegen. „Schlüssel gültig“ beantwortet die Frage nach Verwendbarkeit. „Schlüssel konsistent“ beantwortet die Frage nach Sonderbehandlung.

Ein DoH-Pfad kann als Name dienen

Bei oblivious DoH bietet dohpath eine zweite Zieloberfläche. Ein individueller Pfad identifiziert einen Client auch dann, wenn alle denselben Schlüssel verwenden. Der Client kann nur einen bekannten Wert wie /dns-query{?dns} akzeptieren oder beliebige Werte über eine andere Quelle vergleichen. Stichproben sind je nach Kapazität und Bedrohungsmodell möglich, tragen jedoch nur eine Aussage über den geprüften Anteil.

Auch DDR und DNR dürfen nicht zusammengezogen werden. Bei DDR bleiben die vorgesehenen Zertifikatsprüfungen für den entdeckten Resolver nötig. Bei DNR können DHCP oder Router Advertisements die Parameter liefern; die Autorität stammt aus einem anderen Benennungsmodell. Beide müssen weiterhin individuelle Pfade erkennen. Ein Zertifikat belegt die Kontrolle über eine Endpunktidentität, nicht die Gleichbehandlung aller Clients.

Das Ergebnis braucht eine Belegleiter

Ein steuerbarer Dienst trennt mindestens neun Tatsachen: die Veröffentlichung von ohttp; die Auslegung von mandatory; die akzeptierte DDR- oder DNR-Benennung; die Endpunktidentität; eine parsebare Schlüsselkonfiguration; Konsistenz von Schlüssel, Pfad und Redirect; Zulässigkeit und Erreichbarkeit des Relays; Abschluss der Transaktion; und die tatsächlich belegte Datenschutzeigenschaft.

Ein späterer Erfolg heilt keinen früheren Mangel. Eine Antwort legitimiert keine falsche Benennung. Ein Zertifikat beweist keine gemeinsame Konfiguration. Eine gemeinsame Konfiguration beweist keine Unabhängigkeit von Relay und Gateway. Datenschutz ist eine begrenzte Schlussfolgerung aus mehreren Beobachtungen, kein Statusbit des Protokolls.

Diese Trennung macht OHTTP nicht schwächer, sondern verantwortbar. Sie erlaubt eine genaue Aussage darüber, ob Verfügbarkeit, Anfrageentkopplung oder weitergehender Identitätsschutz erreicht wurde. Die Ankündigung eröffnet den kontrollierten Weg; sie ist nicht dessen Urteil.

Quellen