Zum Hauptinhalt springen

7. Kryptografischer und Transport-Handshake

7. Kryptografischer und Transport-Handshake

QUIC basiert auf einem kombinierten kryptografischen und Transport-Handshake, um die Latenz beim Verbindungsaufbau zu minimieren. QUIC verwendet den CRYPTO-Frame (Abschnitt 19.6), um den kryptografischen Handshake zu übertragen. Version 1 von QUIC verwendet TLS 1.3 wie in [QUIC-TLS] beschrieben; eine andere QUIC-Version könnte ein anderes kryptografisches Handshake-Protokoll verwenden.

QUIC bietet zuverlässige, geordnete Zustellung der kryptografischen Handshake-Daten. Der QUIC-Paketschutz wird verwendet, um so viel wie möglich vom Handshake-Protokoll zu verschlüsseln. Der kryptografische Handshake MUSS die folgenden Eigenschaften bieten:

  • authentifizierter Schlüsselaustausch, wobei

    • ein Server immer authentifiziert ist,
    • ein Client optional authentifiziert ist,
    • jede Verbindung unterschiedliche und nicht verwandte Schlüssel erzeugt,
    • Schlüsselmaterial für den Paketschutz sowohl für 0-RTT- als auch für 1-RTT-Pakete verwendet werden kann, und
    • 1-RTT-Schlüssel Forward Secrecy haben
  • authentifizierter Austausch von Werten für Transportparameter beider Endpunkte und Vertraulichkeitsschutz für Server-Transportparameter (siehe Abschnitt 7.4)

  • authentifizierte Aushandlung eines Anwendungsprotokolls (TLS verwendet ALPN [ALPN] für diesen Zweck)

Der CRYPTO-Frame kann in verschiedenen Paketnummernräumen gesendet werden (Abschnitt 12.3). Die von CRYPTO-Frames verwendeten Offsets zur Gewährleistung der geordneten Zustellung kryptografischer Handshake-Daten beginnen in jedem Paketnummernraum bei Null.

[QUIC-TLS] beschreibt, wie TLS 1.3 mit QUIC verwendet wird.

7.1 Beispiel-Handshake-Abläufe

Details zur Integration von TLS mit QUIC werden in [QUIC-TLS] bereitgestellt, aber einige Beispiele zur Verwendung des Handshakes werden hier gegeben.

7.2 Aushandlung von Verbindungs-IDs

Eine Verbindungs-ID wird verwendet, um ein konsistentes Routing von Paketen sicherzustellen. Der Long-Header enthält zwei Verbindungs-IDs: Die Destination Connection ID wird vom Empfänger des Pakets gewählt und wird verwendet, um konsistentes Routing bereitzustellen; die Source Connection ID wird verwendet, um die vom Peer verwendete Destination Connection ID festzulegen.

7.3 Authentifizierung von Verbindungs-IDs

Die Wahl, die jeder Endpunkt während des Handshakes über Verbindungs-IDs trifft, wird authentifiziert, indem alle gesendeten Werte in Transportparametern enthalten sind; siehe Abschnitt 7.4.

7.4 Transportparameter

Während des Verbindungsaufbaus geben beide Endpunkte authentifizierte Erklärungen ihrer Transportparameter ab. Endpunkte MÜSSEN die durch diese Parameter implizierten Einschränkungen einhalten; die Beschreibung jedes Parameters enthält Regeln für seine Handhabung.

7.5 Pufferung kryptografischer Nachrichten

Implementierungen müssen einen Puffer von CRYPTO-Daten pflegen, die außerhalb der Reihenfolge empfangen wurden.