Zum Hauptinhalt springen

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.

Letztes Update am