From e38cb12dffcec6dd538bead5ca5a1fe10954e490 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 4 Jan 2017 20:24:02 +1100 Subject: [PATCH 01/11] Add definition of transport parameters to -transport --- draft-ietf-quic-transport.md | 246 ++++++++++++++++++++++++++++------- 1 file changed, 201 insertions(+), 45 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 760091fac7..cf2ff637f4 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -666,64 +666,226 @@ Version negotiation uses unprotected data. The result of the negotiation MUST be revalidated once the cryptographic handshake has completed (see {{version-validation}}). + ## Crypto and Transport Handshake {#handshake} QUIC relies on a combined crypto and transport handshake to minimize connection -establishment latency. QUIC provides a dedicated stream (Stream ID 1) to be -used for performing a combined connection and security handshake (streams are -described in detail in {{streams}}). The crypto handshake protocol encapsulates -and delivers QUIC's transport handshake to the peer on the crypto stream. The -first QUIC packet from the client to the server MUST carry handshake information -as data on Stream ID 1. +establishment latency. QUIC allocates stream 1 for the cryptographic handshake, +which uses TLS. + +QUIC provides this stream with reliable, ordered delivery of data. In return, +TLS provides QUIC with: + +* authenticated key exchange, always for the server, optionally for the client + +* keying material for use in packet packet protection + +* authenticated values for the transport parameters of the peer (see + {{transport-parameters}}) + +* authenticated confirmation of version negotiation (see {{version-validation}}) + +* authenticated negotiation of an application protocol (TLS uses ALPN + {{?RFC7301}} for this purpose) + +* for the server, assurance that the client can receive packets that are + addressed with the transport address that is claimed by the client (see + {{source-address-token}}) + +Details of how TLS is integrated with QUIC is provided in more detail in +{{QUIC-TLS}}. + + +## Transport Parameters + +During connection establishment, both endpoints make authenticated declarations +of their transport parameters. These declarations are made unilaterally by each +endpoint. Endpoints are required to comply with the restrictions implied by +these parameters; the description of each parameter includes rules for its +handling. -### Transport Parameters and Options +The format of the transport parameters is the TransportParameters struct from +{{figure-transport-parameters}}. This is described using the presentation +language from Section 3 of {{!I-D.ietf-tls-tls13}}. -During connection establishment, the handshake must negotiate various transport -parameters. The currently defined transport parameters are described later in -the document. +~~~ + uint32 QuicVersion; + + enum { + SFCW(0), + CFCW(1), + MSPC(2), + ICSL(3), + TCID(4), + COPT(5), + (65535) + } TransportParameterId; + + struct { + TransportParameterId parameter; + opaque value<0..2^16-1>; + } TransportParameter; + + struct { + select (Handshake.msg_type) { + case client_hello: + QuicVersion negotiated_version; + QuicVersion initial_version; + + case encrypted_extensions: + QuicVersion supported_versions<2..2^8-4>; + }; + TransportParameter parameters<30..2^16-1>; + } TransportParameters; +~~~ +{: #figure-transport-parameters title="Definition of TransportParameters"} + +The "extension_data" field of the quic_transport_parameters extension defined in +{{QUIC-TLS}} contains a TransportParameters value. TLS encoding rules are +therefore used to encode the transport parameters. + +Definitions for each of the defined transport parameters are included in +{{transport-parameter-definitions}}. Use of the version fields from transport +parameters is described in {{version-validation}}. + + +### Transport Parameter Definitions + +An endpoint MUST include the following parameters in its encoded +TransportParameters: -The transport component of the handshake is responsible for exchanging and -negotiating the following parameters for a QUIC connection. Not all parameters -are negotiated, some are parameters sent in just one direction. These -parameters and options are encoded and handed off to the crypto handshake -protocol to be transmitted to the peer. +SFCW (0x0000): -#### Encoding +: The initial stream level flow control parameter is encoded as an unsigned + 32-bit integer. The sender of this parameter indicates that the flow control + offset for all stream data sent toward it is this value. -(TODO: Describe format with example) +CFCW (0x0001): -QUIC encodes the transport parameters and options as tag-value pairs, all as -7-bit ASCII strings. QUIC parameter tags are listed below. +: The connection level flow control parameter contains the initial connection + flow control window encoded as an unsigned 32-bit integer. The sender of this + parameter sets the byte offset for connection level flow control to this + value. This is equivalent to sending a WINDOW_UPDATE ({{frame-window-update}} + for stream 0 immediately after completing the handshake. -#### Required Transport Parameters {#required-transport-parameters} +MSPC (0x0002): -* SFCW: Stream Flow Control Window. The stream level flow control - byte offset advertised by the sender of this parameter. +: The maximum number of concurrent streams parameter is encoded as an unsigned + 32-bit integer. -* CFCW: Connection Flow Control Window. The connection level flow - control byte offset advertised by the sender of this parameter. +ICSL (0x0003): -* MSPC: Maximum number of incoming streams per connection. +: The idle timeout is a value in seconds that is encoded as an unsigned 16-bit + integer. The maximum value is 600 seconds (10 minutes). -* ICSL: Idle timeout in seconds. The maximum value is 600 seconds (10 minutes). +An endpoint MAY use the following transport parameters: -#### Optional Transport Parameters +TCID (0x0004): -* TCID: Indicates support for truncated Connection IDs. If sent by a peer, - indicates that connection IDs sent to the peer should be truncated to 0 bytes. - This is expected to commonly be used by an endpoint where the 5-tuple is - sufficient to identify a connection. For instance, if the 5-tuple is unique - at the client, the client MAY send a TCID parameter to the server. When a - TCID parameter is received, an endpoint MAY choose to not send the connection - ID on subsequent packets. +: The truncated connection identifier parameter indicates that packets sent to + the peer can omit the connection ID. This can be used by an endpoint where + the 5-tuple is sufficient to identify a connection. This parameter is zero + length. -* COPT: Connection Options are a repeated tag field. The field contains any +COPT (0x0005): + +: Connection options are a repeated parameter. The parameter contains any connection options being requested by the client or server. These are typically used for experimentation and will evolve over time. Example use cases include changing congestion control algorithms and parameters such as initial window. (TODO: List connection options.) -### Proof of Source Address Ownership +### Values of Transport Parameters for 0-RTT + +Transport parameters from the server are remembered by the client for 0-RTT +connections. If values change as a result of completing the handshake, the +client is expected to respect the new values. This introduces some potential +problems, particularly with respect to transport parameters that establish +limits: + +* A client might exceed a newly declared connection or stream flow control limit + with 0-RTT data. If this occurs, the client ceases transmission as though the + flow control limit was reached. Once WINDOW_UPDATE frames indicating an + increase to the affected flow control offsets is received, the client can + recommence sending. + +* Similarly, a client might exceed the concurrent stream limit declared by the + server. A client MUST reset any streams that exceed this connection. A + server MAY reset these streams. + +A client cannot use or rely upon any other transport parameter that was enabled +in a previous connection. This includes those defined in this document. A +client MUST assume that the transport parameter was absent, unless the +definition of a transport parameter provides explicit rules for use of the +option in 0-RTT. + + +### New Transport Parameters + +An endpoint MUST ignore transport parameters that it does not support. + +The definition of new transport parameters can be used to negotiate new protocol +behavior. Endpoints that support features that deviate from this specification +MUST assume that a peer will operate as described in this document unless it +provides an explicit signal of support. A new transport parameter could be used +to provide this signal. + +New transport parameters can be registered according to the rules in +{{iana-transport-parameters}}. + + +### Version Negotiation Validation {#version-validation} + +The transport parameters include three fields that encode version information. +These retroactively authenticate the version negotiation (see +{{version-negotiation}}) that is performed prior to the cryptographic handshake. + +Inclusion of these values in an extension provides integrity protection for +these values. As a result, modification of version negotiation packets by an +attacker can be detected. + +The client includes two fields in the transport parameters that it includes in +the TLS ClientHello: + +* The negotiated_version is the version that was finally selected for use. This + MUST be identical to the value that is on the packet that carries the + ClientHello. A server that receives a negotiated_version that does not match + the version of QUIC that is in use MUST terminate the connection with a TBD + error code. + +* The initial_version is the version that the client initially attempted to use. + If the server did not send a version negotiation packet + {{version-negotiation-packet}}, this will be identical to the + negotiated_version. + +A stateful server can remember how version negotiation was performed and +validate the initial_version value. + +A server that does not maintain state for early packets uses a different +process. If the initial and negotiated versions are the same, a stateless server +can accept the value. + +If the initial version is different from the negotiated_version, a stateless +server MUST validate the value. A server MUST check that it would have sent a +version negotiation packet if it had received a packet with the indicated +initial_version. If a server would have accepted the version included in the +initial_version and the value differs from the value of negotiated_version, the +server MUST terminate the connection with a TBD error code. + +The server includes a list of versions that it would send in any version +negotiation packet ({{version-negotiation-packet}}) in supported_versions. This +value is set even if it did not send a version negotiation packet. + +The client can validate that the negotiated_version is included in the +supported_versions list and - if version negotiation was performed - that it +would have selected the negotiated version. A client MUST terminate the +connection with a TBD error code if the negotiated_version value is not included +in the supported_versions list. A client MUST terminate with a TBD error code +if version negotiation occurred but it would have selected a different version +based on the value of the supported_versions list. + + +### Proof of Source Address Ownership {#source-address-token} Transport protocols commonly use a roundtrip time to verify a client's address ownership for protection from malicious clients that spoof their source address. @@ -748,8 +910,11 @@ client in the STK. (TODO: Describe server and client actions on STK, encoding, recommendations for what to put in an STK. Describe SCUP messages.) + ### Crypto Handshake Protocol Features +(TODO: Remove or migrate this section.) + QUIC's current crypto handshake mechanism is documented in {{QUICCrypto}}. QUIC does not restrict itself to using a specific handshake protocol, so the details of a specific handshake protocol are out of this document's scope. If not @@ -792,15 +957,6 @@ protocol. minimize the number of packets sent during a handshake. -### Version Negotiation Validation {#version-validation} - -The following information used during the QUIC handshake MUST be -cryptographically verified by the crypto handshake protocol: - -* Client's originally proposed version in its first packet. - -* Server's version list in it's Version Negotiation packet, if one was sent. - ## Connection Migration {#migration} From ca8b82f824c97b29e3acf6411476b6f0099a0df6 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 4 Jan 2017 21:36:16 +1100 Subject: [PATCH 02/11] Define the extension in -tls --- draft-ietf-quic-tls.md | 54 +++++++++++++++++++----------------- draft-ietf-quic-transport.md | 2 +- 2 files changed, 29 insertions(+), 27 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 7088aca711..55d38e17ad 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -84,13 +84,11 @@ QUIC. --- note_Note_to_Readers -Discussion of this draft takes place on the QUIC working group mailing list -(quic@ietf.org), which is archived at -. +Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), +which is archived at . -Working Group information can be found at ; source -code and issues list for this draft can be found at -. +Working Group information can be found at ; source code and issues list +for this draft can be found at . --- middle @@ -1106,31 +1104,35 @@ protection for the QUIC negotiation. This does not prevent version downgrade during the handshake, though it means that such a downgrade causes a handshake failure. -Protocols that use the QUIC transport MUST use Application Layer Protocol -Negotiation (ALPN) {{!RFC7301}}. The ALPN identifier for the protocol MUST be -specific to the QUIC version that it operates over. When constructing a -ClientHello, clients MUST include a list of all the ALPN identifiers that they -support, regardless of whether the QUIC version that they have currently -selected supports that protocol. +TLS uses Application Layer Protocol Negotiation (ALPN) {{!RFC7301}} to select an +application protocol. The application-layer protocol MAY restrict the QUIC +versions that it can operate over. Servers MUST select an application protocol +compatible with the QUIC version that the client has selected. -Servers SHOULD select an application protocol based solely on the information in -the ClientHello, not using the QUIC version that the client has selected. If -the protocol that is selected is not supported with the QUIC version that is in -use, the server MAY send a QUIC version negotiation packet to select a -compatible version. +If the server cannot select a compatible combination of application protocol and +QUIC version, it MUST abort the connection. A client MUST abort a connection if +the server picks an incompatible combination of QUIC version and ALPN +identifier. -If the server cannot select a combination of ALPN identifier and QUIC version it -MUST abort the connection. A client MUST abort a connection if the server picks -an incompatible version of QUIC version and ALPN. +## QUIC Transport Parameters Extension {#quic_parameters} -## QUIC Extension {#quic_parameters} +QUIC transport parameters are carried in a TLS extension. Different versions of +QUIC might define a different format for this struct. -QUIC defines an extension for use with TLS. That extension defines -transport-related parameters. This provides integrity protection for these -values. Including these in the TLS handshake also make the values that a client -sets available to a server one-round trip earlier than parameters that are -carried in QUIC packets. This document does not define that extension. +Including transport parameters in the TLS handshake provides integrity +protection for these values. + +~~~ + enum { + quic_transport_parameters(26), (65535) + } ExtensionType; +~~~ + +The `extension_data` field of the quic_transport_parameters extension contains a +value that is defined by the version of QUIC that is in use. The +quic_transport_parameters extension carries a TransportParameters when the +version of QUIC defined in {{QUIC-TRANSPORT}} is used. ## Source Address Validation {#source-address} diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index cf2ff637f4..c8efa4900b 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -740,7 +740,7 @@ language from Section 3 of {{!I-D.ietf-tls-tls13}}. ~~~ {: #figure-transport-parameters title="Definition of TransportParameters"} -The "extension_data" field of the quic_transport_parameters extension defined in +The `extension_data` field of the quic_transport_parameters extension defined in {{QUIC-TLS}} contains a TransportParameters value. TLS encoding rules are therefore used to encode the transport parameters. From 03ee50ed7c2eb7a82c169476e0e308e2c10d04b8 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 4 Jan 2017 21:39:24 +1100 Subject: [PATCH 03/11] Add a stub iana section, fix dead references --- draft-ietf-quic-transport.md | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index c8efa4900b..ae22c6d1c4 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -765,7 +765,7 @@ CFCW (0x0001): : The connection level flow control parameter contains the initial connection flow control window encoded as an unsigned 32-bit integer. The sender of this parameter sets the byte offset for connection level flow control to this - value. This is equivalent to sending a WINDOW_UPDATE ({{frame-window-update}} + value. This is equivalent to sending a WINDOW_UPDATE (TODO: section ref) for stream 0 immediately after completing the handshake. MSPC (0x0002): @@ -1691,13 +1691,12 @@ connection. ## Stream Concurrency -An endpoint can limit the number of concurrently active incoming streams by -setting the MSPC parameter (see {{required-transport-parameters}}) in the -transport parameters. The maximum concurrent streams setting is specific to each -endpoint and applies only to the peer that receives the setting. That is, -clients specify the maximum number of concurrent streams the server can -initiate, and servers specify the maximum number of concurrent streams the -client can initiate. +An endpoint limits the number of concurrently active incoming streams by setting +the MSPC parameter (see {{transport-parameter-definitions}}) in the transport +parameters. The maximum concurrent streams setting is specific to each endpoint +and applies only to the peer that receives the setting. That is, clients specify +the maximum number of concurrent streams the server can initiate, and servers +specify the maximum number of concurrent streams the client can initiate. Streams that are in the "open" state or in either of the "half-closed" states count toward the maximum number of streams that an endpoint is permitted to @@ -2053,6 +2052,11 @@ be able to generate forward-secure encrypted ack packets. This document has no IANA actions yet. +## QUIC Transport Parameter Registry {#iana-transport-parameters} + +TODO: establish a registry for transport parameter identifiers. Steal from TLS. + + --- back # Contributors From e03d04f6ae047dd4373e6472835b86dbc6fcaffe Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 6 Jan 2017 14:15:27 +1300 Subject: [PATCH 04/11] are are are --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index ae22c6d1c4..0cd42229b9 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -416,7 +416,7 @@ implementations have to assume that a version that it does not support uses a different packet format. Between different versions the following things are guaranteed to remain -constant are: +constant: * the location and size of the Flags field, From 5a2f0792d8e755504f5276048abbfde837820bd8 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 6 Jan 2017 16:16:28 +1300 Subject: [PATCH 05/11] Jana's comments --- draft-ietf-quic-transport.md | 38 +++++++++++++++++++----------------- 1 file changed, 20 insertions(+), 18 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 0cd42229b9..5fcf4f6952 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -411,8 +411,7 @@ have the VERSION bit set. This bit is always set on packets that are sent prior to connection establishment. When receiving a packet that is not associated with an existing connection, packets without a VERSION bit MUST be discarded. -While there might be similarities between different versions of this protocol, -implementations have to assume that a version that it does not support uses a +Implementations have to assume that a version that it does not support uses a different packet format. Between different versions the following things are guaranteed to remain @@ -644,7 +643,7 @@ list of versions that the server will accept. A server MUST send a version negotiation packet for every packet that it receives with an unacceptable version. -If the packet contains a version that is acceptable to the server, the server +If the version selected by the client is acceptable to the server, the server proceeds with the handshake ({{handshake}}). All subsequent packets sent by the server MUST have the VERSION flag unset. This commits the server to the version that the client selected. @@ -795,13 +794,21 @@ COPT (0x0005): cases include changing congestion control algorithms and parameters such as initial window. (TODO: List connection options.) + ### Values of Transport Parameters for 0-RTT -Transport parameters from the server are remembered by the client for 0-RTT -connections. If values change as a result of completing the handshake, the -client is expected to respect the new values. This introduces some potential -problems, particularly with respect to transport parameters that establish -limits: +Optional transport parameters from the server MUST be reset to default values by +the client for 0-RTT connections. + +The mandatory transport parameters for stream and connection flow control and +concurrent stream limits MUST be remembered by the client. The idle timeout value +is not expected to be relevant for the short time that it takes to obtain 1-RTT +keys. + + +Transport parameter values could change as a result of completing the handshake. +The client MUST respect the new values when the handshake completes. This +introduces some potential problems: * A client might exceed a newly declared connection or stream flow control limit with 0-RTT data. If this occurs, the client ceases transmission as though the @@ -815,20 +822,15 @@ limits: A client cannot use or rely upon any other transport parameter that was enabled in a previous connection. This includes those defined in this document. A -client MUST assume that the transport parameter was absent, unless the -definition of a transport parameter provides explicit rules for use of the -option in 0-RTT. +client MUST assume that the transport parameter was absent unless the definition +of a transport parameter provides explicit rules for use of the option in 0-RTT. ### New Transport Parameters -An endpoint MUST ignore transport parameters that it does not support. - -The definition of new transport parameters can be used to negotiate new protocol -behavior. Endpoints that support features that deviate from this specification -MUST assume that a peer will operate as described in this document unless it -provides an explicit signal of support. A new transport parameter could be used -to provide this signal. +New transport parameters can be used to by endpoints to advertise new +capabilities. This can be used to negotiate new protocol behavior. An endpoint +MUST ignore transport parameters that it does not support. New transport parameters can be registered according to the rules in {{iana-transport-parameters}}. From c9c6bde1fb63c6f0dfcab9b9efec1d4327b61afc Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 9 Jan 2017 11:25:11 +1300 Subject: [PATCH 06/11] Jana's comments --- draft-ietf-quic-transport.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 5fcf4f6952..c3e4d93a84 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -628,10 +628,9 @@ QUIC's connection establishment begins with version negotiation, since all communication between the endpoints, including packet and frame formats, relies on the two endpoints agreeing on a version. -A QUIC connection begins with a client sending a handshake packet. Until -packets are protected by 1-RTT keys (see {{handshake}}), packets sent by a -client MUST include the version in the packet header. This allows the server to -identify the version of early packets and enable version negotiation. +A QUIC connection begins with a client sending a handshake packet. Until the +cryptographic handshake ({{handshake}}) produces 1-RTT keys, packets sent by a +client MUST include the version in the packet header. When the server receives a packet from a client with the VERSION flag set, it compares the client's version to the versions it supports. @@ -811,8 +810,8 @@ The client MUST respect the new values when the handshake completes. This introduces some potential problems: * A client might exceed a newly declared connection or stream flow control limit - with 0-RTT data. If this occurs, the client ceases transmission as though the - flow control limit was reached. Once WINDOW_UPDATE frames indicating an + with 0-RTT data. If this occurs, the client MUST cease transmission as though + the flow control limit was reached. Once WINDOW_UPDATE frames indicating an increase to the affected flow control offsets is received, the client can recommence sending. From 3ce68620d1492eaecf352a170b94f1a8ecd64e8d Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 10 Jan 2017 12:43:47 +1300 Subject: [PATCH 07/11] Reflow --- draft-ietf-quic-tls.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 55d38e17ad..334affeb55 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -84,11 +84,13 @@ QUIC. --- note_Note_to_Readers -Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), -which is archived at . +Discussion of this draft takes place on the QUIC working group mailing list +(quic@ietf.org), which is archived at +. -Working Group information can be found at ; source code and issues list -for this draft can be found at . +Working Group information can be found at ; source +code and issues list for this draft can be found at +. --- middle From ebd4254079c6f6712ed4ecf6746afb1a99c8621c Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 10 Jan 2017 13:08:08 +1300 Subject: [PATCH 08/11] Add transport parameters to the interface definition --- draft-ietf-quic-tls.md | 108 ++++++++++++++++++++++++++++++++--------- 1 file changed, 85 insertions(+), 23 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 334affeb55..d275edc6ff 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -150,21 +150,23 @@ interactions between TLS and QUIC, with the QUIC packet protection being called out specially. ~~~ -+------------+ +------------+ -| |----- Handshake ---->| | -| |<---- Handshake -----| | -| QUIC | | TLS | -| |<----- 0-RTT OK -----| | -| |<----- 1-RTT OK -----| | -| |<-- Handshake Done --| | -+------------+ +------------+ - | ^ ^ | - | Protect | Protected | | - v | Packet | | -+------------+ / / -| QUIC | / / -| Packet |------ Get Secret ------' / -| Protection |<------ Secret ----------' ++------------+ +------------+ +| |-- Transport Params -->| | +| |------ Handshake ----->| | +| |<----- Handshake ------| | +| |<-- Transport Params --| | +| QUIC | | TLS | +| |<------ 0-RTT OK ------| | +| |<------ 1-RTT OK ------| | +| |<--- Handshake Done ---| | ++------------+ +------------+ + | ^ ^ | + | Protect | Protected | | + v | Packet | | ++------------+ / / +| QUIC | / / +| Packet |------- Get Secret -------' / +| Protection |<------- Secret -----------' +------------+ ~~~ {: #schematic title="QUIC and TLS Interactions"} @@ -300,7 +302,7 @@ ensures that TLS handshake messages are delivered in the correct order. @C QUIC STREAM Frame(s) <1>: ClientHello - + QUIC Extension + + QUIC Transport Params --------> 0-RTT Key => @0 @@ -311,6 +313,7 @@ ensures that TLS handshake messages are delivered in the correct order. QUIC STREAM Frame <1>: @C ServerHello {TLS Handshake Messages} + { + QUIC Transport Params} <-------- 1-RTT Key => @1 @@ -359,8 +362,9 @@ More information on key transitions is included in {{cleartext-hs}}. ## Interface to TLS -As shown in {{schematic}}, the interface from QUIC to TLS consists of three -primary functions: Handshake, Key Ready Events, and Secret Export. +As shown in {{schematic}}, the interface from QUIC to TLS consists of four +primary functions: Handshake, Key Ready Events, Transport Parameter Exchange, +and Secret Export. Additional functions might be needed to configure TLS. @@ -428,6 +432,31 @@ ClientHello message, a TLS server might signal that 0-RTT keys are available. used to protect packets that the client sends. +### Transport Parameter Exchange + +As part of the handshake, QUIC provides TLS with the value of the QUIC transport +parameters extension (see {{quic-extension}}). This value is included in the +TLS ClientHello or EncryptedExtensions message. TLS provides QUIC with the +authenticated value for the transport parameters that was advertised by the +peer. + +The contents of the transport parameters is defined by the version of QUIC that +is in use, see {{QUIC-TRANSPORT}}. + +Transport parameters are available only after handling incoming messages. + +A server learns authenticated values for the server's transport parameters after +the handshake is complete. + +A server learns authenticated values for the client's transport parameters at +one of two points depending on whether the connection is resumed (that is, if it +uses a pre-shared key). A server that accepts resumption learns the +authenticated values for the client's transport parameters after receiving and +verifying the TLS ClientHello. A server that does not accept resumption +authenticates the client's transport parameters once the TLS Finished message +from the client is received and verified. + + ### Secret Export Details how secrets are exported from TLS are included in {{key-expansion}}. @@ -435,8 +464,39 @@ Details how secrets are exported from TLS are included in {{key-expansion}}. ### TLS Interface Summary -{{exchange-summary}} summarizes the exchange between QUIC and TLS for both -client and server. +{{1rtt-interface}} summarizes the exchange between QUIC and TLS for both client +and server for a full handshake without either resumption or 0-RTT. + +~~~ +Client Server + +Get Handshake + --- send/receive ---> + Handshake Received + Get Handshake + 1-RTT Keys Ready + <--- send/receive --- +Handshake Received +1-RTT Keys Ready +Transport Parameters +Get Handshake +Handshake Complete + --- send/receive ---> + Handshake Received + Transport Parameters + Get Handshake + Handshake Complete + <--- send/receive --- +Handshake Received +Get Handshake +~~~ +{: #1rtt-interface title="1-RTT Interactions between QUIC and TLS"} + + +{{0rtt-interface}} summarizes the exchange between QUIC and TLS for both client +and server in the case that 0-RTT is possible and successful. The only +difference is the availability of 0-RTT keys, and the earlier availability of +the client's transport parameters at the server. ~~~ Client Server @@ -446,11 +506,13 @@ Get Handshake --- send/receive ---> Handshake Received 0-RTT Key Ready + Transport Parameters Get Handshake 1-RTT Keys Ready <--- send/receive --- Handshake Received 1-RTT Keys Ready +Transport Parameters Get Handshake Handshake Complete --- send/receive ---> @@ -461,7 +523,7 @@ Handshake Complete Handshake Received Get Handshake ~~~ -{: #exchange-summary title="Interaction Summary between QUIC and TLS"} +{: #0rtt-interface title="0-RTT Interactions between QUIC and TLS"} # QUIC Packet Protection {#packet-protection} @@ -935,7 +997,7 @@ Different strategies are appropriate for different types of data. This document proposes that all strategies are possible depending on the type of message. * Transport parameters and options are made usable and authenticated as part of - the TLS handshake (see {{quic_parameters}}). + the TLS handshake (see {{quic-extension}}). * Most unprotected messages are treated as fatal errors when received except for the small number necessary to permit the handshake to complete (see {{pre-handshake-unprotected}}). @@ -1117,7 +1179,7 @@ the server picks an incompatible combination of QUIC version and ALPN identifier. -## QUIC Transport Parameters Extension {#quic_parameters} +## QUIC Transport Parameters Extension {#quic-extension} QUIC transport parameters are carried in a TLS extension. Different versions of QUIC might define a different format for this struct. From f4577328707a7babfd68116e6507117879878a7b Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 10 Jan 2017 13:22:16 +1300 Subject: [PATCH 09/11] Use better anchor names --- draft-ietf-quic-tls.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index d275edc6ff..935bb19b79 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -464,7 +464,7 @@ Details how secrets are exported from TLS are included in {{key-expansion}}. ### TLS Interface Summary -{{1rtt-interface}} summarizes the exchange between QUIC and TLS for both client +{{full-interface}} summarizes the exchange between QUIC and TLS for both client and server for a full handshake without either resumption or 0-RTT. ~~~ @@ -490,11 +490,11 @@ Handshake Complete Handshake Received Get Handshake ~~~ -{: #1rtt-interface title="1-RTT Interactions between QUIC and TLS"} +{: #full-interface title="1-RTT Interactions between QUIC and TLS"} -{{0rtt-interface}} summarizes the exchange between QUIC and TLS for both client -and server in the case that 0-RTT is possible and successful. The only +{{zero-rtt-interface}} summarizes the exchange between QUIC and TLS for both +client and server in the case that 0-RTT is possible and successful. The only difference is the availability of 0-RTT keys, and the earlier availability of the client's transport parameters at the server. @@ -523,7 +523,7 @@ Handshake Complete Handshake Received Get Handshake ~~~ -{: #0rtt-interface title="0-RTT Interactions between QUIC and TLS"} +{: #zero-rtt-interface title="0-RTT Interactions between QUIC and TLS"} # QUIC Packet Protection {#packet-protection} From dbea96b2bad8710dce44b1145465a14619e56f13 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 11 Jan 2017 13:33:59 +1300 Subject: [PATCH 10/11] Don't require storing of 0-RTT parameters --- draft-ietf-quic-transport.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index c3e4d93a84..7ed3dad50c 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -800,10 +800,9 @@ Optional transport parameters from the server MUST be reset to default values by the client for 0-RTT connections. The mandatory transport parameters for stream and connection flow control and -concurrent stream limits MUST be remembered by the client. The idle timeout value -is not expected to be relevant for the short time that it takes to obtain 1-RTT -keys. - +concurrent stream limits is stored by the client along with any information +needed to establish a 0-RTT connection. The idle timeout value is not expected +to be relevant for the short time that it takes to obtain 1-RTT keys. Transport parameter values could change as a result of completing the handshake. The client MUST respect the new values when the handshake completes. This From e8cb4762c1b53c87a7960d78d74599530738cfd0 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 25 Jan 2017 10:08:34 +0900 Subject: [PATCH 11/11] Remove mention of SCUP --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 7ed3dad50c..81a657f7bd 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -908,7 +908,7 @@ updated STK message mid-connection to update server state that is stored at the client in the STK. (TODO: Describe server and client actions on STK, encoding, recommendations for -what to put in an STK. Describe SCUP messages.) +what to put in an STK.) ### Crypto Handshake Protocol Features