Zusammenfassung

  • Ein CRYPTO-Frame ist ein zusammenhängender Offset-Längen-Bereich aus dem Handshake-Byte-Stream genau einer Verschlüsselungsebene.
  • Frame- und Paketgrenzen beweisen weder eine vollständige TLS-Nachricht noch eine vollständige Nachrichtenfolge, ein akzeptiertes Zertifikat, verfügbare Schlüssel oder Anwendungsbereitschaft.
  • Das Betriebsprotokoll muss QUIC-Transport, Ebenen-Reassemblierung, TLS-Parsing, Schlüsselzustand, erneute Übertragung und Abschlussquittungen trennen.

Die Fehlinterpretation beginnt mit einem zutreffenden, aber zu weit gehenden Befund. Ein Beobachter entfernt den QUIC-Paketschutz, sieht einen CRYPTO-Frame und meldet einen vollständigen ClientHello- oder Finished-Vorgang. Der Frame beschreibt jedoch nur einen zusammenhängenden Bereich von Handshake-Bytes mit Offset und Länge innerhalb einer bestimmten Verschlüsselungsebene. Er sagt nicht, dass dieser Bereich genau einer TLS-Nachricht entspricht, und besitzt kein explizites Ende.

Der Frame liegt vollständig in einem QUIC-Paket. Die Handshake-Daten sind dadurch aber nicht auf eine Paketgröße begrenzt. Eine TLS-Nachricht oder Nachrichtenfolge kann sich über mehrere CRYPTO-Frames und Pakete erstrecken. Ein einzelner Frame kann mitten in einer Nachricht beginnen und vor deren Ende enden. Verlorene kryptografische Informationen werden in neuen CRYPTO-Frames erneut übertragen und mit den Schlüsseln derselben Verschlüsselungsebene wie die ursprünglichen Bytes geschützt; dabei dürfen sich Frame- und Paketgrenzen ändern. Eine andere Verpackung beweist weder eine zweite Nachricht noch ein semantisches Duplikat.

Auch gibt es keinen einzigen CRYPTO-Stream für die gesamte Verbindung. Jede Verschlüsselungsebene besitzt eine eigene Bytefolge, deren Offsets bei null beginnen. Initial-, Handshake- und 1-RTT-Pakete können CRYPTO tragen, 0-RTT-Pakete nicht. Gleiche Offsets verschiedener Ebenen dürfen deshalb nicht zu einer globalen Sequenz verbunden werden. QUIC ordnet die Bytes je Ebene, hält Lücken vor und kann Daten einer künftigen Ebene speichern, bis TLS dafür bereit ist. Nur neu verfügbare zusammenhängende Bytes werden geordnet an TLS geliefert.

Die Zuständigkeiten sind getrennt. QUIC übernimmt Ordnung und Pufferung von Bytes, die außerhalb der Reihenfolge eintreffen. TLS puffert die geordnet gelieferten Bytes und entscheidet, wann eine vollständige Nachricht oder Nachrichtenfolge vorliegt. TLS kann schrittweise verarbeiten oder warten. Das erfolgreiche Entfernen des Paketschutzes ist daher kein erfolgreiches TLS-Parsing. Schlüsselverfügbarkeit ist ein Ergebnis der TLS-Verarbeitung, nicht der bloßen Sichtbarkeit eines CRYPTO-Frames. Ebenso wenig beweist der Frame, dass ein Schlüssel installiert wurde.

Ein belastbares Ledger führt zunächst QUIC-Version, Pakettyp, Paketnummernraum, Verschlüsselungsebene, Ergebnis des Paketschutzes und Paketnummer. Danach folgen CRYPTO-Offset, Länge und ein datensparsamer Digest, der zusammenhängende Bereich je Ebene, noch gepufferte Lücken sowie der an TLS gelieferte Bereich. Der TLS-Nachrichtentyp darf erst nach dem Parsing einer vollständigen Nachricht erscheinen. Zertifikatsprüfung, Alerts, Schlüsselverfügbarkeit, Schlüsselverwerfung, TLS-Handshake-Abschluss, QUIC-Handshake-Bestätigung und Anwendungsbereitschaft brauchen eigene Quittungen.

CRYPTO transportiert ausschließlich TLS-Handshake-Nachrichten. TLS-Warnungen werden QUIC-CONNECTION_CLOSE-Fehlercodes zugeordnet; TLS-Anwendungsdaten und andere TLS-Inhaltstypen können nicht in CRYPTO-Frames transportiert werden. CRYPTO ist nicht flusskontrolliert und besitzt weder Stream-ID noch FIN oder ein explizites Ende. Implementierungen müssen mindestens 4096 Byte außer der Reihe liegender CRYPTO-Daten unterstützen. Ein übermäßig großer höchster Offset kann FRAME_ENCODING_ERROR oder CRYPTO_BUFFER_EXCEEDED auslösen.

Das sind Transport- und Ressourcenschutzsignale, keine Belege für Zertifikatsannahme, Schlüsselwechsel oder Dienstbereitschaft.

Wenn TLS in eine höhere Ebene wechselt, während Daten der vorherigen Ebene noch nicht von TLS verbraucht wurden, gilt dies als PROTOCOL_VIOLATION. Beim Verwerfen der Schlüssel des entsprechenden Paketnummernraums werden die zugehörigen Initial- oder Handshake-Daten verworfen. Auch das ist keine semantische TLS-Nachrichtengrenze. Der TLS-Handshake ist erst abgeschlossen, wenn der TLS-Stack dies nach dem Senden seines Finished und der Prüfung des Peer-Finished meldet. QUIC-Bestätigung und Anwendungsbereitschaft sind spätere, getrennte Zustände.

Fünf benachbarte Themen bleiben getrennt. TR-048 behandelt Handshake-Bestätigung und Anwendungsbereitschaft. TR-049 behandelt koaleszierte Pakete in einem UDP-Datagramm. TR-045 behandelt die Aussagekraft von ACKs. TR-056 behandelt rekonstruierte Paketnummern. TR-063 behandelt die Migration zu einer bevorzugten Adresse. Keines dieser Themen macht einen CRYPTO-Frame zu einer TLS-Nachrichtengrenze.

Die Regel lautet: Jede Behauptung braucht eine Quittung auf derselben Ebene. Der Frame belegt einen bestimmten Bytebereich in einer Ebene. Reassemblierung belegt Kontinuität je Ebene. Das TLS-Parsing belegt eine vollständige Nachricht. Zertifikat, Schlüssel, TLS-Abschluss, QUIC-Bestätigung und Anwendungsbereitschaft benötigen jeweils eigene Nachweise.