Zusammenfassung

  • Die Annahme von QUIC 0-RTT ist eine TLS- und Transportentscheidung, kein Beleg für eine einmalige Anwendungsausführung.
  • Ein Paket-ACK belegt Transportverarbeitung, nicht Replay-Sicherheit, dauerhaften Commit, Client-Identität oder Geschäftserfolg.
  • Die Anwendung legt die zulässige Nutzung früher Daten fest und führt getrennte Nachweise für Ausführung, Idempotenz, Effekte und Ergebnis.

QUIC 0-RTT erlaubt dem Client, Konfiguration aus einer früheren Verbindung, darunter ein TLS-Sitzungsticket, wiederzuverwenden und Anwendungsdaten vor Abschluss des neuen Handshakes zu senden. Der Server akzeptiert dies, indem er die TLS-Erweiterung early_data in EncryptedExtensions sendet. Danach verarbeitet und bestätigt er empfangene 0-RTT-Pakete. Fehlt die Erweiterung, ist 0-RTT abgelehnt; die betreffenden Pakete dürfen nicht als akzeptierte frühe Daten verarbeitet werden.

Damit ist eine eng begrenzte kryptografische und transportbezogene Tatsache bewiesen. Nicht bewiesen ist, dass ein Anwendungs-Handler genau einmal lief, dass eine Anfrage einen nachgelagerten Dienst erreichte oder dass sie einen dauerhaften Commit überschritt. Vor Abschluss des Handshakes beweist die Annahme außerdem weder Client-Lebendigkeit noch eine authentifizierte Identität. Adressvalidierung kann zusätzliche Hinweise liefern, beseitigt aber die Möglichkeit eines Replay nicht.

QUIC 0-RTT übernimmt die Replay-Exposition von TLS Early Data. TLS-Gegenmaßnahmen sind erforderlich, aber keine allgemeine Anwendungsgarantie. Die Verarbeitung von QUIC-Transportframes ist idempotent; ein Replay erzeugt für sich genommen keinen ungültigen Verbindungszustand. Dauerhafte Folgen entstehen durch die Anwendungssyntax und -bedeutung, die über QUIC übertragen wird. STREAM, RESET_STREAM, STOP_SENDING und CONNECTION_CLOSE können Anwendungsbedeutung tragen und in 0-RTT unsicher sein. Ein QUIC verwendendes Anwendungsprotokoll muss daher ein zulässiges Nutzungsprofil definieren.

HTTP macht die Grenze sichtbar. Ohne bessere Informationen können Clients sichere Methoden in frühen Daten verwenden; unsichere oder in ihrer Sicherheit unbekannte Methoden dürfen sie dort nicht verwenden. Early-Data signalisiert, dass ein Vermittler eine Anfrage unter diesen Bedingungen weitergeleitet hat. 425 Too Early bedeutet, dass der Server das Risiko einer möglicherweise wiederholten Verarbeitung nicht eingehen will. Der Retry darf selbst kein Early Data verwenden. Ein späteres Warten auf den Handshake macht eine bereits mit Early-Data markierte Anfrage nicht rückwirkend sicher. Verteilte Instanzen müssen sie einheitlich behandeln.

Das Beweisprotokoll sollte Sitzungsticket und gemerkte Konfiguration getrennt führen; 0-RTT versucht, akzeptiert oder abgelehnt; Paketbestätigung; Weitergabe von Early-Data und Behandlung von 425; Anforderungsidentität und Idempotenzschlüssel; Ausführungsversuche; Seiteneffekte; dauerhafte Commit-Bestätigung; Replay- oder Retry-Beobachtungen; sowie Kunden- oder Finanzergebnis. Idempotenzschlüssel, Transaktionsjournale und verteilte Replay-Register sind Betriebsempfehlungen, keine QUIC-Anforderungen, sofern das Anwendungsprotokoll sie nicht selbst vorgibt.

Die praktische Konsequenz lautet nicht pauschale Abschaltung, sondern Beschränkung auf Vorgänge mit ausdrücklich begrenzten Replay-Folgen. Abschalten ist die wirksamste Replay-Abwehr. Akzeptierte frühe Daten bleiben jedoch der Nachweis einer Transportentscheidung und werden nicht zum Transaktions-Commit.