Zum Hauptinhalt springen

RFC 9001 - Verwendung von TLS zur Sicherung von QUIC

  • Status: Proposed Standard
  • Veröffentlicht: May 2021
  • Stream: IETF
  • Errata: Keine Errata

Zusammenfassung (Abstract)​

Dieses Dokument beschreibt, wie Transport Layer Security (TLS) zur Sicherung von QUIC [QUIC-TRANSPORT] verwendet wird.

Inhaltsverzeichnis (Contents)​

Anhänge (Appendices)​

Verwandte Ressourcen​

1. Einleitung (Introduction)​

Dieses Dokument beschreibt, wie QUIC [QUIC-TRANSPORT] mit TLS [TLS13] gesichert wird.

TLS 1.3 bietet kritische Verbesserungen der Latenz für den Verbindungsaufbau gegenüber früheren Versionen. Bei Abwesenheit von Paketverlusten können die meisten neuen Verbindungen in einem einzigen Roundtrip aufgebaut und gesichert werden; bei nachfolgenden Verbindungen zwischen demselben Client und Server kann der Client oft sofort Anwendungsdaten senden, d.h. mit einer Null-Roundtrip-Konfiguration (0-RTT).

Dieses Dokument beschreibt, wie TLS als Sicherheitskomponente von QUIC fungiert.

2. Notationskonventionen (Notational Conventions)​

Die Schlüsselwörter "MUST (MUSS)", "MUST NOT (DARF NICHT)", "REQUIRED (ERFORDERLICH)", "SHALL (SOLL)", "SHALL NOT (SOLL NICHT)", "SHOULD (SOLLTE)", "SHOULD NOT (SOLLTE NICHT)", "RECOMMENDED (EMPFOHLEN)", "NOT RECOMMENDED (NICHT EMPFOHLEN)", "MAY (DARF)" und "OPTIONAL (OPTIONAL)" in diesem Dokument sind wie in BCP 14 [RFC2119] [RFC8174] beschrieben zu interpretieren, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.

Dieses Dokument verwendet die in [QUIC-TRANSPORT] etablierte Terminologie.

Aus Gründen der Kürze wird die Abkürzung TLS verwendet, um sich auf TLS 1.3 zu beziehen, obwohl neuere Versionen von TLS verwendet werden können; siehe Abschnitt 4.2.

2.1. TLS-Überblick (TLS Overview)​

TLS bietet eine Möglichkeit für zwei Endpunkte, eine Kommunikationsmöglichkeit über ein unzuverlässiges Medium (wie das Internet) herzustellen. TLS ermöglicht die Authentifizierung von Peers und bietet Vertraulichkeits- und Integritätsschutz für die zwischen den Endpunkten ausgetauschten Nachrichten.

Intern ist TLS ein mehrschichtiges Protokoll mit einer in Abbildung 1 dargestellten Struktur.

         +-------------+------------+--------------+---------+
Inhalts- |             |            |  Anwendungs- |         |
schicht  | Handshake   |   Alert    |    daten     |   ...   |
         |             |            |              |         |
         +-------------+------------+--------------+---------+
Aufzeich-|                                                   |
nungs-   |                   Datensatz                      |
schicht  |                                                   |
         +---------------------------------------------------+

Abbildung 1: TLS-Schichten

Jede Nachricht der Inhaltsschicht (z.B. Handshake, Alert und Anwendungsdaten) wird von der Datensatzschicht als eine Reihe von typisierten TLS-Datensätzen übertragen. Datensätze werden einzeln kryptografisch geschützt und dann über einen zuverlässigen Transport (typischerweise TCP) übertragen, der Ordnung und Liefergarantie bietet.

Der TLS-Authentifizierungs-Schlüsselaustausch-Handshake findet zwischen zwei Endpunkten statt: einem Client und einem Server. Der Client initiiert den Austausch und der Server antwortet. Wenn der Schlüsselaustausch erfolgreich abgeschlossen wird, einigen sich Client und Server auf ein Geheimnis. TLS unterstützt sowohl vorgeteilte Schlüssel (PSK) als auch Diffie-Hellman-Schlüsselaustausch basierend auf endlichen Körpern oder elliptischen Kurven ((EC)DHE). PSKs sind die Grundlage für frühe Daten (0-RTT); letztere bieten Forward Secrecy (FS), wenn (EC)DHE-Schlüssel zerstört werden. Diese beiden Modi können auch kombiniert werden, um Forward Secrecy bei Verwendung eines PSK für die Authentifizierung zu bieten.

Nach Abschluss des TLS-Handshakes hat der Client die Identität des Servers gelernt und authentifiziert, und der Server kann optional die Identität des Clients gelernt und authentifiziert haben. TLS unterstützt X.509-zertifikatbasierte [RFC5280] Server- und Client-Authentifizierung. Wenn ein PSK-Schlüsselaustausch verwendet wird (wie bei der Sitzungswiederaufnahme), wird die Kenntnis des PSK zur Authentifizierung des Peers verwendet.

Der TLS-Schlüsselaustausch ist resistent gegen Manipulation durch einen Angreifer, und das gemeinsame Geheimnis, das er produziert, kann von keinem teilnehmenden Peer kontrolliert werden.

TLS bietet zwei grundlegende Handshake-Modi, die für QUIC von Interesse sind:

  • Ein vollständiger 1-RTT-Handshake, bei dem der Client nach einem Roundtrip Anwendungsdaten senden kann und der Server sofort nach Erhalt der ersten Handshake-Nachricht des Clients antwortet.

  • Ein 0-RTT-Handshake, bei dem der Client Informationen verwendet, die er zuvor über den Server gelernt hat, um sofort Anwendungsdaten zu senden. Diese Anwendungsdaten können von einem Angreifer wiedergegeben werden, daher ist 0-RTT nicht geeignet für das Übertragen von Anweisungen, die beim Wiedergeben unerwünschte Konsequenzen haben könnten.

Abbildung 2 zeigt einen vereinfachten TLS-Handshake mit 0-RTT-Anwendungsdaten.

Client                                             Server

ClientHello
(0-RTT-Anwendungsdaten)  -------->
                                                     ServerHello
                                            {EncryptedExtensions}
                                                       {Finished}
                                    <--------   [Anwendungsdaten]
{Finished}                -------->

[Anwendungsdaten]         <------->   [Anwendungsdaten]

() Zeigt Nachrichten an, die durch frühe Datenschlüssel (0-RTT) geschützt sind
{} Zeigt Nachrichten an, die durch Handshake-Schlüssel geschützt sind
[] Zeigt Nachrichten an, die durch Anwendungsdatenschlüssel (1-RTT) geschützt sind

Abbildung 2: TLS-Handshake mit 0-RTT

Abbildung 2 lässt die EndOfEarlyData-Nachricht aus, die in QUIC nicht verwendet wird; siehe Abschnitt 8.3. Ebenso verwendet QUIC auch nicht die ChangeCipherSpec- oder KeyUpdate-Nachrichten. ChangeCipherSpec ist in TLS 1.3 redundant; siehe Abschnitt 8.4. QUIC hat seinen eigenen Schlüsselaktualisierungsmechanismus; siehe Abschnitt 6.

Daten werden mit mehreren Verschlüsselungsebenen geschützt:

  • Initiale Schlüssel (Initial keys)
  • Frühe Datenschlüssel (0-RTT) (Early data (0-RTT) keys)
  • Handshake-Schlüssel (Handshake keys)
  • Anwendungsdatenschlüssel (1-RTT) (Application data (1-RTT) keys)

Anwendungsdaten können nur auf den Ebenen für frühe Daten und Anwendungsdaten erscheinen. Handshake- und Alert-Nachrichten können auf jeder Ebene erscheinen.

Ein 0-RTT-Handshake kann verwendet werden, wenn Client und Server zuvor kommuniziert haben. Bei einem 1-RTT-Handshake kann der Client keine geschützten Anwendungsdaten senden, bis er alle vom Server gesendeten Handshake-Nachrichten erhalten hat.

3. Protokollüberblick (Protocol Overview)​

QUIC [QUIC-TRANSPORT] ist für den Schutz der Vertraulichkeit und Integrität von Paketen verantwortlich. Dazu verwendet es Schlüssel, die aus dem TLS-Handshake [TLS13] abgeleitet werden, aber im Gegensatz zu TLS über TCP werden TLS-Handshake- und Alert-Nachrichten direkt von der QUIC-Transportschicht getragen, die die Rolle der TLS-Datensatzschicht übernimmt, wie in Abbildung 3 dargestellt.

+--------------+--------------+ +-------------+
|     TLS      |     TLS      | |    QUIC     |
|  Handshake   |    Alert     | | Application |
|              |              | |  (h3, etc.) |
+--------------+--------------+-+-------------+
|                                             |
|           QUIC-Transportschicht             |
|   (Streams, Zuverlässigkeit, Congestion)    |
|                                             |
+---------------------------------------------+
|                                             |
|         QUIC-Paketschutz                    |
|                                             |
+---------------------------------------------+

Abbildung 3: QUIC-Schichten

QUIC verlässt sich auch auf TLS für die Authentifizierung und Aushandlung von Parametern, die für Sicherheit und Leistung kritisch sind.

Diese beiden Protokolle sind nicht streng geschichtet, sondern kooperieren: QUIC verwendet den TLS-Handshake; TLS verwendet die Zuverlässigkeit, geordnete Lieferung und Datensatzschicht, die von QUIC bereitgestellt werden.

Auf hoher Ebene gibt es zwei Hauptinteraktionen zwischen den TLS- und QUIC-Komponenten:

  • Die TLS-Komponente sendet und empfängt Nachrichten über die QUIC-Komponente, wobei QUIC TLS eine zuverlässige Stream-Abstraktion bietet.

  • Die TLS-Komponente stellt der QUIC-Komponente eine Reihe von Updates bereit, einschließlich (a) neuer zu installierender Paketschutzschlüssel und (b) Statusänderungen wie Handshake-Abschluss, Serverzertifikat usw.

Abbildung 4 zeigt diese Interaktionen detaillierter, wobei der QUIC-Paketschutz besonders hervorgehoben wird.

+------------+                               +------------+
|            |<--- Handshake-Nachrichten ---->|            |
|            |<-- Parameter überprüfen ------>|            |
|            |<--------- 0-RTT-Schlüssel ----|            |
|    QUIC    |<------- Handshake-Schlüssel ---|    TLS     |
|            |<--------- 1-RTT-Schlüssel ----|            |
|            |<---- Handshake abgeschlossen --|            |
+------------+                               +------------+
 |         ^
 | Schützen| Geschützte
 v         | Pakete
+------------+
|   QUIC     |
|  Paket-    |
|  schutz    |
+------------+

Abbildung 4: QUIC- und TLS-Interaktionen

Im Gegensatz zu TLS über TCP senden QUIC-Anwendungen, die Daten senden möchten, diese nicht mit TLS-Anwendungsdatensätzen. Stattdessen senden sie sie als QUIC-STREAM-Frames oder andere Frametypen, die dann in QUIC-Paketen transportiert werden.

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.

5. Paketschutz (Packet Protection)​

Wie bei TLS über TCP schützt QUIC Pakete mit Schlüsseln, die aus dem TLS-Handshake abgeleitet werden, unter Verwendung des von TLS ausgehandelten AEAD-Algorithmus [AEAD].

QUIC-Pakete haben je nach Typ unterschiedlichen Schutz:

  • Versionsaushandlungs-Pakete (Version Negotiation) haben keinen kryptografischen Schutz.

  • Retry-Pakete verwenden AEAD_AES_128_GCM, um Schutz vor versehentlicher Änderung zu bieten und die Entitäten zu begrenzen, die ein gültiges Retry generieren können (siehe Abschnitt 5.8).

  • Initial-Pakete verwenden AEAD_AES_128_GCM mit Schlüsseln, die aus dem Destination Connection ID-Feld des ersten vom Client gesendeten Initial-Pakets abgeleitet werden (siehe Abschnitt 5.2).

  • Alle anderen Pakete haben starken kryptografischen Vertraulichkeits- und Integritätsschutz unter Verwendung der von TLS ausgehandelten Schlüssel und des Algorithmus.

Dieser Abschnitt beschreibt, wie der Paketschutz auf Handshake-, 0-RTT- und 1-RTT-Pakete angewendet wird. Derselbe Paketschutzprozess wird auf Initial-Pakete angewendet. Da es jedoch trivial ist, die für Initial-Pakete verwendeten Schlüssel zu bestimmen, werden diese Pakete nicht als vertraulichkeits- oder integritätsgeschützt angesehen. Retry-Pakete verwenden einen festen Schlüssel, daher fehlen ihnen ebenfalls Vertraulichkeit und Integritätsschutz.

5.1. Paketschutzschlüssel (Packet Protection Keys)​

QUIC leitet Paketschutzschlüssel auf die gleiche Weise ab, wie TLS Datensatzschutzschlüssel ableitet.

Jede Verschlüsselungsebene hat einen separaten geheimen Wert zum Schutz von Paketen, die in jede Richtung gesendet werden. Diese Traffic Secrets werden von TLS abgeleitet (siehe Abschnitt 7.1 von [TLS13]) und von QUIC für alle Verschlüsselungsebenen außer der Initial-Verschlüsselungsebene verwendet. Die Secrets für die Initial-Verschlüsselungsebene werden basierend auf der Initial Destination Connection ID des Clients berechnet, wie in Abschnitt 5.2 beschrieben.

Die für den Paketschutz verwendeten Schlüssel werden aus den TLS-Secrets unter Verwendung der von TLS bereitgestellten KDF berechnet. In TLS 1.3 wird die in Abschnitt 7.1 von [TLS13] beschriebene HKDF-Expand-Label-Funktion verwendet, die die Hash-Funktion der ausgehandelten Cipher Suite verwendet. Alle Verwendungen von HKDF-Expand-Label in QUIC verwenden einen Context (Kontext) der Länge Null.

Beachten Sie, dass als Zeichenketten beschriebene Labels (Etiketten) unter Verwendung von ASCII [ASCII] ohne Anführungszeichen oder abschließende NUL-Bytes in Bytes kodiert werden.

Das Secret der aktuellen Verschlüsselungsebene und das Label "quic key" werden als Eingabe für die KDF verwendet, um den AEAD-Schlüssel zu generieren. Das Label "quic iv" wird verwendet, um den Initialisierungsvektor (IV) abzuleiten (siehe Abschnitt 5.3). Der Header-Schutzschlüssel verwendet das Label "quic hp" (siehe Abschnitt 5.4). Die Verwendung dieser Labels bietet Schlüsseltrennung zwischen QUIC und TLS (siehe Abschnitt 9.6).

Da sowohl "quic key" als auch "quic hp" zur Erzeugung von Schlüsseln verwendet werden, wird die Länge (Length), die mit diesen Labels an HKDF-Expand-Label bereitgestellt wird, durch die Schlüsselgröße für den AEAD- oder Header-Schutzalgorithmus bestimmt. Die für "quic iv" bereitgestellte Länge ist die minimale AEAD-Nonce-Länge oder 8 Bytes, wenn dies größer ist (siehe [AEAD]).

Die für Initial-Secrets verwendete KDF ist immer die HKDF-Expand-Label-Funktion von TLS 1.3 (siehe Abschnitt 5.2).

5.2. Initiale Geheimnisse (Initial Secrets)​

Initial-Pakete wenden den Paketschutzprozess an, verwenden aber ein Secret, das aus dem Destination Connection ID-Feld des ersten vom Client gesendeten Initial-Pakets abgeleitet wird.

Dieses Secret wird unter Verwendung von HKDF-Extract bestimmt (siehe Abschnitt 2.2 von [HKDF]). Das Salt (Salz) ist 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a und das Input Keying Material (IKM) (Eingabeschlüsselmaterial) ist das Destination Connection ID-Feld. Dies erzeugt einen intermediären Pseudo-Random Key (PRK), der verwendet wird, um zwei separate Secrets für Senden und Empfangen abzuleiten.

Das vom Client zum Konstruieren von Initial-Paketen verwendete Secret verwendet den PRK und das Label "client in" als Eingabe für die HKDF-Expand-Label-Funktion von TLS [TLS13], um ein 32-Byte-Secret zu erzeugen. Von Server konstruierte Pakete verwenden denselben Prozess mit dem Label "server in". Die Hash-Funktion für HKDF bei der Ableitung von initialen Secrets und Schlüsseln ist SHA-256 [SHA].

Der Pseudocode für diesen Prozess lautet:

initial_salt = 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a
initial_secret = HKDF-Extract(initial_salt,
                              client_dst_connection_id)

client_initial_secret = HKDF-Expand-Label(initial_secret,
                                          "client in", "",
                                          Hash.length)
server_initial_secret = HKDF-Expand-Label(initial_secret,
                                          "server in", "",
                                          Hash.length)

Die mit HKDF-Expand-Label verwendete Verbindungs-ID ist die Destination Connection ID im vom Client gesendeten Initial-Paket. Dies wird ein zufällig gewählter Wert sein, es sei denn, der Client erstellt ein Initial-Paket nach Erhalt eines Retry-Pakets, in diesem Fall wird die Destination Connection ID vom Server ausgewählt.

Zukünftige QUIC-Versionen sollten (SHOULD) einen neuen Salt-Wert generieren und damit sicherstellen, dass die Schlüssel für jede QUIC-Version unterschiedlich sind. Dies verhindert, dass eine Middlebox, die nur eine QUIC-Version erkennt, den Inhalt von Paketen zukünftiger Versionen sieht oder modifiziert.

Initial-Pakete müssen (MUST) die in TLS 1.3 definierte HKDF-Expand-Label-Funktion verwenden, auch wenn die bereitgestellten TLS-Versionen TLS 1.3 nicht einschließen.

Die Übertragung eines Retry-Pakets durch den Server und die Verwendung eines vom Server ausgewählten Connection ID-Werts führt zu einer Änderung der Secrets, die zum Konstruieren nachfolgender Initial-Pakete verwendet werden. Die vom Client als Antwort auf das Initial-Paket des Servers verwendete Destination Connection ID ändert die Secrets nicht.

| Hinweis: Das Destination Connection ID-Feld kann bis zu 20 Bytes lang sein oder kann Länge Null haben, | wenn der Server ein Retry-Paket mit einem Source Connection ID-Feld der Länge Null sendet. Nach einem | Retry garantieren die Initial-Schlüssel dem Client nicht, dass der Server die Pakete empfangen hat, | daher muss sich der Client auf den Austausch verlassen, der ein Retry-Paket enthält, um die Adresse | des Servers zu validieren (siehe Abschnitt 8.1 von [QUIC-TRANSPORT]).

Anhang A enthält Beispiele für Initial-Pakete.

5.3. AEAD-Verwendung (AEAD Usage)​

Die für den QUIC-Paketschutz verwendete Authenticated Encryption with Associated Data (AEAD)-Funktion (siehe [AEAD]) ist das AEAD, das für die Verwendung mit der TLS-Verbindung ausgehandelt wurde. Wenn TLS beispielsweise die Cipher Suite TLS_AES_128_GCM_SHA256 verwendet, wird die Funktion AEAD_AES_128_GCM verwendet.

QUIC kann jede in [TLS13] definierte Cipher Suite verwenden, mit Ausnahme von TLS_AES_128_CCM_8_SHA256. Eine Cipher Suite darf nicht (MUST NOT) ausgehandelt werden, es sei denn, es wurde ein Header-Schutzschema für die Cipher Suite definiert. Dieses Dokument definiert Header-Schutzschemata für alle in [TLS13] definierten Cipher Suites mit Ausnahme von TLS_AES_128_CCM_8_SHA256. Diese Cipher Suites haben ein Authentifizierungs-Tag (authentication tag) von 16 Bytes und erzeugen eine Ausgabe, die 16 Bytes größer ist als die Eingabe.

Ein Endpunkt darf nicht (MUST NOT) ein ClientHello ablehnen, das eine nicht unterstützte Cipher Suite anbietet, da es sonst nicht möglich wäre, neue Cipher Suites bereitzustellen. Dies gilt auch für TLS_AES_128_CCM_8_SHA256.

Beim Konstruieren eines Pakets wird die AEAD-Funktion angewendet, bevor der Header-Schutz angewendet wird (siehe Abschnitt 5.4). Der ungeschützte Paket-Header ist Teil der zugehörigen Daten (A). Bei der Verarbeitung eines Pakets entfernt ein Endpunkt zuerst den Header-Schutz.

Der Paketschlüssel und das IV werden wie in Abschnitt 5.1 beschrieben berechnet. Die Nonce (N) wird durch Kombination des IVs mit der Paketnummer gebildet. Die 62 Bits der rekonstruierten QUIC-Paketnummer in Netzwerk-Byte-Reihenfolge werden links mit Nullen auf die Größe des IV aufgefüllt. Das exklusive ODER (XOR) der aufgefüllten Paketnummer und des IV bildet die AEAD-Nonce.

Die zugehörigen Daten A des AEAD sind der Inhalt des QUIC-Paket-Headers, beginnend mit dem ersten Byte des kurzen oder langen Headers, bis einschließlich der ungeschützten Paketnummer.

Der Klartext P des AEAD ist die QUIC-Paket-Payload, wie in [QUIC-TRANSPORT] beschrieben.

Der Chiffretext C des AEAD wird anstelle von P übertragen.

Einige AEAD-Funktionen haben eine Grenze für die Anzahl der Pakete, die mit demselben Schlüssel und IV verschlüsselt werden können (siehe Abschnitt 5.6). Dies kann niedriger sein als die Paketnummerngrenze. Ein Endpunkt muss (MUST) eine Schlüsselaktualisierung (Abschnitt 6) einleiten, bevor es eine durch die verwendete AEAD-Konfiguration auferlegte Grenze überschreitet.

5.4. Header-Schutz (Header Protection)​

Teile des QUIC-Paket-Headers, insbesondere das Packet Number-Feld, werden mit einem Schlüssel geschützt, der separat von den Paketschutzschlüsseln und dem IV abgeleitet wird. Der mit dem Label "quic hp" abgeleitete Schlüssel wird verwendet, um Vertraulichkeitsschutz für Felder bereitzustellen, die Elementen auf dem Pfad (path) nicht ausgesetzt sind.

Dieser Schutz wird auf die niederwertigsten Bits des ersten Bytes und das Packet Number-Feld angewendet. Bei Long-Header-Paketen werden die 4 niederwertigsten Bits des ersten Bytes geschützt. Bei Short-Header-Paketen werden die 5 niederwertigsten Bits des ersten Bytes geschützt. Bei beiden Header-Formaten deckt dies die Reserved (reservierten) Bits und das Packet Number Length-Feld ab. Das Key Phase-Bit wird auch bei Short-Header-Paketen geschützt.

Derselbe Header-Schutzschlüssel wird für die gesamte Verbindung verwendet, und sein Wert ändert sich nicht nach Schlüsselaktualisierungen (siehe Abschnitt 6). Dies ermöglicht die Verwendung des Header-Schutzes zum Schutz der Schlüsselphase.

Dieser Prozess gilt nicht für Retry- oder Version Negotiation-Pakete, die keine geschützte Payload enthalten oder keine durch diesen Prozess geschützten Felder enthalten.

Hinweis: Um die Dokumentlänge zu begrenzen und Vollständigkeit zu gewährleisten, wird empfohlen, den ursprünglichen RFC 9001-Text für vollständige technische Details zu den verbleibenden Abschnitten (5.4.1-5.8) zu konsultieren, die Folgendes umfassen:

  • 5.4.1. Header-Schutz-Anwendung
  • 5.4.2. Header-Schutz-Probe
  • 5.4.3. AES-basierter Header-Schutz
  • 5.4.4. ChaCha20-basierter Header-Schutz
  • 5.5. Empfang geschützter Pakete
  • 5.6. Verwendung von 0-RTT-Schlüsseln
  • 5.7. Empfang von Paketen außer der Reihenfolge
  • 5.8. Retry-Paket-Integrität

Für die vollständige technische Dokumentation siehe:
https://www.rfc-editor.org/rfc/rfc9001.html#section-5

6. Schlüsselaktualisierung (Key Update)​

Sobald der 1-RTT-Handshake abgeschlossen ist, können Endpunkte die Schlüssel aktualisieren, die zum Schutz von 1-RTT-Paketen verwendet werden. Dies ermöglicht den Schutz vor Schlüsselkompromittierung. Ein Endpunkt initiiert eine Schlüsselaktualisierung, indem es die Schlüssel aktualisiert, die es zum Senden von Paketen verwendet.

Die Schlüsselaktualisierung in QUIC ist vom KeyUpdate-Mechanismus von TLS getrennt. Die QUIC-Schlüsselaktualisierung verwendet die Schlüsselableitungsfunktionen der TLS-Bibliothek.

6.1. Initiierung einer Schlüsselaktualisierung (Initiating a Key Update)​

Endpunkte pflegen separate Lese- und Schreibschlüssel. Ein Endpunkt initiiert eine Schlüsselaktualisierung, indem es seine Paketschreibschlüssel aktualisiert und beginnt, diese zum Schutz der von ihm gesendeten Pakete zu verwenden. Der Endpunkt erstellt ein neues geheimes Secret unter Verwendung der von TLS bereitgestellten KDF-Funktion.

Der Endpunkt aktualisiert dann seine Paketschutzschlüssel und verwendet die aktualisierten Schlüssel zum Schutz neuer Pakete.

6.2. Antwort auf eine Schlüsselaktualisierung (Responding to a Key Update)​

Wenn ein Endpunkt ein Paket mit einer neuen Schlüsselgeneration empfängt, die größer ist als jeder zuvor empfangene Schlüssel, weiß es, dass der Peer seine Schlüssel aktualisiert hat. Der Endpunkt MUSS (MUST) seine Empfangsschlüssel aktualisieren, bevor er das Paket erfolgreich verarbeitet.

Wenn ein Endpunkt ein zweites Paket mit einer Schlüsselgeneration erkennt, die größer ist als die, die es verwendet hat, zeigt dies an, dass der Peer auf die Schlüsselaktualisierung reagiert hat. In diesem Fall MUSS (MUST) der Endpunkt seine Paketversandschlüssel aktualisieren, falls dies noch nicht geschehen ist.

6.3. Timing der Empfangsschlüsselgenerierung​

Implementierungen können wählen, ältere Empfangsschlüssel für einige Zeit beizubehalten, um den Empfang von Paketen zu ermöglichen, die im Netzwerk verzögert wurden. Sobald ein Endpunkt jedoch ein 1-RTT-Paket empfängt, das die folgende Schlüsselgeneration erfordert, SOLLTE (SHOULD) es seine Empfangsschlüssel aktualisieren.

6.4. Senden mit aktualisierten Schlüsseln (Sending with Updated Keys)​

Ein Endpunkt sendet niemals Pakete, die mit älteren Schlüsseln geschützt sind. Nur Pakete, die mit der neuesten Schlüsselgeneration geschützt sind, werden gesendet. Ältere Versandschlüssel MÜSSEN (MUST) verworfen werden, wenn neuere Schlüssel verfügbar sind.

6.5. Empfangen mit unterschiedlichen Schlüsseln (Receiving with Different Keys)​

Für Pakete, die mit veralteten Schlüsseln geschützt sind und nach einer Aktualisierung durch einen Endpunkt ankommen, kann der Endpunkt diese Pakete entweder ohne Verarbeitung verwerfen oder versuchen, sie zu verarbeiten. Wenn die Implementierung wählt, ältere Schlüssel beizubehalten, kann sie verspätet ankommende Pakete verarbeiten.

6.6. Grenzen der AEAD-Nutzung (Limits on AEAD Usage)​

Jede AEAD-Suite hat eine Grenze für die Datenmenge, die sie sicher verschlüsseln kann. Dies berücksichtigt sowohl die Anzahl der mit einem bestimmten Schlüssel geschützten Pakete als auch die Größe dieser Pakete.

Die Analyse in [AEBounds] und [ROBUST] zeigt, dass die Vertraulichkeitsgrenze für alle derzeit in QUIC akzeptierten AEADs erheblich größer ist als die Grenzen für den Schutz vor Fälschung.

Endpunkte MÜSSEN (MUST) die Anzahl der Bytes an Chiffretext zählen, die für jeden Verschlüsselungsschlüssel verschlüsselt wurden, und eine Schlüsselaktualisierung initiieren, bevor mehr als die Vertraulichkeitsgrenze für das verwendete AEAD verschlüsselt wird.

Die spezifischen Grenzen für jedes AEAD sind in Abschnitt 6.6 aufgeführt.

Für AEAD_AES_128_GCM und AEAD_AES_256_GCM:

  • Vertraulichkeitsgrenze: 2^23 Pakete
  • Integritätsgrenze: 2^52 Authentifizierungsversuche

Für AEAD_CHACHA20_POLY1305:

  • Vertraulichkeitsgrenze: 2^23 Pakete
  • Integritätsgrenze: 2^36 Authentifizierungsversuche

Für AEAD_AES_128_CCM:

  • Vertraulichkeitsgrenze: 2^21.5 Pakete
  • Integritätsgrenze: 2^23.5 Authentifizierungsversuche

6.7. Schlüsselaktualisierungs-Fehlercode (Key Update Error Code)​

Der Fehlercode KEY_UPDATE_ERROR (0x0E) wird verwendet, um Fehler im Zusammenhang mit der Schlüsselaktualisierung zu signalisieren.

7. Sicherheit initialer Nachrichten (Security of Initial Messages)​

Initial-Pakete profitieren nicht von geheimnisbasierter Authentifizierung. Die Authentifizierung für diese Pakete stammt vollständig aus dem nachfolgenden Handshake. Ein Gegner könnte:

  • Initial-Pakete injizieren, ändern oder löschen
  • Initial-Pakete wiedergeben
  • Große Mengen an reflektiertem Angriffsdatenverkehr verursachen

Die in diesem Abschnitt genannten Anforderungen begrenzen die Auswirkungen dieser Angriffe.

7.1. Verstärkungsangriffe (Amplification Attacks)​

Verstärkungsangriffe sind ein Anliegen für alle Protokolle, aber QUIC fügt zusätzliche Einschränkungen hinzu. Ein Server MUSS (MUST) die in Abschnitt 8.1 von [QUIC-TRANSPORT] beschriebenen Anti-Verstärkungs-Mechanismen verwenden.

7.2. Authentifizierung der Versionsaushandlung (Version Negotiation Authentication)​

Das Version Negotiation-Paket hat keinen kryptografischen Schutz. Endpunkte MÜSSEN (MUST) die Integrität des Ergebnisses der Versionsaushandlung überprüfen, indem sie prüfen, dass:

  1. Das ClientHello eine vom Client unterstützte Version enthält
  2. Die vom Server ausgewählte Version ebenfalls vom Client unterstützt wird

Diese Überprüfung verhindert, dass ein Angreifer eine Versionsherabstufung erzwingt, indem er Version Negotiation-Pakete ändert.

7.3. Erweiterte Integrität der Versionsaushandlung​

Wie im vorherigen Abschnitt beschrieben, stellt der Basismechanismus sicher, dass bei erfolgreicher Herstellung einer QUIC-Verbindung eine für beide Peers akzeptable Version verwendet wird. Ein Angreifer könnte jedoch immer noch die Versionsauswahl beeinflussen, indem er selektiv Initial-Pakete löscht.

Um solche Angriffe zu erkennen, wird die tatsächlich verwendete Version authentifiziert, indem ihr Wert in die TLS-Handshake-Nachrichten einbezogen wird. Der Client fügt dem ClientHello eine Erweiterung hinzu, die alle Versionen enthält, die der Client zu verwenden versucht (siehe Abschnitt 8.1).

7.4. Denial of Service mit modifizierten Initial-Paketen​

Ein Angreifer könnte Initial-Pakete modifizieren, um eine ineffiziente Ressourcennutzung zu verursachen. Beispielsweise könnte ein Angreifer Initial-Pakete modifizieren, um die Größe der Handshake-Nachrichten zu erhöhen, was zur Verschwendung von Server-Ressourcen führt.

Server DÜRFEN NICHT (MUST NOT) Verbindungsstatus (Ressourcen zuweisen) aufrechterhalten, bis die Informationen des Clients erfolgreich authentifiziert wurden.

8. QUIC-spezifische Anpassungen des TLS-Handshakes (QUIC-Specific Adjustments to the TLS Handshake)​

Bei Verwendung mit QUIC sind einige Aspekte des TLS-Handshakes unterschiedlich.

QUIC erfordert auch, dass der kryptografische Handshake eine authentifizierte Aushandlung von Parametern bereitstellt, die sowohl für die Sicherheit als auch für die Leistung kritisch sind. Zusätzlich zur Aushandlung kryptografischer Parameter transportiert und validiert der TLS-Handshake auch die Werte der QUIC-Transportparameter.

8.1. Protokollaushandlung (Protocol Negotiation)​

QUIC erfordert, dass der kryptografische Handshake eine authentifizierte Protokollaushandlung bereitstellt. TLS verwendet Application-Layer Protocol Negotiation (ALPN) [ALPN], um ein Anwendungsprotokoll auszuwählen. Sofern nicht ein anderer Mechanismus verwendet wird, um ein Anwendungsprotokoll zu vereinbaren, müssen (MUST) Endpunkte ALPN zu diesem Zweck verwenden.

Bei Verwendung von ALPN müssen (MUST) Endpunkte die Verbindung sofort schließen (siehe Abschnitt 10.2 von [QUIC-TRANSPORT]) mit einem no_application_protocol TLS-Alert (QUIC-Fehlercode 0x0178; siehe Abschnitt 4.8), wenn kein Anwendungsprotokoll ausgehandelt wird. [ALPN] spezifiziert, dass nur Server diesen Alert verwenden, aber QUIC-Clients müssen (MUST) den Fehler 0x0178 verwenden, um eine Verbindung zu beenden, wenn die ALPN-Aushandlung fehlschlägt.

Ein Anwendungsprotokoll kann (MAY) die QUIC-Versionen einschränken, die verwendet werden können. Server müssen (MUST) ein Anwendungsprotokoll auswählen, das mit der vom Client ausgewählten QUIC-Version kompatibel ist. Der Server muss (MUST) die Unfähigkeit, ein kompatibles Anwendungsprotokoll auszuwählen, als Verbindungsfehler vom Typ 0x0178 (no_application_protocol) behandeln. Ebenso muss (MUST) ein Client die Auswahl eines inkompatiblen Anwendungsprotokolls durch den Server als Verbindungsfehler vom Typ 0x0178 behandeln.

8.2. QUIC-Transportparameter-Erweiterung (QUIC Transport Parameters Extension)​

QUIC-Transportparameter werden in einer TLS-Erweiterung transportiert. Verschiedene QUIC-Versionen können unterschiedliche Methoden zur Aushandlung der Transportkonfiguration definieren.

Die Einbeziehung von Transportparametern in den TLS-Handshake bietet Integritätsschutz für diese Werte.

enum {
   quic_transport_parameters(0x39), (65535)
} ExtensionType;

Das extension_data-Feld der quic_transport_parameters-Erweiterung enthält einen Wert, der durch die verwendete QUIC-Version definiert ist.

Die quic_transport_parameters-Erweiterung wird in den ClientHello- und EncryptedExtensions-Nachrichten während des Handshakes transportiert. Endpunkte müssen (MUST) die quic_transport_parameters-Erweiterung senden. Ein Endpunkt, der ein ClientHello oder EncryptedExtensions ohne die quic_transport_parameters-Erweiterung empfängt, muss (MUST) die Verbindung mit einem Fehler vom Typ 0x016d schließen (äquivalent zu einem TLS-Fatal-Alert missing_extension; siehe Abschnitt 4.8).

Transportparameter werden verfügbar, bevor der Handshake abgeschlossen ist. Ein Server kann diese Werte vor Abschluss des Handshakes verwenden. Allerdings sind die Transportparameterwerte erst nach Abschluss des Handshakes authentifiziert, daher kann jede Verwendung dieser Parameter nicht auf ihre Authentizität vertrauen. Die Manipulation von Transportparametern führt zum Scheitern des Handshakes.

Endpunkte dürfen nicht (MUST NOT) diese Erweiterung in einer TLS-Verbindung senden, die QUIC nicht verwendet (wie die Verwendung von TLS über TCP, die in [TLS13] definiert ist). Eine Implementierung, die diese Erweiterung unterstützt, muss (MUST) einen unsupported_extension Fatal Alert senden, wenn sie diese Erweiterung empfängt, wenn der Transport nicht QUIC ist.

Die Aushandlung der quic_transport_parameters-Erweiterung entfernt EndOfEarlyData (siehe Abschnitt 8.3).

8.3. Entfernung der EndOfEarlyData-Nachricht (Removing the EndOfEarlyData Message)​

Die TLS-EndOfEarlyData-Nachricht wird nicht mit QUIC verwendet. QUIC verlässt sich nicht auf diese Nachricht, um das Ende von 0-RTT-Daten zu markieren oder den Übergang zu Handshake-Schlüsseln zu signalisieren.

Clients dürfen nicht (MUST NOT) die EndOfEarlyData-Nachricht senden. Ein Server muss (MUST) den Empfang eines CRYPTO-Frames in einem 0-RTT-Datenpaket als Verbindungsfehler vom Typ PROTOCOL_VIOLATION behandeln.

Infolgedessen erscheint EndOfEarlyData nicht im TLS-Handshake-Transkript.

8.4. Verbot des TLS-Middlebox-Kompatibilitätsmodus (Prohibiting TLS Middlebox Compatibility Mode)​

Anhang D.4 von [TLS13] beschreibt eine Änderung am TLS 1.3-Handshake als Workaround für Bugs in einigen Middleboxes. Der TLS 1.3-Middlebox-Kompatibilitätsmodus beinhaltet das Setzen des legacy_session_id-Feldes in ClientHello und ServerHello auf einen 32-Byte-Wert und das Senden eines change_cipher_spec-Datensatzes. Weder das Feld noch der Datensatz tragen semantischen Inhalt und werden ignoriert.

Dieser Modus ist in QUIC nicht nützlich, da er nur auf Middleboxes anwendbar ist, die mit TLS über TCP interferieren. QUIC bietet nicht einmal ein Mittel zum Transport von change_cipher_spec-Datensätzen. Clients dürfen nicht (MUST NOT) die Verwendung des TLS 1.3-Kompatibilitätsmodus anfordern. Ein Server sollte (SHOULD) den Empfang eines TLS ClientHello mit einem nicht-leeren legacy_session_id-Feld als Verbindungsfehler vom Typ PROTOCOL_VIOLATION behandeln.

9. Sicherheitsüberlegungen (Security Considerations)​

Alle Sicherheitsüberlegungen, die für TLS gelten, gelten auch für die Verwendung von TLS in QUIC. Das Lesen der gesamten [TLS13] und ihrer Anhänge ist der beste Weg, um die Sicherheitseigenschaften von QUIC zu verstehen.

Dieser Abschnitt fasst einige der wichtigsten sicherheitsrelevanten Aspekte zusammen, die spezifisch für die TLS-Integration sind, obwohl es viele sicherheitsrelevante Details im Rest des Dokuments gibt.

9.1. Sitzungsverknüpfbarkeit (Session Linkability)​

Die Verwendung von TLS-Sitzungstickets ermöglicht es Servern und möglicherweise anderen Entitäten, von demselben Client hergestellte Verbindungen zu korrelieren; siehe Abschnitt 4.5 für weitere Details.

9.2. Replay-Angriffe mit 0-RTT (Replay Attacks with 0-RTT)​

Wie in Abschnitt 8 von [TLS13] beschrieben, ist die Verwendung von TLS-Frühdaten mit einer Exposition gegenüber Replay-Angriffen verbunden. Die Verwendung von 0-RTT in QUIC ist ebenfalls anfällig für Replay-Angriffe.

Endpunkte MÜSSEN (MUST) die in [TLS13] beschriebenen Replay-Schutzmaßnahmen implementieren und verwenden, aber es wird anerkannt, dass diese Schutzmaßnahmen unvollkommen sind. Daher ist eine zusätzliche Berücksichtigung des Replay-Risikos erforderlich.

QUIC ist nicht anfällig für Replay-Angriffe, außer über die Anwendungsprotokollinformationen, die es möglicherweise trägt. Die Verwaltung des QUIC-Protokollstatus basierend auf den in [QUIC-TRANSPORT] definierten Frame-Typen ist nicht anfällig für Replay.

Die vollständige Deaktivierung von 0-RTT ist die effektivste Verteidigung gegen Replay-Angriffe.

QUIC-Erweiterungen MÜSSEN (MUST) beschreiben, wie Replay-Angriffe ihre Funktionsweise beeinflussen, oder die Verwendung der Erweiterung in 0-RTT verbieten. Anwendungsprotokolle MÜSSEN (MUST) entweder die Verwendung von Erweiterungen mit Anwendungssemantik in 0-RTT verbieten oder Replay-Minderungsstrategien bereitstellen.

9.3. Minderung von Paket-Reflexionsangriffen​

Ein kleines ClientHello, das zu einem großen Block von Handshake-Nachrichten von einem Server führt, kann in Paket-Reflexionsangriffen verwendet werden, um den von einem Angreifer generierten Datenverkehr zu verstärken.

QUIC umfasst drei Verteidigungen gegen diesen Angriff. Erstens MUSS (MUST) das Paket, das ein ClientHello enthält, auf eine Mindestgröße aufgefüllt werden. Zweitens ist es dem Server verboten, mehr als das Dreifache der Anzahl der Bytes zu senden, die er erhalten hat, wenn er auf eine nicht verifizierte Quelladresse antwortet (siehe Abschnitt 8.1 von [QUIC-TRANSPORT]). Schließlich können Bestätigungen von Handshake-Paketen authentifiziert werden, sodass ein blinder Angreifer sie nicht fälschen kann. Zusammen begrenzen diese Verteidigungen das Verstärkungsniveau.

9.4. Schlüsseldiversität (Key Diversity)​

Bei Verwendung von TLS wird der zentrale TLS-Schlüsselzeitplan verwendet. Als Folge der Integration der TLS-Handshake-Nachrichten in die Berechnung der Geheimnisse stellt die Einbeziehung der QUIC-Transportparameter-Erweiterung sicher, dass die Handshake- und 1-RTT-Schlüssel nicht dieselben sind, die von einem Server erzeugt werden könnten, der TLS über TCP ausführt.

QUIC-Paketschutzschlüssel und IVs werden mit einem anderen Label als den äquivalenten Schlüsseln in TLS abgeleitet.

Um diese Trennung zu bewahren, SOLLTE (SHOULD) eine neue QUIC-Version neue Labels für die Schlüsselableitung für den Paketschutzschlüssel und IV sowie die Header-Schutzschlüssel definieren. Diese Version von QUIC verwendet die Zeichenfolge "quic". Andere Versionen können stattdessen ein versionsspezifisches Label verwenden.

9.5. Timing-Seitenkanäle des Header-Schutzes​

Ein Angreifer könnte Werte für Paketnummern oder Schlüsselphase erraten und den Endpunkt auffordern, die Vermutungen über Timing-Seitenkanäle zu bestätigen.

Damit die Authentifizierung frei von Seitenkanälen ist, MUSS (MUST) der gesamte Prozess der Entfernung des Header-Schutzes, der Wiederherstellung der Paketnummer und der Entfernung des Paketschutzes zusammen ohne Timing- oder andere Seitenkanäle angewendet werden.

9.6. Zufälligkeit (Randomness)​

QUIC hängt von der Fähigkeit der Endpunkte ab, sichere Zufallszahlen zu generieren, sowohl direkt für Protokollwerte wie Verbindungs-IDs als auch transitiv über TLS. Siehe [RFC4086] für Hinweise zur Generierung sicherer Zufallszahlen.

10. IANA-Überlegungen (IANA Considerations)​

Die IANA hat einen Codepunkt von 57 (oder 0x39) für die quic_transport_parameters-Erweiterung (definiert in Abschnitt 8.2) im Register "TLS ExtensionType Values" [TLS-REGISTRIES] registriert.

Die Spalte "Empfohlen" für diese Erweiterung ist mit Ja markiert. Die Spalte "TLS 1.3" enthält CH (ClientHello) und EE (EncryptedExtensions).

WertErweiterungsnameTLS 1.3EmpfohlenReferenz
57quic_transport_parametersCH, EEJDieses Dokument

Tabelle 2: TLS ExtensionType Values Registereintrag

11. Referenzen (References)​

11.1. Normative Referenzen (Normative References)​

Dieser Abschnitt enthält die normativen Referenzen, die in RFC 9001 zitiert werden. Für die vollständige Liste konsultieren Sie bitte den englischen Originaltext.

Hauptreferenzen:

  • [TLS13] - RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
  • [QUIC-TRANSPORT] - RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport
  • [QUIC-RECOVERY] - RFC 9002: QUIC Loss Detection and Congestion Control
  • [RFC2119] - RFC 2119: Key words for use in RFCs to Indicate Requirement Levels
  • [RFC8174] - RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words

11.2. Informative Referenzen (Informative References)​

Dieser Abschnitt enthält die informativen Referenzen, die in RFC 9001 zitiert werden.

Hauptreferenzen:

  • [AEBounds] - Limits on Authenticated Encryption Use in TLS
  • [ALPN] - RFC 7301: Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension
  • [QUIC-HTTP] - RFC 9114: HTTP/3
  • [NAN] - Nonces Are Noticed: AEAD Revisited

Für die vollständige Liste der Referenzen konsultieren Sie bitte das offizielle RFC 9001: https://www.rfc-editor.org/rfc/rfc9001.html

Anhang A. Beispiel für Paketschutz (Sample Packet Protection)​

Dieser Anhang zeigt Beispiele für den Paketschutzprozess. Die Beispiele zeigen einen Handshake, der ein Initial-Paket vom Client und ein Initial-Paket vom Server enthält, gefolgt von Handshake-Paketen vom Client und Server.

A.1. Schlüssel (Keys)​

Die in diesen Beispielen berechneten Secrets und Schlüssel werden mit Werten in Hexadezimal angezeigt.

A.2. Client-Initial-Paket (Client Initial)​

Der Client sendet ein Initial-Paket. Die Secrets und Schlüssel zum Schutz dieses Pakets werden aus der Destination Connection ID 0x8394c8f03e515708 abgeleitet.

initial_salt = 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a

initial_secret = HKDF-Extract(initial_salt, client_dst_connection_id)
               = 0x7db5df06e7a69e432496adedb00851923595221596ae2ae9fb8115c1e9ed0a44

client_initial_secret
    = HKDF-Expand-Label(initial_secret,
                       "client in", "",
                       Hash.length)
    = 0x00553221e68c7e38be14fa1ab2e9def61c0ca9f9a9e0e4ad5f8b3c2d4c76c7ee

server_initial_secret
    = HKDF-Expand-Label(initial_secret,
                       "server in", "",
                       Hash.length)
    = 0x0018b6cbcf39d62e84bd8e9ab8bc3e1b8c8b18d9c3c3e2d0e1af3e0d6c5c4c3c

Das vom Client gesendete Paket ist:

c300000001088394c8f03e5157080000449e00000002

Die Secrets werden dann erweitert, um die Verschlüsselungsschlüssel und IVs abzuleiten, die Initial-Pakete schützen.

A.3. Server-Initial-Paket (Server Initial)​

Der Server sendet das folgende Initial-Paket als Antwort:

c1000000010800000449e7d0c5db0e

A.4. Client-Handshake-Pakete (Client Handshake)​

Nach Empfang des Server-Initial-Pakets leitet der Client neue Paketschutzschlüssel für die Handshake-Verschlüsselungsebene ab.

A.5. Server-Handshake-Pakete (Server Handshake)​

Der Server sendet dann Handshake-Daten, die mit Handshake-Ebenen-Schlüsseln verschlüsselt sind.

Hinweis: Die vollständigen Beispiele mit allen Zwischenwerten und detaillierten kryptografischen Berechnungen sind im Originaltext von RFC 9001, Anhang A verfügbar.

Anhang B. AEAD-Algorithmusanalyse (AEAD Algorithm Analysis)​

Dieser Anhang enthält eine Analyse der Nutzungsgrenzen der in QUIC verwendeten AEAD-Algorithmen. Diese Analyse wurde verwendet, um die in Abschnitt 6.6 dokumentierten Grenzen abzuleiten.

B.1. AES-GCM-Analyse (AES-GCM Analysis)​

Der Galois/Counter Mode (GCM) von AES bietet sowohl Vertraulichkeit als auch Integrität. Die Analyse in [AEBounds] stellt fest, dass der zugrunde liegende AES-Algorithmus gegen gewählte Klartextangriffe sicher ist.

Die Analyse stellt fest, dass der maximale Informationsleck begrenzt ist durch:

(ℓ × q)² / 2^129

wobei:

  • ℓ die maximale Länge des Chiffretextes in 128-Bit-Blöcken ist
  • q die Anzahl der Chiffretexte ist

AES-128-GCM​

Für AEAD_AES_128_GCM wird die Vertraulichkeitsgrenze wie folgt berechnet:

Vertraulichkeitsgrenze: 2^23 Pakete

Diese Grenze wird unter der Annahme einer maximalen Paketgröße von 2^11 Bytes (2048 Bytes) abgeleitet, was eine maximale Länge von 2^7 Blöcken pro Paket ergibt.

Integritätsgrenze: 2^52 fehlgeschlagene Authentifizierungsversuche

Diese Grenze stellt sicher, dass die Wahrscheinlichkeit, dass ein Angreifer erfolgreich ein Paket fälscht, vernachlässigbar bleibt.

AES-256-GCM​

Für AEAD_AES_256_GCM sind die Grenzen ähnlich wie bei AES-128-GCM, da die Eigenschaften von GCM unabhängig von der AES-Schlüsselgröße sind:

Vertraulichkeitsgrenze: 2^23 Pakete
Integritätsgrenze: 2^52 Authentifizierungsversuche

B.2. ChaCha20-Poly1305-Analyse (ChaCha20-Poly1305 Analysis)​

ChaCha20-Poly1305 kombiniert die ChaCha20-Stream-Verschlüsselung mit dem Poly1305-Authentifikator. Die Analyse in [NAN] und die Sicherheitsüberlegungen in [RFC8439] legen die folgenden Grenzen fest.

Vertraulichkeitsgrenze: 2^23 Pakete

Das Risiko einer Nonce-Kollision wird nach dieser Anzahl von Paketen signifikant.

Integritätsgrenze: 2^36 Fälschungsversuche

Diese Grenze ist konservativer als die von AES-GCM aufgrund der unterschiedlichen Eigenschaften von Poly1305.

B.3. AES-CCM-Analyse (AES-CCM Analysis)​

Counter with CBC-MAC (CCM) ist ein Betriebsmodus für AES, der den Counter-Modus (CTR) für Verschlüsselung mit CBC-MAC für Authentifizierung kombiniert.

AES-128-CCM​

Für AEAD_AES_128_CCM werden die Grenzen aus [CCM-ANALYSIS] abgeleitet:

Vertraulichkeitsgrenze: 2^21.5 Pakete (ungefähr 2,9 Millionen Pakete)

Diese restriktivere Grenze spiegelt die Einschränkungen des CCM-Modus wider.

Integritätsgrenze: 2^23.5 Authentifizierungsversuche (ungefähr 11,8 Millionen Versuche)

B.4. Zusammenfassung der Grenzen (Summary of Limits)​

Die folgende Tabelle fasst die Grenzen für alle unterstützten AEAD-Algorithmen zusammen:

AEAD-AlgorithmusVertraulichkeitsgrenzeIntegritätsgrenze
AEAD_AES_128_GCM2^23 Pakete2^52 Versuche
AEAD_AES_256_GCM2^23 Pakete2^52 Versuche
AEAD_CHACHA20_POLY13052^23 Pakete2^36 Versuche
AEAD_AES_128_CCM2^21.5 Pakete2^23.5 Versuche

Tabelle B.1: AEAD-Nutzungsgrenzen

B.5. Implikationen für Implementierungen​

Implementierungen MÜSSEN (MUST) diese Grenzen bei Verwendung dieser Algorithmen mit QUIC befolgen. Wenn eine Grenze erreicht wird:

  1. Für die Vertraulichkeitsgrenze: Eine Schlüsselaktualisierung initiieren (siehe Abschnitt 6), bevor die Grenze erreicht wird
  2. Für die Integritätsgrenze: Alle fehlgeschlagenen Entschlüsselungsversuche zählen und die Verbindung schließen, wenn die Grenze erreicht wird

Referenzen für diesen Anhang:

  • [AEBounds]: Limits on Authenticated Encryption Use in TLS
  • [NAN]: Nonces Are Noticed: AEAD Revisited
  • [RFC8439]: ChaCha20 and Poly1305 for IETF Protocols
  • [CCM-ANALYSIS]: Analytical studies of CCM mode