4. Übertragung von TLS-Nachrichten (Carrying TLS Messages)
QUIC transportiert TLS-Handshake-Daten in CRYPTO-Frames. Jeder CRYPTO-Frame besteht aus einem zusammenhängenden Block von Handshake-Daten, der durch einen Offset und eine Länge identifiziert wird. Diese Frames werden in QUIC-Pakete verpackt und mit dem aktuellen Verschlüsselungsniveau verschlüsselt. Wie bei TLS über TCP liegt die Verantwortung für die zuverlässige Lieferung bei QUIC, sobald TLS-Handshake-Daten an QUIC übergeben wurden. Jeder von TLS produzierte Datenblock ist mit dem Satz von Schlüsseln verknüpft, die TLS derzeit verwendet. Wenn QUIC diese Daten erneut übertragen muss, MUSS (MUST) es dieselben Schlüssel verwenden, auch wenn TLS bereits auf neuere Schlüssel aktualisiert hat.
4.1. Schnittstelle zu TLS (Interface to TLS)
Wie in Abbildung 4 dargestellt, umfasst die Schnittstelle von QUIC zu TLS vier Hauptfunktionen:
- Senden und Empfangen von Handshake-Nachrichten
- Verarbeitung von Transport- und Anwendungsstatus, der aus Wiederaufnahme-Sitzungen gespeichert wurde, und Bestimmung der Gültigkeit der Generierung oder Annahme von 0-RTT-Daten
- Re-keying (einschließlich Senden und Empfangen)
- Aktualisierung des Handshake-Status
Zusätzliche Funktionen können erforderlich sein, um TLS zu konfigurieren. Insbesondere müssen QUIC und TLS sich darauf einigen, wer für die Validierung der Anmeldeinformationen der Peers verantwortlich ist (z.B. Zertifikatsvalidierung [RFC5280]).
4.1.1. Handshake abgeschlossen (Handshake Complete)
In diesem Dokument gilt der TLS-Handshake als abgeschlossen, wenn der TLS-Stack den Abschluss des Handshakes meldet. Dies tritt auf, wenn der TLS-Stack sowohl eine Finished-Nachricht gesendet als auch die Finished-Nachricht des Peers verifiziert hat.
4.1.2. Handshake bestätigt (Handshake Confirmed)
In diesem Dokument gilt der TLS-Handshake auf der Serverseite als bestätigt, wenn der Handshake abgeschlossen ist. Der Server MUSS (MUST) ein HANDSHAKE_DONE-Frame sofort nach Abschluss des Handshakes senden. Auf der Clientseite gilt der Handshake als bestätigt, wenn ein HANDSHAKE_DONE-Frame empfangen wird.
Zusätzlich KANN (MAY) der Client den Handshake als bestätigt betrachten, wenn er eine Bestätigung von 1-RTT-Paketen empfängt.
4.1.3. Senden und Empfangen von Handshake-Nachrichten
Um den Handshake zu steuern, verlässt sich TLS auf die Fähigkeit, Handshake-Nachrichten zu senden und zu empfangen. Es gibt zwei Grundfunktionen auf dieser Schnittstelle: eine Funktion für QUIC, um Handshake-Nachrichten anzufordern, und eine andere Funktion für QUIC, um die Bytes bereitzustellen, die eine Handshake-Nachricht bilden.
Vor Beginn des Handshakes stellt QUIC TLS die Transportparameter zur Verfügung, die es übertragen möchte (siehe Abschnitt 8.2).
Der QUIC-Client initiiert TLS, indem er die Handshake-Bytes von TLS anfordert. Der Client erhält die Handshake-Bytes, bevor er sein erstes Paket sendet. Der QUIC-Server initiiert den Prozess, indem er TLS die Handshake-Bytes des Clients bereitstellt.
4.1.4. Änderungen der Verschlüsselungsebene (Encryption Level Changes)
Wenn die Schlüssel für eine gegebene Verschlüsselungsebene für TLS verfügbar sind, teilt TLS QUIC mit, dass Lese- und Schreibschlüssel für diese Verschlüsselungsebene verfügbar sind.
4.1.5. TLS-Schnittstellenzusammenfassung (TLS Interface Summary)
Abbildung 5 fasst die Austausche zwischen QUIC und TLS für Client und Server zusammen. Durchgezogene Pfeile zeigen Pakete an, die Handshake-Daten tragen; gestrichelte Pfeile zeigen an, wo Anwendungsdaten gesendet werden können.
4.2. TLS-Version (TLS Version)
Dieses Dokument beschreibt, wie TLS 1.3 [TLS13] mit QUIC verwendet wird.
In der Praxis verhandelt der TLS-Handshake die zu verwendende TLS-Version. Wenn beide Endpunkte diese Version unterstützen, könnte dies zur Aushandlung einer neueren TLS-Version als 1.3 führen. Dies ist akzeptabel, solange die von QUIC verwendeten TLS 1.3-Funktionen von der neueren Version unterstützt werden.
Ein Client DARF NICHT (MUST NOT) eine TLS-Version vor 1.3 anbieten. Wenn eine TLS-Version vor 1.3 ausgehandelt wird, MUSS (MUST) der Endpunkt die Verbindung beenden.
4.3. ClientHello-Größe (ClientHello Size)
Das erste Initial-Paket eines Clients enthält den Anfang oder die Gesamtheit seiner ersten verschlüsselten Handshake-Nachricht, die für TLS das ClientHello ist. Ein Server muss möglicherweise das gesamte ClientHello analysieren, um zu entscheiden, ob er eine neue eingehende QUIC-Verbindung akzeptiert oder nicht.
4.4. Peer-Authentifizierung (Peer Authentication)
Die Authentifizierungsanforderungen hängen vom verwendeten Anwendungsprotokoll ab. TLS bietet Server-Authentifizierung und ermöglicht es dem Server, Client-Authentifizierung anzufordern.
Ein Client MUSS (MUST) die Identität des Servers authentifizieren. Dies beinhaltet typischerweise die Überprüfung, dass die Identität des Servers in einem Zertifikat enthalten ist und dass das Zertifikat von einer vertrauenswürdigen Entität ausgestellt wurde.
Ein Server KANN (MAY) während des Handshakes Client-Authentifizierung anfordern. Ein Server DARF NICHT (MUST NOT) Client-Authentifizierung nach dem Handshake verwenden.
4.5. Sitzungswiederaufnahme (Session Resumption)
QUIC kann die Sitzungswiederaufnahme-Funktion von TLS 1.3 verwenden. Dies geschieht durch das Transportieren von NewSessionTicket-Nachrichten in CRYPTO-Frames nach Abschluss des Handshakes.
4.6. 0-RTT
Die 0-RTT-Funktion von QUIC ermöglicht es einem Client, Anwendungsdaten vor Abschluss des Handshakes zu senden. Dies wird durch Wiederverwendung der von einer vorherigen Verbindung ausgehandelten Parameter ermöglicht.
4.6.1. Aktivierung von 0-RTT (Enabling 0-RTT)
Die TLS-Erweiterung early_data in der NewSessionTicket-Nachricht ist definiert, um die Menge an TLS-0-RTT-Daten zu übertragen, die der Server akzeptiert (im Parameter max_early_data_size). QUIC verwendet keine TLS-Frühdaten. QUIC verwendet 0-RTT-Datenpakete, um die Frühdaten zu übertragen. Daher wird der Parameter max_early_data_size wiederverwendet, um einen Sentinel-Wert 0xffffffff zu enthalten, um anzuzeigen, dass der Server bereit ist, QUIC-0-RTT-Daten zu akzeptieren.
4.6.2. Annahme und Ablehnung von 0-RTT
Ein Server akzeptiert 0-RTT, indem er eine early_data-Erweiterung in EncryptedExtensions sendet. Der Server verarbeitet und bestätigt dann die empfangenen 0-RTT-Datenpakete.
Ein Server lehnt 0-RTT ab, indem er EncryptedExtensions ohne early_data-Erweiterung sendet. Bei Ablehnung von 0-RTT DARF (MUST NOT) ein Server keine 0-RTT-Datenpakete verarbeiten, auch wenn er dies könnte.
4.6.3. Validierung der 0-RTT-Konfiguration
Wenn ein Server ein ClientHello mit einer early_data-Erweiterung empfängt, muss er entscheiden, ob er die 0-RTT-Daten des Clients akzeptiert oder ablehnt. Ein Teil der Entscheidung wird vom TLS-Stack getroffen.
4.7. HelloRetryRequest
Die HelloRetryRequest-Nachricht kann verwendet werden, um den Client aufzufordern, neue Informationen bereitzustellen oder bestimmte Client-Eigenschaften zu validieren. Aus QUIC-Sicht ist HelloRetryRequest nicht anders als eine andere verschlüsselte Handshake-Nachricht, die in Initial-Paketen transportiert wird.
4.8. TLS-Fehler (TLS Errors)
Wenn TLS auf einen Fehler stößt, generiert es die entsprechende in Abschnitt 6 von [TLS13] definierte Warnung.
TLS-Warnungen werden in QUIC-Verbindungsfehler umgewandelt. Der AlertDescription-Wert plus 0x0100 wird addiert, um einen QUIC-Fehlercode im CRYPTO_ERROR-Bereich zu erzeugen.
4.9. Verwerfen ungenutzter Schlüssel (Discarding Unused Keys)
Nachdem QUIC seinen Übergang zu einer neuen Verschlüsselungsebene abgeschlossen hat, können die Paketschutzschlüssel der vorherigen Verschlüsselungsebene verworfen werden.
4.9.1. Verwerfen initialer Schlüssel (Discarding Initial Keys)
Pakete, die durch initiale Geheimnisse geschützt sind, sind nicht authentifiziert, was bedeutet, dass ein Angreifer Pakete fälschen könnte, um eine Verbindung zu stören. Um diese Angriffe zu begrenzen, werden Initial-Paketschutzschlüssel aggressiver verworfen als andere Schlüssel.
4.9.2. Verwerfen von Handshake-Schlüsseln (Discarding Handshake Keys)
Ein Endpunkt MUSS (MUST) seine Handshake-Schlüssel verwerfen, wenn der TLS-Handshake bestätigt ist (Abschnitt 4.1.2).
4.9.3. Verwerfen von 0-RTT-Schlüsseln (Discarding 0-RTT Keys)
0-RTT- und 1-RTT-Pakete teilen sich denselben Paketnummernraum, und ein Client sendet keine 0-RTT-Pakete, nachdem er 1-RTT-Pakete gesendet hat (Abschnitt 5.6).
Daher SOLLTE (SHOULD) ein Client 0-RTT-Schlüssel verwerfen, sobald er 1-RTT-Schlüssel installiert, da sie danach nicht mehr nützlich sind.