Aller au contenu principal

7. Cryptographic and Transport Handshake

7. Cryptographic and Transport Handshake

QUIC relies on a combined cryptographic and transport handshake to minimize connection establishment latency. QUIC uses the CRYPTO frame (Section 19.6) to transmit the cryptographic handshake. Version 1 of QUIC uses TLS 1.3 as described in [QUIC-TLS]; a different QUIC version could use a different cryptographic handshake protocol.

QUIC provides reliable, ordered delivery of the cryptographic handshake data. QUIC packet protection is used to encrypt as much of the handshake protocol as possible. The cryptographic handshake MUST provide the following properties:

  • authenticated key exchange, where

    • a server is always authenticated,
    • a client is optionally authenticated,
    • every connection produces distinct and unrelated keys,
    • keying material is usable for packet protection for both 0-RTT and 1-RTT packets, and
    • 1-RTT keys have forward secrecy
  • authenticated exchange of values for transport parameters of both endpoints, and confidentiality protection for server transport parameters (see Section 7.4)

  • authenticated negotiation of an application protocol (TLS uses ALPN [ALPN] for this purpose)

The CRYPTO frame can be sent in different packet number spaces (Section 12.3). The offsets used by CRYPTO frames to ensure ordered delivery of cryptographic handshake data start from zero in each packet number space.

[QUIC-TLS] describes how TLS 1.3 is used with QUIC.

7.1 Example Handshake Flows

Details of how TLS is integrated with QUIC are provided in [QUIC-TLS], but some examples of how the handshake is used are provided here.

7.2 Negotiating Connection IDs

A connection ID is used to ensure consistent routing of packets. The long header contains two connection IDs: the Destination Connection ID is chosen by the recipient of the packet and is used to provide consistent routing; the Source Connection ID is used to set the Destination Connection ID used by the peer.

7.3 Authenticating Connection IDs

The choice each endpoint makes about connection IDs during the handshake is authenticated by including all values sent in transport parameters; see Section 7.4.

7.4 Transport Parameters

During connection establishment, both endpoints make authenticated declarations of their transport parameters. Endpoints MUST comply with the restrictions implied by these parameters; the description of each parameter includes rules for its handling.

7.5 Cryptographic Message Buffering

Implementations need to maintain a buffer of CRYPTO data received out of order.