Zusammenfassung

  • NEW_TOKEN ist ein vom Server ausgestellter Nachweis für die Adressprüfung einer späteren QUIC-Verbindung; Retry gilt für den unmittelbaren Versuch.
  • Eine erfolgreiche Prüfung liefert begrenzte Evidenz zur Quelladresse nach Serverrichtlinie, nicht zur Identität eines zurückkehrenden Clients.
  • Tokenprüfung, Handshake-Authentisierung, Anwendungsidentität, Autorisierung und Ergebnis gehören in getrennte Felder.

Das Betriebsdashboard sieht ein Initial mit Token und schreibt „wiederkehrender Client“. Das wirkt plausibel, weil NEW_TOKEN eine zusätzliche Runde der Adressprüfung vermeiden kann. Die Bezeichnung ist dennoch zu weit. Die eigentliche Frage lautet: Darf der Server dieses Token als begrenzten Hinweis akzeptieren, dass die Quelladresse mit der Verbindung zusammenhängt, in der das Token ausgegeben wurde?

Der Server kann während einer Verbindung opake Bytes in einem NEW_TOKEN-Frame senden. Der Client setzt sie bei einer späteren Verbindung in Initial-Pakete ein. Das ist ein Nachweis für eine künftige Verbindung. Retry hat eine andere Rolle: Es wird sofort für den aktuellen Verbindungsversuch verwendet und darf nicht in spätere Verbindungen übernommen werden. NEW_TOKEN kann nach einer gewissen Zeit noch verwendbar sein, bleibt aber an Ablauf und Anwendbarkeit gebunden.

Der Server bestimmt Format und Prüfregeln. Er muss Integrität, Zuständigkeit des ausstellenden Servers, QUIC-Version, Ablauf und eine mögliche Änderung der Quell-IP prüfen können. RFC 9000 schreibt weder eine einheitliche Lebensdauer noch eine Wiederverwendungsrate oder einen Vertrauenswert vor. Ein Ausstellungszeitpunkt kann ausdrücklich enthalten sein oder die Ableitung eines Ablaufs ermöglichen. Der Client sollte normalerweise ein anwendbares, unbenutztes Token auswählen und es nicht über verschiedene Versuche hinweg wiederverwenden.

Die Aussage bleibt eng. Hinter NAT können mehrere Geräte dieselbe Adresse nutzen; Adressen werden neu zugewiesen; Geräte wechseln Netze. Das Token erlaubt dem Server eine Korrelation zwischen Ausstellung und späterer Nutzung. Wiederverwendung kann auch für Beobachter auf dem Übertragungsweg die Verknüpfbarkeit erhöhen. Ein Client, der diese Kontinuität vermeiden will, kann NEW_TOKEN verwerfen. Die Tokens sind nicht in den kryptografischen Handshake integriert. Ihre Prüfung authentisiert daher nicht den Kommunikationspartner und beweist weder Kontinuität eines Kontos noch Geräteidentität, Autorisierung oder erfolgreichen Geschäftsvorgang.

Wenn sich die Adresse ändert, gilt die Anti-Amplification-Grenze weiter, auch wenn das Token die Entscheidung beeinflusst, kein Retry zu senden. Ein gültiges Token hebt keine Transportschutzregel auf. Bei einem ungültigen Token sollte der Server den Client grundsätzlich als nicht validiert behandeln und gegebenenfalls Retry senden, statt die Ungültigkeit als Identitätsfehler zu deuten oder die Verbindung automatisch zu verwerfen. Tokenintegrität muss Raten, Veränderung und Fälschung verhindern; Replay muss verhindert oder begrenzt werden.

NEW_TOKEN braucht eine längere Gültigkeit als Retry, sollte aber nicht mehrfach akzeptiert werden; einmalige Nutzung wird empfohlen, soweit möglich.

DNS über QUIC zeigt die Datenschutzgrenze anschaulich. Ein an eine IP gebundenes Token kann eine zusätzliche Runde vermeiden, während ein unbemerkter Adresswechsel Verknüpfbarkeit erzeugt. Sitzungsfortsetzung kann dies abmildern, beseitigt es aber nicht. Der Betriebszweck ist daher ein kleiner: Transportaufwand senken, ohne daraus eine dauerhafte Kundenkennung zu machen.

Das Evidenzregister sollte Aussteller und Serverzuständigkeit, Tokentyp, Ausstellungs- und Ablaufzeit, QUIC-Version, Tokenkennung oder datenschutzschonenden Digest, Quell-IP-Abgleich, Entscheidung zu Erstnutzung oder Wiederverwendung, Validierungsergebnis, Anti-Amplification-Zustand, Retry-Entscheidung, Handshake-Authentisierung, Konto- oder Geräteidentität, Autorisierung, Anfrage- oder Transaktionsergebnis und Aufbewahrungsregel getrennt führen. Digests und Aufbewahrungsgrenzen sind betriebliche Empfehlungen, keine QUIC-Vorgaben.

Auch die benachbarten Dimensionen müssen getrennt bleiben: Retry-Integrität betrifft ein sofort verwendetes Paket; die Dreifachregel das Sende-Limit vor Validierung; Connection ID einen Routinggriff; 0-RTT wiederholbare Anwendungsdaten und Bindungsentscheidungen; DNS Cookie den Rückweg eines anderen Protokolls. Keine dieser Aussagen erweitert NEW_TOKEN.