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.