Zusammenfassung

  • Der Abschluss des QUIC-Handshakes ist lokal und hängt von der Perspektive des jeweiligen Endpunkts ab.
  • HANDSHAKE_DONE oder ein qualifizierendes 1-RTT-ACK beim Client bestätigt einen Protokollzustand und ermöglicht das Verwerfen der Handshake-Schlüssel.
  • Für eine Bereitschaftsaussage müssen die Bestätigung, die 0-RTT-Entscheidung und das Anwendungsergebnis zusammengeführt werden.

Die Fehlinterpretation beginnt oft mit einem grünen Dashboard. HANDSHAKE_DONE trifft ein, der Dienst wird als bereit angezeigt, und aus einem engen Transport-Signal wird eine umfassende Geschäftsbehauptung. Dabei kann der Server frühe Daten abgelehnt haben. Dann muss der Client alle betroffenen Streams und den daran gebundenen Anwendungszustand zurücksetzen. Das Signal ist korrekt; nur die Schlussfolgerung ist zu weitgehend.

RFC 9001 beschreibt den Abschluss aus lokaler Sicht. Der lokale TLS-Stack muss eine Finished-Nachricht gesendet und die Finished-Nachricht des Peers überprüft haben. Daraus folgt kein gemeinsamer, gleichzeitig beobachteter Zeitpunkt. Ein belastbares Protokoll muss deshalb festhalten, welcher Endpunkt die Bedingung mit welcher Evidenz erfüllt sah.

Die Bestätigung richtet sich außerdem nach der Rolle. Auf dem Server ist der Handshake bestätigt, sobald er abgeschlossen ist; der Server muss dann umgehend HANDSHAKE_DONE senden. Auf dem Client bestätigt der Empfang von HANDSHAKE_DONE den Handshake. Alternativ darf der Client die Bestätigung aus einem ACK ableiten, das ein von ihm mit 1-RTT-Schlüsseln gesendetes Paket abdeckt. HANDSHAKE_DONE darf nur vom Server gesendet werden. Der Frame zeigt dem Client, dass der Server sein Handshake-Paket empfangen und verarbeitet hat. Er ist keine Antwort der Anwendung.

Die wichtigste Folge betrifft den Schlüsselzyklus. Nach der Bestätigung muss der Endpunkt die Handshake-Schlüssel verwerfen. Damit wird die kryptografische Handshake-Epoche beendet. Das beweist jedoch nicht, dass die Aushandlung des Anwendungsprotokolls abgeschlossen ist, dass eine Anfrage den Anwendungscode erreicht hat, dass ein Backend gesund ist oder dass ein Geschäftsvorgang dauerhaft gespeichert wurde.

Initial-Schlüssel gehören zu einem anderen Übergang. Der Client verwirft sie, sobald er erstmals ein Handshake-Paket sendet. Der Server verwirft sie, sobald er erstmals erfolgreich ein Handshake-Paket verarbeitet. Diese Nachweise dürfen nicht mit der Handshake-Bestätigung oder dem Verwerfen der Handshake-Schlüssel verschmolzen werden. Ein einziger Sammelstatus würde die entscheidenden Grenzen der Verbindung unsichtbar machen.

Auch die Entscheidung über 0-RTT ist eigenständig. Der Server akzeptiert 0-RTT, indem er die Erweiterung early_data in EncryptedExtensions aufnimmt, und lehnt es durch Weglassen der Erweiterung ab. Bei einer Ablehnung darf der Server keine 0-RTT-Pakete verarbeiten; der Client muss alle Streams und den daran gebundenen Anwendungszustand zurücksetzen. Ein späteres HANDSHAKE_DONE macht abgelehnte frühe Daten nicht nachträglich gültig.

Replay-Sicherheit liegt in der Verantwortung des Anwendungsprotokolls. Anwendungsdaten in 0-RTT können wegen Replay mehrfach verarbeitet werden. Der Client darf 0-RTT für Anwendungsdaten nur verwenden, wenn die Anwendung dies ausdrücklich verlangt; das Anwendungsprotokoll muss die zulässige Nutzung festlegen. Eine bestätigte Handshake-Epoche beweist deshalb weder Replay-Sicherheit noch genau-einmalige Ausführung, dauerhafte Speicherung oder Annahme der frühen Anfrage.

Auch das alternative 1-RTT-ACK bleibt transportbezogen. Deckt es die niedrigste 1-RTT-Paketnummer des Clients ab, erfüllt es die in RFC 9001 definierte Bestätigungsbedingung. Es beweist nicht, dass die Anwendung die Daten konsumiert, gespeichert, autorisiert oder einen Geschäftsvorgang abgeschlossen hat. Es ist ein kryptografischer Zustandsbeleg, kein Geschäftsbeleg.