| Network Working Group | M. Thomson |
| Internet-Draft | Mozilla |
| Intended status: Standards Track | March 16, 2016 |
| Expires: September 17, 2016 |
Porting QUIC to Datagram Transport Layer Security (DTLS)
draft-thomson-quic-dtls-latest
The QUIC experiment defines a custom security protocol. This was necessary to gain handshake latency improvements. This document describes how that security protocol might be replaced with DTLS.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 17, 2016.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
QUIC [I-D.tsvwg-quic-protocol] provides a multiplexed transport for HTTP [RFC7230] semantics that provides several key advantages over HTTP/1.1 [RFC7230] or HTTP/2 [RFC7540] over TCP [RFC0793].
The custom security protocol designed for QUIC provides critical latency improvements for connection establishment. Absent packet loss, most new connections can be established with a single round trip; on subsequent connections between the same client and server, the client can often send application data immediately, that is, zero round trip setup. DTLS 1.3 uses a similar design and aims to provide the same set of improvements.
This document describes how the standardized DTLS 1.3 might serve as a security layer for QUIC. The same design could work for DTLS 1.2, though few of the benefits QUIC provides would be realized due to the handshake latency in versions of TLS prior to 1.3.
The words “MUST”, “MUST NOT”, “SHOULD”, and “MAY” are used in this document. It’s not shouting; when they are capitalized, they have the special meaning defined in [RFC2119].
QUIC [I-D.tsvwg-quic-protocol] can be separated into several modules:
The relative relationship of these components are pictorally represented in Figure 1.
+----+------+
| HS | HTTP |
+----+------+------------+
| Streams | Congestion |
+-----------+------------+
| Frames |
+ +---------------------+
| | FEC +--------+
+ +---------------------+ Public |
| | Crypto | Reset |
+--+---------------------+--------+
| Envelope |
+---------------------------------+
| UDP |
+---------------------------------+
*HS = Crypto Handshake
Figure 1: QUIC Structure
This document describes a replacement of the cryptographic parts of QUIC. This includes the handshake messages that are exchanged on stream 1, plus the record protection that is used to encrypt and authenticate all other frames.
TLS 1.3 provides two basic handshake modes of interest to QUIC:
A simplified TLS 1.3 handshake with 0-RTT application data is shown in Figure 2, see [I-D.ietf-tls-tls13] for more options.
Client Server
ClientHello
(Finished)
(0-RTT Application Data)
(end_of_early_data) -------->
ServerHello
{EncryptedExtensions}
{ServerConfiguration}
{Certificate}
{CertificateVerify}
{Finished}
<-------- [Application Data]
{Finished} -------->
[Application Data] <-------> [Application Data]
Figure 2: TLS Handshake with 0-RTT
Two additional variations on this basic handshake exchange are relevant to this document:
QUIC completes its cryptographic handshake on stream 1, which means that the negotiation of keying material happens within the QUIC protocol. In contrast, QUIC over DTLS uses a layered approach, where QUIC frames are exchanged as DTLS application data.
+-----------+ | HTTP | +-----------+------------+ | Streams | Congestion | +-----------+------------+ | Frames | | +------------+ | | FEC +--------+ +-----------+------------+ Public | | DTLS | Reset | +------------------------+--------+ | UDP | +---------------------------------+
Figure 3: QUIC over DTLS
In this design QUIC frames are exchanged as DTLS application data. FEC and public reset are provided as minimal protocols that are multiplexed with DTLS, using a different value for the first octet of the UDP payload (see Section 7.3 for a sample design).
The DTLS handshake is the first data that is exchanged on a connection, though additional QUIC-specific data might be included, see Section 5.
Several changes to the structure of QUIC are necessary to make a layered design practical.
These changes produce the handshake shown in Figure 4, where QUIC frames are exchanged as DTLS application data.
Client Server
ClientHello
+ QUIC Setup Parameters
+ ALPN ("quic")
(Finished)
(Replayable QUIC Frames)
(end_of_early_data) -------->
ServerHello
{EncryptedExtensions}
{ServerConfiguration}
{Certificate}
{CertificateVerify}
{Finished}
<-------- [QUIC Frames]
{Finished} -------->
[QUIC Frames] <-------> [QUIC Frames]
Figure 4: QUIC over DTLS Handshake
The remainder of this section describes how QUIC features are modified to fit into a layered design.
[I-D.tsvwg-quic-protocol] does not describe any connection-level state that might be included by a client in a standard 1-RTT handshake to aid in connection setup. However, the following additions are either implemented, or might be.
QUIC implementations describe a source address token. This is an opaque blob that a server provides to clients when they first use a given source address. The client returns this token in subsequent messages as a return routeability check. That is, the client returns this token to prove that it is able to receive packets at the source address that it claims.
Since this token is opaque and consumed only by the server, it can be included in the TLS 1.3 configuration identifier for 0-RTT handshakes. Servers that use 0-RTT are advised to provide new configuration identifiers after every handshake to avoid passive linkability of connections from the same client.
A server that is under load might include the same information in the cookie extension/field of a HelloRetryRequest. (Note: the current version of TLS 1.3 does not include this information.)
Application Layer Protocol Negotiation (ALPN) [RFC7301] will be used to negotiate the version of QUIC that is used. This is a more verbose mechanism than the scheme used in QUIC, but it is also more capable. For example, specific QUIC versions could be separately identified: “quic-draft-01”, “quic-draft-02”, and “quic-underdamped-cc”.
A client describes characteristics of the transport protocol it intends to conduct with the server in a new QUIC-specific extensions in its ClientHello. The server uses this information to determine whether it wants to continue the connection, request source address validation, or reject the connection. Having this information unencrypted permits this check to occur prior to committing the resources needed to complete the initial key exchange.
If the server decides to complete the connection, it generates a corresponding response and includes it in the EncryptedExtensions message.
These parameters are not confidentiality-protected when sent by the client, but the server response is protected by the handshake traffic keys. The entire exchange is integrity protected once the handshake completes.
This information is not used by DTLS, but can be passed to the QUIC protocol as initialization parmeters.
The quic_transport_parameters extension contains a declarative set of parameters that constrain the behaviour of a peer. This includes the size of the stream- and connection-level flow control windows, plus a set of optional parameters such as the receive buffer size.
enum {
receive_buffer(0),
(65535)
} QuicTransportParameterType;
struct {
QuicTransportParameterType type;
uint32 value;
} QuicTransportParameter;
struct {
uint32 connection_initial_window;
uint32 stream_initial_window;
uint32 implicit_shutdown_timeout;
QuicTransportParameter parameters<0..2^16-1>;
} QuicTransportParametersExtension;
These values can be updated once the connection has started by sending an authenticated -SOMETHING- frame on stream -SOMETHING-.
The QuicTransportParameterType identifies parameters. This is taken from a single space that is shared by all QUIC versions (and options, see Section 5.3.2).
This extension MUST be included if a QUIC version is negotiated. A server MUST NOT negotiate QUIC if this extension is not present. This could mean that a server might consequently send a fatal no_application_protocol alert.
Based on the values offered by a client a server MAY use the values in this extension to determine whether it wants to continue the connection, request source address validation, or reject the connection. Since this extension is initially unencrypted (along with ALPN), the server can use the information prior to committing the resources needed to complete a key exchange.
If the server decides to use QUIC, this extension MUST be included in the EncryptedExtensions message.
The quic_options extension includes a list of options that can be negotiated for a given connection. These are set during the initial handshake and are fixed thereafter. These options are used to enable or disable optional features in the protocol.
enum {
(65535)
} QuicOption;
struct {
QuicOption options<0..2^8-2>;
} QuicOptionsExtension;
The set of features that are supported across different versions might vary. A client SHOULD include all options that it is willing to use. The server MAY select any subset of those options that apply to the version of QUIC that it selects. Only those options selected by the server are available for use.
If the server decides to use any QUIC options, includes this extension in the EncryptedExtensions message.
In addition to the parameters for the transport, congestion feedback might need be exchanged prior to completing a key exchange is complete.
A new QUIC congestion extension might be included by clients to include any information. Servers might include this extension if there is a need to use the HelloRetryRequest also. Once the handshake is complete, this information can be exchanged as QUIC frames.
The use of extensions for the purpose has some potential drawbacks:
Section 7.2 identifies the related issue of loss feedback mechanisms during the handshaking phase.
No major changes are required to transport frames as DTLS application data. A small modification permits the use of a single contiguous sequence number space, so that QUIC can reuse DTLS sequence numbers rather than provide redundant numbering (see Section 7.1).
This can be removed, and is (apparently) already have been removed from current implementations.
FEC can be covered by encryption and forms part of the framing layer. The current protocol has some external parts, but these can be encrypted.
DTLS 1.3 does not need substantial modifications in order to support the more critical features of QUIC. However, some additional changes might be made to optimize DTLS for use with QUIC.
Since the work on TLS 1.3 is not yet complete, these changes might be integrated before TLS 1.3 is completed. Failing that, new extensions to TLS might be considered to negotiate their use.
QUIC relies on a single sequence number space for identifying frames. DTLS does not provide a contiguous sequence number space as each change of traffic keys causes sequence numbers to be reset. This change occurs at the transition from 0-RTT application data to full application data, plus when traffic keys are updated.
The only reason for the separate sequence number space is to support the guarantees required by TLS. For TLS, an attacker with access to record protection keys might be able to force loss of a number of packets that are protected by the next key.
DTLS does not rely on the same property, since it does not aim to secure a contiguous stream of data. Attacker-induced loss is not distinguishable from other forms of loss. For this reason, a single sequence number space is acceptable.
DTLS has a somewhat simplistic retransmission scheme for its handshake datagrams. An entire flight of handshake messages is sent repeatedly by an endpoint until it receives a response from its peer. In this regard, the QUIC scheme of acknowledgments is more precise in identifying and repairing missing datagrams. Providing a more complete and accurate feedback mechanism would be valuable in reducing the performance of the handshake.
DTLS 1.2 [RFC6347] has a rather large per-packet overhead. This overhead includes a content type (1 octet), protocol version (2 octets), an epoch (2 octets), sequence number (6 octets) and length (2 octets), totalling 13 octets on every record. Of these, only the sequence number and 14 bits of the record length are critical to the correct functioning of the protocol and both might be reduced in size. A single bit of the epoch is useful in allowing an endpoint to more easily identify when keys change.
Note that a change to the packet format needs to be carefully designed if DTLS is to remain compatible with existing use cases. DTLS-SRTP [RFC5764] relies on the value of the first octet of the DTLS packet not overlapping with valid values for SRTP [RFC3711] and STUN [RFC5389]. Only values 20 through 63 inclusive are guaranteed to be available to DTLS in that context.
One possible design has a four octet header, comprising three fixed bits (001), 1 epoch bit, 12 sequence number bits, 2 zero bits, and 14 length bits. This format would only apply to encrypted datagrams, since the ClientHello and ServerHello would need to be backward compatible.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1|e|sequence number (13bit)|0 0| length (14bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Packet Header
The second set of zero bits could be used for an expanded sequence number space. However, if there is any expectation of being able to use datagrams that are more than 4096 packets out of sequence, then adding another octet might be a better option, even if that results in destroying word alignment.
This design allows for unprotected messages such as unprotected handshake messages and the QUIC public reset to use values between 20 and 31 in the first octet.
If each UDP datagram is restricted to containing a single DTLS record, the length field could be omitted entirely, reducing the unencrypted overhead to as little as 2 octets. The drawback of this approach is that it could require some additional UDP datagrams during the handshake, since changes to keying material can only happen when a new record is sent.
In TLS 1.3, these transitions are infrequent aside from during the initial handshake:
The QUIC connection identifier serves to identify a connection and to allow a server to resume an existing connection from a new client address in case of mobility events. However, this creates an identifier that a passive observer [RFC7258] can use to correlate connections.
TLS 1.3 offers connection resumption using pre-shared keys, which also allows a client to send 0-RTT application data. This mode could be used to continue a connection rather than rely on a publicly visible correlator. This only requires that servers produce a new ticket on every connection and that clients do not resume from the same ticket more than once.
The advantage of relying on 0-RTT modes for mobility events is that this is also more robust. If the new point of attachment results in contacting a new server instance - one that lacks the session state - then a fallback is easy.
The main drawback with a clean restart or anything resembling a restart is that accumulated state can be lost. In particular, the state of the HPACK header compression table can be quite valuable. Note that some QUIC implementations use part of the connection ID to identify the server that is handling the connection, enabling routing to that server and avoiding this sort of problem.
A lightweight state resurrection extension might be used to avoid having to recreate any expensive state.
Including data outside of the DTLS protection layer exposes endpoints to all sorts of intermediary-initiated shenanigans.
This includes transport parameter negotiation, which might ultimately have integrity protection. If transport configuration is grounds for rejecting a connection, and a client adjusts its proposed configuration in response to a rejection, and that rejection is not authenticated (it won’t be), then an attacker can force a client to adjust their configuration.
Clients are therefore encouraged to not alter their ClientHello or its contents in response to unauthenticated rejections or network errors.
This document has no IANA actions. Yet.
– back
Christian Huitema’s knowledge of QUIC is far better than my own. This would be even more inaccurate and useless if not for his assistance. This document has variously benefited from a long series of discussions with Ryan Hamilton, Jana Iyengar, Adam Langley, Roberto Peon, Ian Swett, and likely many others who are merely forgotten by a faulty meat computer.
| [I-D.ietf-tls-tls13] | Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Internet-Draft draft-ietf-tls-tls13-11, December 2015. |
| [I-D.tsvwg-quic-protocol] | Hamilton, R., Iyengar, J., Swett, I. and A. Wilk, "QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2", Internet-Draft draft-tsvwg-quic-protocol-02, January 2016. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC7301] | Friedl, S., Popov, A., Langley, A. and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014. |