Summary

  • Agent Discovery kann organisatorische Absichten schon vor der Auswahl offenlegen: Fähigkeitsfilter, Rechtsraum, Vertrauensanforderungen, Zeitpunkt und wiederholte Verfeinerungen beschreiben die geplante Aufgabe selbst bei verschlüsseltem Abfragetext.
  • draft-iannone-dawn-privacy-considerations-00 benennt Überwachung, gespeicherte Daten, Korrelation und Identifizierung, ist aber ein unvollständiger individueller Internet-Draft; DNS-Vergleich, Privatsphäre gegen Prüfbarkeit, RFC-6973-Fragebogen und mehrere Bedrohungen stehen noch auf TBD.
  • Daniel Kade schlägt ein Auswahl-Offenlegungsbudget für Attributgranularität, Mindestgröße der Kandidatenmenge, Verknüpfungsfenster, Rollentrennung, Bootstrap-Pfad, Ergebnisadressaten und Aufbewahrung vor. Das ist eine redaktionelle Empfehlung, keine DAWN- oder IETF-Vorgabe.

Die erste Preisgabe geschieht vor dem ersten Kontakt

Discovery erscheint oft als harmlose Verbindung zwischen Absicht und Ausführung. Ein Client kennt seinen Bedarf, fragt ein Verzeichnis nach passenden Anbietern, vergleicht Antworten und entscheidet sich. Vertrauen, Autorisierung und Auftragsausführung kommen später. Dadurch wirkt die Suche wie bloße technische Zuleitung.

Die vorgeschlagene DAWN-Terminologie macht deutlich, wie viel diese Zuleitung trägt. Entdeckbare Einheiten können Agenten, Workloads oder benannte Ressourcen sein. Ihre Eigenschaften können Funktion, Fähigkeiten, Protokolle, Eigentümer, Betreiber, Standort, Rechtsraum und Vertrauenssignale beschreiben. Der Nutzen interoperabler Discovery liegt darin, Tausende Möglichkeiten ohne vorherige Beziehung maschinell einzugrenzen. Genau diese Struktur verwandelt eine Anfrage in ein komprimiertes Dokument der Auswahlpolitik des Suchenden.

„Übersetzung“ ist unspezifisch. Kommen Sprachpaar, Schutzanforderung für medizinische Daten, ein seltenes Attestierungsverfahren, europäischer Rechtsraum, eine Latenzgrenze und sofortige Verfügbarkeit hinzu, kann die Anfrage einen bestimmten klinischen Ablauf erkennen lassen. Wird im zweiten Versuch die Latenz gelockert und im dritten der Rechtsraum geändert, zeigt die Reihenfolge, welche Bedingung verhandelbar ist. Niemand muss die endgültige Wahl sehen; der Suchpfad hat das Ziel bereits umrissen.

Der DAWN-Anforderungsentwurf nimmt Auswahlmechanismen und Auswahlrichtlinien aus seinem Gegenstandsbereich. Für ein Dokument, das noch kein Protokoll festlegt, ist das plausibel. Beobachtbar bleibt die Richtlinie dennoch. Wer die getesteten Attribute, ihre schrittweise Lockerung, die zurückgegebenen Kandidaten und die Zeitpunkte kennt, kann jene Auswahlregeln ableiten, die der Entwurf ausdrücklich nicht definiert.

Verschlüsselung verbirgt den Satz, nicht die Gestalt der Suche

Der auf den 22. Mai 2026 datierte draft-iannone-dawn-privacy-considerations-00 benennt das Problem offen. Eine Discovery-Infrastruktur kann erkennen, welche Organisation welche Fähigkeiten abfragt, und daraus Interessen, Auslastungsmuster oder Betriebsverhalten ableiten. Gespeicherte Abfragehistorien legen Arbeitsabläufe frei. Wiederholte Anfragen ermöglichen Korrelation. Organisationsnamen, Eigentums- und Betreiberangaben sowie Fähigkeitsmetadaten können identifizieren.

Der Text ist jedoch keine abgeschlossene IETF-Position. Er ist ein laufender individueller Entwurf ohne RFC-Stream, zuständigen Area Director oder IESG-Telechat. Intrusion, falsche Zuordnung, Sekundärnutzung, Offenlegung und Ausschluss sind noch nicht ausgearbeitet. Auch der DNS-Vergleich, „Privacy vs Auditability“, der Fragenkatalog aus RFC 6973, DAWN-spezifische Gegenmaßnahmen und die Security Considerations bleiben künftige Arbeit. Seine heutige Bedeutung liegt darin, offene Entscheidungen sichtbar zu machen, nicht darin, sie vorwegzunehmen.

Verschlüsselung kann bestimmten Beobachtern den Inhalt nehmen. Ziel, Größe, Zeitpunkt, Wiederholung, Fehlschlag und Umfang der Antwort verschwinden dadurch nicht. RFC 7258 erinnert daran, dass auch äußere Merkmale und ihre Korrelation Überwachung ermöglichen, unabhängig vom behaupteten Motiv. Die Frage „Wird TLS verwendet?“ ist deshalb zu klein. Governance muss fragen, welcher Beteiligte welche Fragmente wie lange zusammenführen kann.

RFC 9458 zu Oblivious HTTP liefert einen nützlichen Vergleich. Ein Relay kann den Client kennen, ohne den Klartext der Anfrage zu sehen; ein Gateway kann die Anfrage sehen, ohne den Client direkt zu kennen. Nachrichtengröße, Timing, Schlüsselkennungen, Wiederverwendung von Verbindungen und unterschiedliche Behandlung bleiben jedoch Korrelationsmerkmale. Kleine Anonymitätsmengen schwächen die Trennung, und die Konstruktion setzt Nicht-Kollusion voraus. Zwei Kästen in einem Architekturdiagramm beweisen keine operative Trennung, wenn Logsysteme, Cloud oder Analytik gemeinsam sind.

Die Kandidatenmenge kann mehr verraten als die Anfrage

Ein geschützter Suchtext hilft wenig, wenn die Antwort genau eine Einheit enthält. Der einzelne Kandidat erklärt dann die Bedeutung der Bedingungen. Eine hinreichend große, vielfältige Ergebnismenge ist daher eine Privatsphäre-Eigenschaft und nicht nur eine Frage der Verfügbarkeit. Umgekehrt kann ein Dienst, der extrem seltene Attributkombinationen akzeptiert und sofort die Trefferzahl liefert, als Existenzorakel für seinen Eigenschaftsbestand missbraucht werden.

Oblivious DoH nach RFC 9230 trennt unter bestimmten Voraussetzungen die Kenntnis über den Client von der Kenntnis über die Klartext-DNS-Anfrage. RFC 9156 schärft den Blick für Minimierung und Granularität. Agent Discovery ist anspruchsvoller, weil gerade die Kombination vieler Eigenschaften nützlich ist. Eine stufenweise Suche von groben Klassen zu wirklich nötigen Details kann verhindern, dass der gesamte Plan in einer Anfrage steckt. Werden die Stufen aber durch Kennung, Verbindung oder präzises Timing verbunden, entsteht der Plan wieder. Granularität und Verknüpfbarkeit lassen sich nicht getrennt regeln.

RFC 9540 zeigt zudem, dass bereits der Bootstrap vor der geschützten Anfrage lecken kann. Schlüsselabruf, Konfigurationsadresse, Weiterleitung oder ein einzigartiger Netzpfad können erkennen lassen, welcher Discovery-Dienst benutzt werden soll. Wer nur das Innere des Tunnels prüft, übersieht die Spur bis zu dessen Eingang.

Auch die Ergebnissicht hat nicht nur ein Publikum. Öffentliche, nur autorisierten Suchenden zugängliche und auf einen Suchenden zugeschnittene Antworten erzeugen unterschiedliche Flächen. Beschränkung kann sensible Anbieterdaten schützen, bindet aber die authentisierte Identität enger an die Filter. Personalisierung steigert Nützlichkeit, doch Antwortunterschiede können Clientklassen oder interne Regeln offenbaren. Ein Wechsel des Schutzsubjekts verschiebt das Leck, ohne es zwingend zu schließen.

Privatsphäre und Prüfbarkeit sind keine notwendige Entweder-oder-Wahl

Die noch offene Überschrift „Privacy vs Auditability“ des Entwurfs markiert eine zentrale institutionelle Entscheidung. Betreiber wollen Missbrauch, Scraping, ungerechtfertigten Ausschluss und Qualitätsabfall untersuchen. Verträge oder Aufsicht können Erklärungen verlangen. Werden dafür jede Anfrage, jede Kandidatenliste und eine dauerhafte Kennung zentral gespeichert, wird die Prüfinfrastruktur zu einem Archiv der Nutzerabsichten.

Alle Aufzeichnungen abzuschaffen, wäre ebenfalls unzureichend. Ohne Belege lassen sich unterschiedliche Behandlung, systematische Fehler oder Ausnahmegebrauch schwer nachweisen. Nötig ist zweckgebundene Evidenz: Wer darf sie in welcher Auflösung bis wann sehen? Kurzlebige lokale Zähler können Größenklassen der Kandidatenmenge, Fehlerquote, Latenzverteilung, Häufigkeit seltener Filter, Richtlinienversion und Ablaufdatum einer Ausnahme erfassen, ohne Suchtext oder Identität sämtlicher Kandidaten zu bewahren.

Die Privacy-Pass-Architektur in RFC 9576 trennt Ausgabe-, Attestierungs- und Einlösungskontexte, um unnötige Verknüpfung zu vermeiden. RFC 9614 verteilt das Wissen darüber, wer sich verbunden hat und wohin die Verbindung ging. Beides ist kein Allheilmittel. Kollusion, kleine Mengen, übereinstimmende Zeitpunkte und persistente Kennungen setzen die Teile erneut zusammen. Auch bei Audit-Strukturen muss geprüft werden, wann Rekombination möglich ist; eine erklärte Rollentrennung reicht nicht.

Ein Budget für die Offenlegung der Auswahl

Daniel Kade schlägt ein Auswahl-Offenlegungsbudget vor, kein zentrales Register aller Suchen. Es legt vorab fest, wie viel Auswahlpolitik eine einzelne Abfrage oder Folge sichtbar machen darf, misst die betriebliche Wirkung und bindet Ausnahmen an Frist und Überprüfung.

Erstens braucht es eine maximale Attributgranularität. Eine seltene Kombination kann als Kennung wirken, obwohl jedes Feld für sich harmlos aussieht. Der Einstieg kann breite Fähigkeitsklassen oder Rechtsraumgruppen verwenden und Details erst später zulassen. Zweitens braucht es eine Mindestgröße der Kandidatenmenge und definiertes Verhalten darunter. Statt eine einzige Einheit zu nennen, kann das System die Bedingung vergröbern, die Antwort zeitlich bündeln oder nur mitteilen, dass keine ausreichend große Menge existiert.

Drittens ist ein Verknüpfungsfenster festzulegen: Wie viele Minuten, Stunden oder Tage dürfen aufeinanderfolgende Anfragen demselben Suchenden zugeordnet werden? Batching, Zeitrundung, Kennungsrotation und gegebenenfalls Padding wirken nur zusammen mit einer institutionellen Obergrenze. Viertens braucht es eine Sichtbarkeitsmatrix. Für Client, Relay, Index, Anbieter, Schlüsselverteiler und Auditor hält sie fest, wer Identität, Attribute, Kandidaten, Zeit und Resultat sieht.

Fünftens gehören Nicht-Kollusionsannahmen und Bootstrap-Pfad in die Dokumentation. Rechtlich getrennte Unternehmen können dasselbe Cloud-Konto, denselben Logsammler oder denselben Analytikdienst nutzen; dann ist die nominelle Trennung schwach. Sechstens sind öffentliche, beschränkte und anfragerspezifische Ergebnisse, Aufbewahrung, Löschung, Korrektur, Ausnahmebefugnis, Ablauf und erneute Prüfung zu regeln.

Dieses Budget soll keine Rohabfragen, Berechtigungsnachweise, Aufgabeninhalte, personenbezogenen Daten, proprietären Gewichte oder vollständigen Kandidatenidentitäten sammeln. Grobe Aggregate, kurzlebige lokale Zähler, synthetische Tests und unabhängige Konfigurationsprüfungen decken einen großen Teil des Kontrollbedarfs. Nicht vorhandene unnötige Daten sind verlässlicher geschützt als Daten, deren Nutzung nur versprochen wird.

Was sich noch nicht behaupten lässt

Die untersuchten Quellen belegen keine produktive DAWN-Implementierung, Verbreitung, Leistungswerte, tatsächlichen Datenschutzvorfall oder rechtliche Bewertung. PIR wird als möglicher Baustein erwähnt, nicht als beschlossene Technik oder in diesem Maßstab nachgewiesene Lösung. Auch die Einhaltung eines bestimmten Gesetzes lässt sich aus den technischen Texten nicht ableiten.

Das hier vorgeschlagene Budget ist weder IETF-Konsens noch Implementierungspflicht oder Rechtsnorm. Es übersetzt eine erkennbare Lücke in überprüfbare Betriebsfragen. Belastbar ist zunächst nur dies: Der Nutzen von Discovery entsteht aus maschinell vergleichbaren Eigenschaften; dieselben Eigenschaften und die Reihenfolge ihres Vergleichs drücken Absicht aus.

Solange das Design offen ist, können Ergebnismenge, Zeit, Rollentrennung, Bootstrap, Aufbewahrung und Ausnahmen als Bestandteile der Privatsphäre gestaltet werden, statt alles einer späteren Verschlüsselungsschicht zu überlassen. „Noch nicht gewählt“ bedeutet nicht „noch nichts verraten“. Die Suche ist bereits der erste sichtbare Teil der Wahl.

Sources

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://datatracker.ietf.org/doc/html/draft-iannone-dawn-privacy-considerations-00
  5. https://datatracker.ietf.org/doc/draft-iannone-dawn-privacy-considerations/
  6. https://datatracker.ietf.org/doc/draft-iannone-dawn-privacy-considerations/history/
  7. https://datatracker.ietf.org/doc/html/draft-akhavain-moussa-dawn-problem-statement-02
  8. https://datatracker.ietf.org/doc/html/draft-king-dawn-requirements-01
  9. https://datatracker.ietf.org/doc/html/draft-farrel-dawn-terminology-01
  10. https://www.rfc-editor.org/rfc/rfc6973.html
  11. https://www.rfc-editor.org/rfc/rfc7258.html
  12. https://www.rfc-editor.org/rfc/rfc9156.html
  13. https://www.rfc-editor.org/rfc/rfc9230.html
  14. https://www.rfc-editor.org/rfc/rfc9458.html
  15. https://www.rfc-editor.org/rfc/rfc9540.html
  16. https://www.rfc-editor.org/rfc/rfc9576.html
  17. https://www.rfc-editor.org/rfc/rfc9614.html