< draft-thomson-quic-tls-00.txt   draft-thomson-quic-tls-01.txt >
Network Working Group M. Thomson Network Working Group M. Thomson
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track R. Hamilton Intended status: Standards Track R. Hamilton
Expires: September 22, 2016 Google Expires: April 28, 2017 Google
March 21, 2016 October 25, 2016
Porting QUIC to Transport Layer Security (TLS) Using Transport Layer Security (TLS) to Secure QUIC
draft-thomson-quic-tls-00 draft-thomson-quic-tls-01
Abstract Abstract
The QUIC experiment defines a custom security protocol. This was This document describes how Transport Layer Security (TLS) can be
necessary to gain handshake latency improvements. This document used to secure QUIC.
describes how that security protocol might be replaced with TLS.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 22, 2016. This Internet-Draft will expire on April 28, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 11 skipping to change at page 2, line 11
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Handshake Overview . . . . . . . . . . . . . . . . . . . 4 2.1. Handshake Overview . . . . . . . . . . . . . . . . . . . 4
3. QUIC over TLS Structure . . . . . . . . . . . . . . . . . . . 5 3. TLS in Stream 1 . . . . . . . . . . . . . . . . . . . . . . . 5
4. Mapping of QUIC to QUIC over TLS . . . . . . . . . . . . . . 6 3.1. Handshake and Setup Sequence . . . . . . . . . . . . . . 6
4.1. Protocol and Version Negotiation . . . . . . . . . . . . 7 4. QUIC Record Protection . . . . . . . . . . . . . . . . . . . 8
4.2. Source Address Validation . . . . . . . . . . . . . . . . 8 4.1. Key Phases . . . . . . . . . . . . . . . . . . . . . . . 8
5. Record Protection . . . . . . . . . . . . . . . . . . . . . . 8 4.1.1. Retransmission of TLS Handshake Messages . . . . . . 9
5.1. TLS Handshake Encryption . . . . . . . . . . . . . . . . 9 4.1.2. Key Update . . . . . . . . . . . . . . . . . . . . . 10
5.2. Key Update . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. QUIC Key Expansion . . . . . . . . . . . . . . . . . . . 11
5.3. Sequence Number Reconstruction . . . . . . . . . . . . . 10 4.3. QUIC AEAD application . . . . . . . . . . . . . . . . . . 12
5.4. Alternative Design: Exporters . . . . . . . . . . . . . . 10 4.4. Sequence Number Reconstruction . . . . . . . . . . . . . 12
6. Pre-handshake QUIC Messages . . . . . . . . . . . . . . . . . 11 5. Pre-handshake QUIC Messages . . . . . . . . . . . . . . . . . 13
6.1. QUIC Extension . . . . . . . . . . . . . . . . . . . . . 11 5.1. Unprotected Frames Prior to Handshake Completion . . . . 14
6.2. Unprotected Frames Prior to Handshake Completion . . . . 15 5.1.1. STREAM Frames . . . . . . . . . . . . . . . . . . . . 14
6.2.1. STREAM Frames . . . . . . . . . . . . . . . . . . . . 15 5.1.2. ACK Frames . . . . . . . . . . . . . . . . . . . . . 15
6.2.2. ACK Frames . . . . . . . . . . . . . . . . . . . . . 15 5.1.3. WINDOW_UPDATE Frames . . . . . . . . . . . . . . . . 15
6.2.3. WINDOW_UPDATE Frames . . . . . . . . . . . . . . . . 15 5.1.4. Denial of Service with Unprotected Packets . . . . . 15
6.2.4. FEC Packets . . . . . . . . . . . . . . . . . . . . . 16 5.2. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 16
6.3. Protected Frames Prior to Handshake Completion . . . . . 16 5.3. Protected Frames Prior to Handshake Completion . . . . . 17
7. Connection ID . . . . . . . . . . . . . . . . . . . . . . . . 17 6. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6.1. Protocol and Version Negotiation . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6.2. QUIC Extension . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.3. Source Address Validation . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 18 6.4. Priming 0-RTT . . . . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 19 7.1. Packet Reflection Attack Mitigation . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 7.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
QUIC [I-D.tsvwg-quic-protocol] provides a multiplexed transport for QUIC [I-D.hamilton-quic-transport-protocol] provides a multiplexed
HTTP [RFC7230] semantics that provides several key advantages over transport for HTTP [RFC7230] semantics that provides several key
HTTP/1.1 [RFC7230] or HTTP/2 [RFC7540] over TCP [RFC0793]. advantages over HTTP/1.1 [RFC7230] or HTTP/2 [RFC7540] over TCP
[RFC0793].
The custom security protocol designed for QUIC provides critical This document describes how QUIC can be secured using Transport Layer
latency improvements for connection establishment. Absent packet Security (TLS) version 1.3 [I-D.ietf-tls-tls13]. TLS 1.3 provides
loss, most new connections can be established with a single round critical latency improvements for connection establishment over
trip; on subsequent connections between the same client and server, previous versions. Absent packet loss, most new connections can be
the client can often send application data immediately, that is, zero established and secured within a single round trip; on subsequent
round trip setup. TLS 1.3 uses a similar design and aims to provide connections between the same client and server, the client can often
the same set of improvements. send application data immediately, that is, zero round trip setup.
This document describes how the standardized TLS 1.3 might serve as a This document describes how the standardized TLS 1.3 can act a
security layer for QUIC. The same design could work for TLS 1.2, security component of QUIC. The same design could work for TLS 1.2,
though few of the benefits QUIC provides would be realized due to the though few of the benefits QUIC provides would be realized due to the
handshake latency in versions of TLS prior to 1.3. handshake latency in versions of TLS prior to 1.3.
Alternative Designs: There are other designs that are possible; and
many of these alternative designs are likely to be equally good.
The point of this document is to articulate a coherent single
design. Notes like this throughout the document are used describe
points where alternatives were considered.
Note: This is a rough draft. Many details have not been ironed out.
Ryan is not responsible for any errors or omissions.
1.1. Notational Conventions 1.1. Notational Conventions
The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this
document. It's not shouting; when they are capitalized, they have document. It's not shouting; when they are capitalized, they have
the special meaning defined in [RFC2119]. the special meaning defined in [RFC2119].
2. Protocol Overview 2. Protocol Overview
QUIC [I-D.tsvwg-quic-protocol] can be separated into several modules: QUIC [I-D.hamilton-quic-transport-protocol] can be separated into
several modules:
1. The basic frame envelope describes the common packet layout. 1. The basic frame envelope describes the common packet layout.
This layer includes connection identification, version This layer includes connection identification, version
negotiation, and includes the indicators that allow the framing, negotiation, and includes markers that allow the framing and
public reset, and FEC modules to be identified. public reset to be identified.
2. The public reset is an unprotected frame that allows an 2. The public reset is an unprotected packet that allows an
intermediary (an entity that is not part of the security context) intermediary (an entity that is not part of the security context)
to request the termination of a QUIC connection. to request the termination of a QUIC connection.
3. The forward error correction (FEC) module provides redundant 3. Version negotiation frames are used to agree on a common version
entropy that allows for frames to be repaired in event of loss. of QUIC to use.
4. Framing comprises most of the QUIC protocol. Framing provides a 4. Framing comprises most of the QUIC protocol. Framing provides a
number of different types of frame, each with a specific purpose. number of different types of frame, each with a specific purpose.
Framing supports frames for both congestion management and stream Framing supports frames for both congestion management and stream
multiplexing. Framing additionally provides a liveness testing multiplexing. Framing additionally provides a liveness testing
capability (the PING frame). capability (the PING frame).
5. Crypto provides confidentiality and integrity protection for 5. Encryption provides confidentiality and integrity protection for
frames. All frames are protected after the handshake completes frames. All frames are protected based on keying material
on stream 1. Prior to this, data is protected with the 0-RTT derived from the TLS connection running on stream 1. Prior to
keys. this, data is protected with the 0-RTT keys.
6. Multiplexed streams are the primary payload of QUIC. These 6. Multiplexed streams are the primary payload of QUIC. These
provide reliable, in-order delivery of data and are used to carry provide reliable, in-order delivery of data and are used to carry
the encryption handshake and transport parameters (stream 1), the encryption handshake and transport parameters (stream 1),
HTTP header fields (stream 3), and HTTP requests and responses. HTTP header fields (stream 3), and HTTP requests and responses.
Frames for managing multiplexing include those for creating and Frames for managing multiplexing include those for creating and
destroying streams as well as flow control and priority frames. destroying streams as well as flow control and priority frames.
7. Congestion management includes packet acknowledgment and other 7. Congestion management includes packet acknowledgment and other
signal required to ensure effective use of available link signal required to ensure effective use of available link
capacity. capacity.
8. HTTP mapping provides an adaptation to HTTP that is based on 8. A complete TLS connection is run on stream 1. This includes the
entire TLS record layer. As the TLS connection reaches certain
states, keying material is provided to the QUIC encryption layer
for protecting the remainder of the QUIC traffic.
9. HTTP mapping provides an adaptation to HTTP that is based on
HTTP/2. HTTP/2.
The relative relationship of these components are pictorally The relative relationship of these components are pictorally
represented in Figure 1. represented in Figure 1.
+----+------+ +-----+------+
| HS | HTTP | | TLS | HTTP |
+----+------+------------+ +-----+------+------------+
| Streams | Congestion | | Streams | Congestion |
+-----------+------------+ +------------+------------+
| Frames | | Frames +--------+---------+
+ +------------+ + +---------------------+ Public | Version |
| | FEC +--------+ | | Encryption | Reset | Nego. |
+ +--------+------------+ Public | +---+---------------------+--------+---------+
| | Crypto | Reset | | Envelope |
+--+---------------------+--------+ +--------------------------------------------+
| Envelope | | UDP |
+---------------------------------+ +--------------------------------------------+
| UDP |
+---------------------------------+
*HS = Crypto Handshake
Figure 1: QUIC Structure Figure 1: QUIC Structure
This document describes a replacement of the cryptographic parts of This document defines the cryptographic parts of QUIC. This includes
QUIC. This includes the handshake messages that are exchanged on the handshake messages that are exchanged on stream 1, plus the
stream 1, plus the record protection that is used to encrypt and record protection that is used to encrypt and authenticate all other
authenticate all other frames. frames.
2.1. Handshake Overview 2.1. Handshake Overview
TLS 1.3 provides two basic handshake modes of interest to QUIC: TLS 1.3 provides two basic handshake modes of interest to QUIC:
o A full handshake in which the client is able to send application o A full handshake in which the client is able to send application
data after one round trip and the server immediately after data after one round trip and the server immediately after
receiving the first message from the client. receiving the first message from the client.
o A 0-RTT handshake in which the client uses information about the o A 0-RTT handshake in which the client uses information about the
server to send immediately. This data can be replayed by an server to send immediately. This data can be replayed by an
attacker so it MUST NOT carry a self-contained trigger for any attacker so it MUST NOT carry a self-contained trigger for any
non-idempotent action. non-idempotent action.
A simplified TLS 1.3 handshake with 0-RTT application data is shown 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. in Figure 2, see [I-D.ietf-tls-tls13] for more options and details.
Client Server Client Server
ClientHello ClientHello
(Finished) (Finished)
(0-RTT Application Data) (0-RTT Application Data)
(end_of_early_data) --------> (end_of_early_data) -------->
ServerHello ServerHello
{EncryptedExtensions} {EncryptedExtensions}
{ServerConfiguration} {ServerConfiguration}
skipping to change at page 5, line 38 skipping to change at page 5, line 38
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
Figure 2: TLS Handshake with 0-RTT Figure 2: TLS Handshake with 0-RTT
Two additional variations on this basic handshake exchange are Two additional variations on this basic handshake exchange are
relevant to this document: relevant to this document:
o The server can respond to a ClientHello with a HelloRetryRequest, o The server can respond to a ClientHello with a HelloRetryRequest,
which adds an additional round trip prior to the basic exchange. which adds an additional round trip prior to the basic exchange.
This is needed if the server wishes to request a different key This is needed if the server wishes to request a different key
exchange key from the client. HelloRetryRequest might also be exchange key from the client. HelloRetryRequest is also used to
used to verify that the client is correctly able to receive verify that the client is correctly able to receive packets on the
packets on the address it claims to have (see Section 4.2). address it claims to have (see Section 6.3).
o A pre-shared key mode can be used for subsequent handshakes to o A pre-shared key mode can be used for subsequent handshakes to
avoid public key operations. This might be the basis for 0-RTT, avoid public key operations. This is the basis for 0-RTT data,
even if the remainder of the connection is protected by a new even if the remainder of the connection is protected by a new
Diffie-Hellman exchange. Diffie-Hellman exchange.
3. QUIC over TLS Structure 3. TLS in Stream 1
QUIC completes its cryptographic handshake on stream 1, which means QUIC completes its cryptographic handshake on stream 1, which means
that the negotiation of keying material happens within the QUIC that the negotiation of keying material happens after the QUIC
protocol. QUIC over TLS does the same, relying on the ordered protocol has started. This simplifies the use of TLS since QUIC is
delivery guarantees provided by QUIC to ensure that the TLS handshake able to ensure that the TLS handshake packets are delivered reliably
packets are delivered reliably and in order. and in order.
+-----+---------+ QUIC Stream 1 carries a complete TLS connection. This includes the
| TLS | HTTP | TLS record layer in its entirety. QUIC provides for reliable and in-
+-----+----------+------------+ order delivery of the TLS handshake messages on this stream.
| Streams | Congestion |
+----------------+------------+
| Frames |
| +------------+
| | FEC +--------+
| +----------+------------+ Public |
| | TLS Record Protection | Reset |
+-----+-----------------------+--------+
| Envelope |
+--------------------------------------+
| UDP |
+--------------------------------------+
Figure 3: QUIC over TLS Prior to the completion of the TLS handshake, QUIC frames can be
exchanged. However, these frames are not authenticated or
confidentiality protected. Section 5 covers some of the implications
of this design and limitations on QUIC operation during this phase.
In this design the QUIC envelope carries QUIC frames until the TLS Once complete, QUIC frames are protected using QUIC record
handshake completes. After the handshake successfully completes the protection, see Section 4.
key exchange, QUIC frames are then protected by TLS record
protection.
QUIC stream 1 is used to exchange TLS handshake packets. QUIC 3.1. Handshake and Setup Sequence
provides for reliable and in-order delivery of the TLS handshake
The integration of QUIC with a TLS handshake is shown in more detail
in Figure 3. QUIC "STREAM" frames on stream 1 carry the TLS
handshake. QUIC is responsible for ensuring that the handshake
packets are re-sent in case of loss and that they can be ordered
correctly.
Client Server
@A QUIC STREAM Frame(s) <1>:
ClientHello
+ QUIC Setup Parameters
-------->
0-RTT Key -> @B
@B QUIC STREAM Frame(s) <1>:
(Finished)
Replayable QUIC Frames <any stream>
-------->
QUIC STREAM Frame <1>: @B/A
ServerHello
{Handshake Messages}
<--------
1-RTT Key -> @C
QUIC Frames @C
<--------
@B QUIC STREAM Frame(s) <1>:
(end_of_early_data <1>)
{Finished}
-------->
@C QUIC Frames <-------> QUIC Frames @C
Figure 3: QUIC over TLS Handshake
In Figure 3, symbols mean:
o "<" and ">" enclose stream numbers.
o "@" indicates the key phase that is currently used for protecting
QUIC packets.
o "(" and ")" enclose messages that are protected with TLS 0-RTT
handshake or application keys.
o "{" and "}" enclose messages that are protected by the TLS
Handshake keys.
If 0-RTT is not possible, then the client does not send frames
protected by the 0-RTT key (@B). The only key transition on the
client is from cleartext (@A) to 1-RTT protection (@C).
If 0-RTT data is not accepted by the server, then the server sends
its handshake messages without protection (@A). The client still
transitions from @A to @B, but it can stop sending 0-RTT data and
progress immediately to 1-RTT data when it receives a cleartext
ServerHello.
4. QUIC Record Protection
QUIC provides a record protection layer that is responsible for
authenticated encryption of packets. The record protection layer
uses keys provided by the TLS connection and authenticated encryption
to provide confidentiality and integrity protection for the content
of packets.
Different keys are used for QUIC and TLS record protection. Having
separate QUIC and TLS record protection means that TLS records can be
protected by two different keys. This redundancy is maintained for
the sake of simplicity.
4.1. Key Phases
The transition to use of a new QUIC key occurs immediately after
sending the TLS handshake messages that produced the key transition.
Every time that a new set of keys is used for protecting outbound
messages, the KEY_PHASE bit in the public flags is toggled. The
KEY_PHASE bit on unencrypted messages is 0.
The KEY_PHASE bit on the public flags is the most significant bit
(0x80).
The KEY_PHASE bit allows a recipient to detect a change in keying
material without needing to receive the message that triggers the
change. This avoids head-of-line blocking around transitions between
keys without relying on trial decryption.
The following transitions are defined:
o The client transitions to using 0-RTT keys after sending the
ClientHello. This causes the KEY_PHASE bit on packets sent by the
client to be set to 1.
o The server transitions to using 0-RTT keys before sending the
ServerHello, but only if the early data from the client is
accepted. This transition causes the KEY_PHASE bit on packets
sent by the server to be set to 1. If the server rejects 0-RTT
data, the server's handshake messages are sent without QUIC-level
record protection with a KEY_PHASE of 0. TLS handshake messages
will still be protected by TLS record protection based on the TLS
handshake traffic keys.
o The server transitions to using 1-RTT keys after sending its
Finished message. This causes the KEY_PHASE bit to be set to 0 if
early data was accepted, and 1 if the server rejected early data.
o The client transitions to 1-RTT keys after sending its Finished
message. Subsequent messages from the client will then have a
KEY_PHASE of 0 if 0-RTT data was sent, and 1 otherwise.
o Both peers start sending messages protected by a new key
immediately after sending a TLS KeyUpdate message. The value of
the KEY_PHASE bit is changed each time.
At each point, both keying material (see Section 4.2) and the AEAD
function used by TLS is interchanged with the values that are
currently in use for protecting outbound packets. Once a change of
keys has been made, packets with higher sequence numbers MUST use the
new keying material until a newer set of keys (and AEAD) are used.
The exception to this is that retransmissions of TLS handshake
packets MUST use the keys that they were originally protected with.
Once a packet protected by a new key has been received, a recipient
SHOULD retain the previous keys for a short period. Retaining old
keys allows the recipient to decode reordered packets around a change
in keys. Keys SHOULD be discarded when an endpoints has received all
packets with sequence numbers lower than the lowest sequence number
used for the new key, or when it determines that reordering of those
packets is unlikely. 0-RTT keys SHOULD be retained until the
handshake is complete.
The KEY_PHASE bit does not directly indicate which keys are in use.
Depending on whether 0-RTT data was sent and accepted, packets
protected with keys derived from the same secret might be marked with
different KEY_PHASE values.
4.1.1. Retransmission of TLS Handshake Messages
TLS handshake messages need to be retransmitted with the same level
of cryptographic protection that was originally used to protect them.
Newer keys cannot be used to protect QUIC packets that carry TLS
messages. messages.
Prior to the completion of the TLS handshake, QUIC frames can be A client would be unable to decrypt retransmissions of a server's
exchanged. However, these frames are not authenticated or handshake messages that are protected using the 1-RTT keys, since the
confidentiality protected. Section 6 covers some of the implications calculation of the application data keys depends on the contents of
of this design. the handshake messages.
Alternative Design: TLS could be used to protect the entire QUIC This restriction means the creation of an exception to the
envelope. QUIC version negotiation could be subsumed by TLS and requirement to always use new keys for sending once they are
ALPN [RFC7301]. The only unprotected packets are then public available. A server MUST mark the retransmitted handshake messages
resets and ACK frames, both of which could be given first octet with the same KEY_PHASE as the original messages to allow a recipient
values that would easily distinguish them from other TLS packets. to distinguish the messages.
This requires that the QUIC sequence numbers be moved to the
outside of the record.
4. Mapping of QUIC to QUIC over TLS 4.1.2. Key Update
Several changes to the structure of QUIC are necessary to make a Once the TLS handshake is complete, the KEY_PHASE bit allows for the
layered design practical. processing of messages without having to receive the TLS KeyUpdate
message that triggers the key update. This allows endpoints to start
using updated keys immediately without the concern that a lost
KeyUpdate will cause their messages to be indecipherable to their
peer..
These changes produce the handshake shown in Figure 4. In this An endpoint MUST NOT initiate more than one key update at a time. A
handshake, QUIC STREAM frames on stream 1 carry the TLS handshake. new key update cannot be sent until the endpoint has received a
QUIC is responsible for ensuring that the handshake packets are re- matching KeyUpdate message from its peer; or, if the endpoint did not
sent in case of loss and that they can be ordered correctly. initiate the original key update, it has received an acknowledgment
of its own KeyUpdate.
QUIC operates without any record protection until the handshake This ensures that there are at most two keys to distinguish between
completes, just as TLS over TCP does not include record protection at any one time, for which the KEY_PHASE bit is sufficient.
for the handshake messages. Once complete, QUIC frames and forward
error control (FEC) messages are encapsulated in using TLS record
protection.
Client Server Initiating Peer Responding Peer
QUIC STREAM Frame <stream 1> @M KeyUpdate
ClientHello New Keys -> @N
+ QUIC Setup Parameters @N QUIC Frames
(Finished) --------> -------->
(Replayable QUIC Frames <any stream>) KeyUpdate @N
(end_of_early_data <1>) --------> <--------
QUIC STREAM Frame <1> -- Initiating Peer can initiate another KeyUpdate --
ServerHello @N Acknowledgment
{EncryptedExtensions} -------->
{ServerConfiguration} -- Responding Peer can initiate another KeyUpdate --
{Certificate}
{CertificateVerify}
{Finished}
<-------- [QUIC Frames/FEC]
QUIC STREAM Frame <1>
{Finished} -------->
[QUIC Frames/FEC] <-------> [QUIC Frames/FEC] Figure 4: Key Update
Figure 4: QUIC over TLS Handshake As shown in Figure 3 and Figure 4, there is never a situation where
there are more than two different sets of keying material that might
be received by a peer.
The remainder of this document describes the changes to QUIC and TLS A server cannot initiate a key update until it has received the
that allow the protocols to operate together. client's Finished message. Otherwise, packets protected by the
updated keys could be confused for retransmissions of handshake
messages. A client cannot initiate a key update until it has
received an acknowledgment that its Finished message has been
received.
4.1. Protocol and Version Negotiation Note: This models the key changes in the handshake as a key update
initiated by the server, with the Finished message in the place of
KeyUpdate.
The QUIC version negotiation mechanism is used to negotiate the 4.2. QUIC Key Expansion
version of QUIC that is used prior to the completion of the
handshake. However, this packet is not authenticated, enabling an
active attacker to force a version downgrade.
To ensure that a QUIC version downgrade is not forced by an attacker, The following table shows QUIC keys, when they are generated and the
version information is copied into the TLS handshake, which provides TLS secret from which they are derived:
integrity protection for the QUIC negotiation. This doesn't prevent
version downgrade during the handshake, though it does prevent a
connection from completing with a downgraded version, see
Section 6.1.
ISSUE: The QUIC version negotiation has poor performance in the +-------+----------------------+----------------------------+
event that a client is forced to downgrade from their preferred | Key | TLS Secret | Phase |
version. +-------+----------------------+----------------------------+
| 0-RTT | early_traffic_secret | "QUIC 0-RTT key expansion" |
| | | |
| 1-RTT | traffic_secret_N | "QUIC 1-RTT key expansion" |
+-------+----------------------+----------------------------+
4.2. Source Address Validation 0-RTT keys are those keys that are used in resumed connections prior
to the completion of the TLS handshake. Data sent using 0-RTT keys
might be replayed and so has some restrictions on its use, see
Section 5.2. 0-RTT keys are used after sending or receiving a
ClientHello.
QUIC implementations describe a source address token. This is an 1-RTT keys are used after the TLS handshake completes. There are
opaque blob that a server provides to clients when they first use a potentially multiple sets of 1-RTT keys; new 1-RTT keys are created
given source address. The client returns this token in subsequent by sending a TLS KeyUpdate message. 1-RTT keys are used after
messages as a return routeability check. That is, the client returns sending a Finished or KeyUpdate message.
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 The complete key expansion uses the same process for key expansion as
included in the TLS 1.3 configuration identifier for 0-RTT defined in Section 7.3 of [I-D.ietf-tls-tls13]. For example, the
handshakes. Servers that use 0-RTT are advised to provide new Client Write Key for the data sent immediately after sending the TLS
configuration identifiers after every handshake to avoid passive Finished message is:
linkability of connections from the same client.
A server that is under load might include the same information in the label = "QUIC 1-RTT key expansion, client write key"
cookie extension/field of a HelloRetryRequest. (Note: the current client_write = HKDF-Expand-Label(traffic_secret_0, label,
version of TLS 1.3 does not include the ability to include a cookie "", key_length)
in HelloRetryRequest.)
5. Record Protection This results in a label input to HKDF that includes a two-octet
length field, the string "TLS 1.3, QUIC 1-RTT key expansion, client
write key" and a zero octet.
Each TLS record is encapsulated in the QUIC envelope. This provides The QUIC record protection initially starts without keying material.
length information, which means that the length field can be dropped When the TLS state machine produces the corresponding secret, new
from the TLS record. keys are generated from the TLS connection and used to protect the
QUIC record protection.
The sequence number used by TLS record protection is changed to deal The Authentication Encryption with Associated Data (AEAD) [RFC5116]
with the potential for packets to be dropped or lost. The QUIC function used is the same one that is negotiated for use with the TLS
sequence number is used in place of the monotonically increasing TLS connection. For example, if TLS is using the
record sequence number. This means that the TLS record protection TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, the AEAD_AES_128_GCM
employed is closer to DTLS in both its form and the guarantees that function is used.
are provided.
QUIC has a single, contiguous sequence number space. In comparison, 4.3. QUIC AEAD application
TLS restarts its sequence number each time that record protection
keys are changed. The sequence number restart in TLS ensures that a
compromise of the current traffic keys does not allow an attacker to
truncate the data that is sent after a key update by sending
additional packets under the old key (causing new packets to be
discarded).
QUIC does not rely on there being a continuous sequence of Regular QUIC packets are protected by an AEAD [RFC5116]. Version
application data packets; QUIC uses authenticated repair mechansims negotiation and public reset packets are not protected.
that operate above the layer of encryption. QUIC can therefore
operate without restarting sequence numbers.
5.1. TLS Handshake Encryption Once TLS has provided a key, the contents of regular QUIC packets
immediately after any TLS messages have been sent are protected by
the AEAD selected by TLS.
TLS 1.3 adds encryption for handshake messages. This introduces an The key, K, for the AEAD is either the Client Write Key or the Server
additional transition between different record protection keys during Write Key, derived as defined in Section 4.2.
the handshake. A consequence of this is that it becomes more
important to explicitly identify the transition from one set of keys
to the next (see Section 5.2).
5.2. Key Update The nonce, N, for the AEAD is formed by combining either the Client
Write IV or Server Write IV with the sequence numbers. The 48 bits
of the reconstructed QUIC sequence number (see Section 4.4) in
network byte order is left-padded with zeros to the N_MAX parameter
of the AEAD (see Section 4 of [RFC5116]). The exclusive OR of the
padded sequence number and the IV forms the AEAD nonce.
Each time that the TLS record protection keys are changed, the The associated data, A, for the AEAD is an empty sequence.
message initiating the change could be lost. This results in
subsequent packets being indecipherable to the peer that receives
them. Key changes happen at the conclusion of the handshake and and
immediately after a KeyUpdate message.
TLS relies on an ordered, reliable transport and therefore provides The input plaintext, P, for the AEAD is the contents of the QUIC
no other mechanism to ensure that a peer receives the message frame following the packet number, as described in
initiating a key change prior to receiving the subsequent messages [I-D.hamilton-quic-transport-protocol]
that are protected using the new key. A similar mechanism here would
introduce head-of-line blocking.
The simplest solution here is to steal a single bit from the The output ciphertext, C, of the AEAD is transmitted in place of P.
unprotected part of the QUIC header that signals key updates, similar
to how DTLS signals the epoch on each packet. The epoch bit is
encoded into 0x80 of the QUIC public flags.
Each time the epoch bit changes, an attempt is made to update the Prior to TLS providing keys, no record protection is performed and
keys used to read. Peers are prohibited from sending multiple the plaintext, P, is transmitted unmodified.
KeyUpdate messages until they see a reciprocal KeyUpdate to prevent
the chance that a transition is undetected as a result of two changes
in this bit.
The transition from cleartext to encrypted packets is exempt from Note: QUIC defined a null-encryption that had an additional, hash-
this limit of one key change. Two key changes occur during the based checksum for cleartext packets. This might be added here,
handshake. The server sends packets in the clear, plus packets but it is more complex.
protected using handshake and application data keys. With only a
single bit available to discriminate between keys, packets protected
with the application data keys will have the same bit value as
cleartext packets. This condition will be easily identified and
handled, likely by discarding the application data, since the
encrypted packets will be highly unlikely to be valid.
5.3. Sequence Number Reconstruction 4.4. Sequence Number Reconstruction
Each peer maintains a 48-bit send sequence number that is incremented Each peer maintains a 48-bit sequence number that is incremented with
with each packet that is sent (even retransmissions). The least every packet that is sent, including retransmissions. The least
significant 8-, 16-, 32-, or 48-bits of this number is encoded in the significant 8-, 16-, 32-, or 48-bits of this number is encoded in the
QUIC sequence number field in every packet. A 16-bit send epoch QUIC sequence number field in every packet.
number is maintained; the epoch is incremented each time new record
protection keying material is used. The least significant bit of the
epoch number is encoded into the epoch bit (0x80) of the QUIC public
flags.
A receiver maintains the same values, but recovers values based on A receiver maintains the same values, but recovers values based on
the packets it receives. This is based on the sequence number of the packets it receives. This is based on the sequence number of
packets that it has received. A simple scheme predicts the receive packets that it has received. A simple scheme predicts the receive
sequence number of an incoming packet by incrementing the sequence sequence number of an incoming packet by incrementing the sequence
number of the most recent packet to be successfully decrypted by one number of the most recent packet to be successfully decrypted by one
and expecting the sequence number to be within a range centered on and expecting the sequence number to be within a range centered on
that value. The receive epoch value is incremented each time that that value.
the epoch bit (0x80) changes.
The sequence number used for record protection is the 64-bit value
obtained by concatenating the epoch and sequence number, both in
network byte order.
5.4. Alternative Design: Exporters
An exporter could be used to provide keying material for a QUIC-
specific record protection. This could draw on the selected cipher
suite and the TLS record protection design so that the overall effort
required to design and analyze is kept minimal.
One concern with using exporters is that TLS doesn't define an
exporter for use prior to the end of the handshake. That means the
creation of a special exporter for use in protecting 0-RTT data.
That's a pretty sharp object to leave lying around, and it's not
clear what the properties we could provide. (That doesn't mean that
there wouldn't be demand for such a thing, the possibility has
already been raised.)
An exporter-based scheme might opt not to use the handshake traffic A more sophisticated algorithm can almost double the search space by
keys to protect QUIC packets during the handshake, relying instead on checking backwards from the most recent sequence for a received (or
separate protection for the TLS handshake records. This complicates abandoned) packet. If a packet was received, then the packet
implementations somewhat, so an exporter might still be used. contains a sequence number that is greater than the most recent
sequence number. If no such packet was found, the number is assumed
to be in the smaller window centered on the next sequence number, as
in the simpler scheme.
In the end, using an exporter doesn't alter the design significantly. Note: QUIC has a single, contiguous sequence number space. In
Given the risks, a modification to the record protocol is probably comparison, TLS restarts its sequence number each time that record
safer. protection keys are changed. The sequence number restart in TLS
ensures that a compromise of the current traffic keys does not
allow an attacker to truncate the data that is sent after a key
update by sending additional packets under the old key (causing
new packets to be discarded). QUIC does not assume a reliable
transport and is therefore required to handle attacks where
packets are dropped in other ways. TLS maintains a separate
sequence number that is used for record protection on the
connection that is hosted on stream 1. This sequence number is
reset according to the rules in the TLS protocol.
6. Pre-handshake QUIC Messages 5. Pre-handshake QUIC Messages
Implementations MUST NOT exchange data on any stream other than Implementations MUST NOT exchange data on any stream other than
stream 1 prior to the TLS handshake completing. However, QUIC stream 1 prior to the completion of the TLS handshake. However, QUIC
requires the use of several types of frame for managing loss requires the use of several types of frame for managing loss
detection and recovery. In addition, it might be useful to use the detection and recovery. In addition, it might be useful to use the
data acquired during the exchange of unauthenticated messages for data acquired during the exchange of unauthenticated messages for
congestion management. congestion management.
This section generally only applies to TLS handshake messages from
both peers and acknowledgments of the packets carrying those
messages. In many cases, the need for servers to provide
acknowledgments is minimal, since the messages that clients send are
small and implicitly acknowledged by the server's responses.
The actions that a peer takes as a result of receiving an The actions that a peer takes as a result of receiving an
unauthenticated packet needs tobe limited. In particular, state unauthenticated packet needs to be limited. In particular, state
established by these packets cannot be retained once record established by these packets cannot be retained once record
protection commences. protection commences.
There are several approaches possible for dealing with There are several approaches possible for dealing with
unauthenticated packets prior to handshake completion: unauthenticated packets prior to handshake completion:
o discard and ignore them o discard and ignore them
o use them, but reset any state that is established once the o use them, but reset any state that is established once the
handshake completes handshake completes
skipping to change at page 11, line 39 skipping to change at page 14, line 25
o save them and use them when they can be properly authenticated o save them and use them when they can be properly authenticated
o treat them as a fatal error o treat them as a fatal error
Different strategies are appropriate for different types of data. Different strategies are appropriate for different types of data.
This document proposes that all strategies are possible depending on This document proposes that all strategies are possible depending on
the type of message. the type of message.
o Transport parameters and options are made usable and authenticated o Transport parameters and options are made usable and authenticated
as part of the TLS handshake (see Section 6.1). as part of the TLS handshake (see Section 6.2).
o Most unprotected messages are treated as fatal errors when o Most unprotected messages are treated as fatal errors when
received except for the small number necessary to permit the received except for the small number necessary to permit the
handshake to complete (see Section 6.2). handshake to complete (see Section 5.1).
o Protected packets can be discarded, but can be saved and later
used (see Section 6.3).
6.1. QUIC Extension
A client describes characteristics of the transport protocol it
intends to conduct with the server in a new QUIC-specific extension
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 TLS, but can be passed to the QUIC
protocol as initialization parmeters.
The "quic_parameters" extension contains a declarative set of
parameters that establish QUIC operating parameters and constrain the
behaviour of a peer. The connection identifier and version are first
negotiated using QUIC, and are included in the TLS handshake in order
to provide integrity protection.
enum {
receive_buffer(0),
(65535)
} QuicTransportParameterType;
struct {
QuicTransportParameterType type;
uint32 value;
} QuicTransportParameter;
uint32 QuicVersion;
enum {
(65535)
} QuicOption;
struct {
uint64 connection_id;
QuicVersion quic_version;
QuicVersion supported_quic_versions<0..2^8-1>;
uint32 connection_initial_window;
uint32 stream_initial_window;
uint32 implicit_shutdown_timeout;
QuicTransportParameter transport_parameters<0..2^16-1>;
QuicOption options<0..2^8-2>;
} QuicParametersExtension;
This extension MUST be included if a QUIC version is negotiated. A
server MUST NOT negotiate QUIC if this extension is not present.
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, 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 parameters are:
connection_id: The 64-bit connection identifier for the connection,
as selected by the client.
quic_version: The currently selected QUIC version that is used for
the connection. This is the version negotiated using the
unauthenticated QUIC version negotiation (Section 4.1).
supported_quic_versions: This is a list of supported QUIC versions
for each peer. A client sends an empty list if the version of
QUIC being used is their preferred version; however, a client MUST
include their preferred version if this was not negotiated using
QUIC version negotiation. A server MUST include all versions that
it supports in this list.
connection_initial_window: The initial value for the connection flow
control window for the endpoint, in octets.
connection_initial_window: The initial value for the flow control
window of new streams created by the peer endpoint, in octets.
implicit_shutdown_timeout: The time, in seconds, that a connection
can remain idle before being implicitly shutdown.
transport_parameters: A list of parameters for the QUIC connection,
expressed as key-value pairs of arbitrary length. The
QuicTransportParameterType identifies each parameter; duplicate
types are not permitted and MUST be rejected with a fatal
illegal_parameter alert. Type values are taken from a single
space that is shared by all QUIC versions.
ISSUE: There is currently no way to update the value of
parameters once the connection has started. QUIC crypto
provided a SCFG message that could be sent after the connection
was established.
options: 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. 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.
Note: This sort of optional behaviour seems like it could be o Protected packets can either be discarded or saved and later used
accommodated adequately by defining new versions of QUIC for (see Section 5.3).
each experiment. However, as an evolving protocol, multiple
experiments need to be conducted concurrently and continuously.
The options parameter provides a flexible way to regulate which
experiments are enabled on a per-connection basis.
6.2. Unprotected Frames Prior to Handshake Completion 5.1. Unprotected Frames Prior to Handshake Completion
This section describes the handling of messages that are sent and This section describes the handling of messages that are sent and
received prior to the completion of the TLS handshake. received prior to the completion of the TLS handshake.
Sending and receiving unprotected messages is hazardous. Unless Sending and receiving unprotected messages is hazardous. Unless
expressly permitted, receipt of an unprotected message of any kind expressly permitted, receipt of an unprotected message of any kind
MUST be treated as a fatal error. MUST be treated as a fatal error.
6.2.1. STREAM Frames 5.1.1. STREAM Frames
"STREAM" frames for stream 1 are permitted. These carry the TLS "STREAM" frames for stream 1 are permitted. These carry the TLS
handshake messages. handshake messages.
Receiving unprotected "STREAM" frames that do not contain TLS Receiving unprotected "STREAM" frames for other streams MUST be
handshake messages MUST be treated as a fatal error. treated as a fatal error.
6.2.2. ACK Frames 5.1.2. ACK Frames
"ACK" frames are permitted prior to the handshake being complete. "ACK" frames are permitted prior to the handshake being complete.
However, an unauthenticated "ACK" frame can only be used to obtain Information learned from "ACK" frames cannot be entirely relied upon,
NACK ranges. Timestamps MUST NOT be included in an unprotected ACK since an attacker is able to inject these packets. Timing and packet
frame, since these might be modified by an attacker with the intent retransmission information from "ACK" frames is critical to the
of altering congestion control response. Information on FEC-revived functioning of the protocol, but these frames might be spoofed or
packets is redundant, since use of FEC in this phase is prohibited. altered.
"ACK" frames MAY be sent a second time once record protection is Endpoints MUST NOT use an unprotected "ACK" frame to acknowledge data
enabled. Once protected, timestamps can be included. that was protected by 0-RTT or 1-RTT keys. An endpoint MUST ignore
an unprotected "ACK" frame if it claims to acknowledge data that was
protected data. Such an acknowledgement can only serve as a denial
of service, since an endpoint that can read protected data is always
permitted to send protected data.
Editor's Note: This prohibition might be a little too strong, but An endpoint SHOULD use data from unprotected or 0-RTT-protected "ACK"
this is the only obviously safe option. If the amount of damage frames only during the initial handshake and while they have
that an attacker can do by modifying timestamps is limited, then insufficient information from 1-RTT-protected "ACK" frames. Once
it might be OK to permit the inclusion of timestamps. Note that sufficient information has been obtained from protected messages,
an attacker need not be on-path to inject an ACK. information obtained from less reliable sources can be discarded.
6.2.3. WINDOW_UPDATE Frames 5.1.3. WINDOW_UPDATE Frames
Sending a "WINDOW_UPDATE" on stream 1 might be necessary to permit "WINDOW_UPDATE" frames MUST NOT be sent unprotected.
the completion of the TLS handshake, particularly in cases where the
certification path is lengthy. To avoid stalling due to flow control
exhaustion, "WINDOW_UPDATE" frames with stream 1 are permitted.
Receiving a "WINDOW_UPDATE" frame on streams other than 1 MUST be Though data is exchanged on stream 1, the initial flow control window
treated as a fatal error. is is sufficiently large to allow the TLS handshake to complete.
This limits the maximum size of the TLS handshake and would prevent a
server or client from using an abnormally large certificate chain.
Stream 1 is exempt from the connection-level flow control window. Stream 1 is exempt from the connection-level flow control window.
The position of the flow control window MUST be reset to defaults 5.1.4. Denial of Service with Unprotected Packets
once the TLS handshake is complete. This might result in the window
position for either the connection or stream 1 being smaller than the
number of octets that have been sent on those streams. A
"WINDOW_UPDATE" frame might therefore be necessary to prevent the
connection from being stalled.
Note: This is only potentially problematic for servers, who might Accepting unprotected - specifically unauthenticated - packets
need to send large certificate chains. In other cases, this is presents a denial of service risk to endpoints. An attacker that is
unlikely given that QUIC - like HTTP [RFC7230] - is a protocol able to inject unprotected packets can cause a recipient to drop even
where the server is unable to exercise the opportunity TLS protected packets with a matching sequence number. The spurious
presents to send first. packet shadows the genuine packet, causing the genuine packet to be
ignored as redundant.
If a server has a large certificate chain, or later modifications Once the TLS handshake is complete, both peers MUST ignore
or extensions to QUIC permit the server to send first, a client unprotected packets. The handshake is complete when the server
might reduce the chance of stalling due to flow control in this receives a client's Finished message and when a client receives an
first round trip by setting larger values for the initial stream acknowledgement that their Finished message was received. From that
and connection flow control windows using the "quic_parameters" point onward, unprotected messages can be safely dropped. Note that
extension (Section 6.1). the client could retransmit its Finished message to the server, so
the server cannot reject such a message.
Editor's Note: Unlike "ACK", the prohibition on "WINDOW_UPDATE" is Since only TLS handshake packets and acknowledgments are sent in the
much less of an imposition on implementations. And, given that a clear, an attacker is able to force implementations to rely on
spurious "WINDOW_UPDATE" might be used to create a great deal of retransmission for packets that are lost or shadowed. Thus, an
memory pressure on an endpoint, the restriction seems justifiable. attacker that intends to deny service to an endpoint has to drop or
Besides, I understand this one a lot better. shadow protected packets in order to ensure that their victim
continues to accept unprotected packets. The ability to shadow
packets means that an attacker does not need to be on path.
6.2.4. FEC Packets ISSUE: This would not be an issue if QUIC had a randomized starting
sequence number. If we choose to randomize, we fix this problem
and reduce the denial of service exposure to on-path attackers.
The only possible problem is in authenticating the initial value,
so that peers can be sure that they haven't missed an initial
message.
FEC packets MUST NOT be sent prior to completing the TLS handshake. In addition to denying endpoints messages, an attacker to generate
Endpoints MUST treat receipt of an unprotected FEC packet as a fatal packets that cause no state change in a recipient. See Section 7.2
error. for a discussion of these risks.
6.3. Protected Frames Prior to Handshake Completion To avoid receiving TLS packets that contain no useful data, a TLS
implementation MUST reject empty TLS handshake records and any record
that is not permitted by the TLS state machine. Any TLS application
data or alerts - other than a single end_of_early_data at the
appropriate time - that is received prior to the end of the handshake
MUST be treated as a fatal error.
5.2. Use of 0-RTT Keys
If 0-RTT keys are available, the lack of replay protection means that
restrictions on their use are necessary to avoid replay attacks on
the protocol.
A client MUST only use 0-RTT keys to protect data that is idempotent.
A client MAY wish to apply additional restrictions on what data it
sends prior to the completion of the TLS handshake. A client
otherwise treats 0-RTT keys as equivalent to 1-RTT keys.
A client that receives an indication that its 0-RTT data has been
accepted by a server can send 0-RTT data until it receives all of the
server's handshake messages. A client SHOULD stop sending 0-RTT data
if it receives an indication that 0-RTT data has been rejected. In
addition to a ServerHello without an early_data extension, an
unprotected handshake message with a KEY_PHASE bit set to 0 indicates
that 0-RTT data has been rejected.
A client SHOULD send its end_of_early_data alert only after it has
received all of the server's handshake messages. Alternatively
phrased, a client is encouraged to use 0-RTT keys until 1-RTT keys
become available. This prevents stalling of the connection and
allows the client to send continuously.
A server MUST NOT use 0-RTT keys to protect anything other than TLS
handshake messages. Servers therefore treat packets protected with
0-RTT keys as equivalent to unprotected packets in determining what
is permissible to send. A server protects handshake messages using
the 0-RTT key if it decides to accept a 0-RTT key. A server MUST
still include the early_data extension in its ServerHello message.
This restriction prevents a server from responding to a request using
frames protected by the 0-RTT keys. This ensures that all
application data from the server are always protected with keys that
have forward secrecy. However, this results in head-of-line blocking
at the client because server responses cannot be decrypted until all
the server's handshake messages are received by the client.
5.3. Protected Frames Prior to Handshake Completion
Due to reordering and loss, protected packets might be received by an Due to reordering and loss, protected packets might be received by an
endpoint before the final handshake messages are received. If these endpoint before the final handshake messages are received. If these
can be decrypted successfully, such packets MAY be stored and used can be decrypted successfully, such packets MAY be stored and used
once the handshake is complete. once the handshake is complete.
Unless expressly permitted below, encrypted packets MUST NOT be used Unless expressly permitted below, encrypted packets MUST NOT be used
prior to completing the TLS handshake, in particular the receipt of a prior to completing the TLS handshake, in particular the receipt of a
valid Finished message and any authentication of the peer. If valid Finished message and any authentication of the peer. If
packets are processed prior to completion of the handshake, an packets are processed prior to completion of the handshake, an
skipping to change at page 17, line 12 skipping to change at page 17, line 49
TLS handshake messages are covered by record protection during the TLS handshake messages are covered by record protection during the
handshake, once key agreement has completed. This means that handshake, once key agreement has completed. This means that
protected messages need to be decrypted to determine if they are TLS protected messages need to be decrypted to determine if they are TLS
handshake messages or not. Similarly, "ACK" and "WINDOW_UPDATE" handshake messages or not. Similarly, "ACK" and "WINDOW_UPDATE"
frames might be needed to successfully complete the TLS handshake. frames might be needed to successfully complete the TLS handshake.
Any timestamps present in "ACK" frames MUST be ignored rather than Any timestamps present in "ACK" frames MUST be ignored rather than
causing a fatal error. Timestamps on protected frames MAY be saved causing a fatal error. Timestamps on protected frames MAY be saved
and used once the TLS handshake completes successfully. and used once the TLS handshake completes successfully.
An endpoint MUST save the last protected "WINDOW_UPDATE" frame it An endpoint MAY save the last protected "WINDOW_UPDATE" frame it
receives for each stream and apply the values once the TLS handshake receives for each stream and apply the values once the TLS handshake
completes. completes. Failing to do this might result in temporary stalling of
affected streams.
Editor's Note: Ugh. This last one is pretty ugly. Maybe we should 6. QUIC-Specific Additions to the TLS Handshake
just make the TLS handshake exempt from flow control up to the
Finished message. Then we can prohibit unauthenticated
"WINDOW_UPDATE" messages. We would still likely want to account
for the packets sent and received, since to do otherwise would
create some hairy special cases. That means that stalling is
possible, but it means that we can avoid ugly rules like the
above.
7. Connection ID QUIC uses the TLS handshake for more than just negotiation of
cryptographic parameters. The TLS handshake validates protocol
version selection, provides preliminary values for QUIC transport
parameters, and allows a server to perform return routeability checks
on clients.
The QUIC connection identifier serves to identify a connection and to 6.1. Protocol and Version Negotiation
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 The QUIC version negotiation mechanism is used to negotiate the
also allows a client to send 0-RTT application data. This mode could version of QUIC that is used prior to the completion of the
be used to continue a connection rather than rely on a publicly handshake. However, this packet is not authenticated, enabling an
visible correlator. This only requires that servers produce a new active attacker to force a version downgrade.
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 To ensure that a QUIC version downgrade is not forced by an attacker,
this is also more robust. If the new point of attachment results in version information is copied into the TLS handshake, which provides
contacting a new server instance - one that lacks the session state - integrity protection for the QUIC negotiation. This does not prevent
then a fallback is easy. version downgrade during the handshake, though it means that such a
downgrade causes a handshake failure.
The main drawback with a clean restart or anything resembling a Protocols that use the QUIC transport MUST use Application Layer
restart is that accumulated state can be lost. Aside from progress Protocol Negotiation (ALPN) [RFC7301]. The ALPN identifier for the
on incomplete requests, the state of the HPACK header compression protocol MUST be specific to the QUIC version that it operates over.
table could be quite valuable. Existing QUIC implementations use the When constructing a ClientHello, clients MUST include a list of all
connection ID to route packets to the server that is handling the the ALPN identifiers that they support, regardless of whether the
connection, which avoids this sort of problem. QUIC version that they have currently selected supports that
protocol.
A lightweight state resurrection extension might be used to avoid Servers SHOULD select an application protocol based solely on the
having to recreate any expensive state. 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 MUST
either send a QUIC version negotiation packet if this is possible, or
fail the connection otherwise.
8. Security Considerations 6.2. QUIC Extension
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 frames. This
document does not define that extension.
6.3. Source Address Validation
QUIC implementations describe a source address token. This is an
opaque blob that a server might provide 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. This prevents the server from
being used in packet reflection attacks (see Section 7.1).
A source address token is opaque and consumed only by the server.
Therefore it can be included in the TLS 1.3 pre-shared key identifier
for 0-RTT handshakes. Servers that use 0-RTT are advised to provide
new pre-shared key identifiers after every handshake to avoid
linkability of connections by passive observers. Clients MUST use a
new pre-shared key identifier for every connection that they
initiate; if no pre-shared key identifier is available, then
resumption is not possible.
A server that is under load might include a source address token in
the cookie extension of a HelloRetryRequest. (Note: the current
version of TLS 1.3 does not include the ability to include a cookie
in HelloRetryRequest.)
6.4. Priming 0-RTT
QUIC uses TLS without modification. Therefore, it is possible to use
a pre-shared key that was obtained in a TLS connection over TCP to
enable 0-RTT in QUIC. Similarly, QUIC can provide a pre-shared key
that can be used to enable 0-RTT in TCP.
All the restrictions on the use of 0-RTT apply, and the certificate
MUST be considered valid for both connections, which will use
different protocol stacks and could use different port numbers. For
instance, HTTP/1.1 and HTTP/2 operate over TLS and TCP, whereas QUIC
operates over UDP.
Source address validation is not completely portable between
different protocol stacks. Even if the source IP address remains
constant, the port number is likely to be different. Packet
reflection attacks are still possible in this situation, though the
set of hosts that can initiate these attacks is greatly reduced. A
server might choose to avoid source address validation for such a
connection, or allow an increase to the amount of data that it sends
toward the client without source validation.
7. Security Considerations
There are likely to be some real clangers here eventually, but the There are likely to be some real clangers here eventually, but the
current set of issues is well captured in the relevant sections of current set of issues is well captured in the relevant sections of
the main text. the main text.
Never assume that because it isn't in the security considerations Never assume that because it isn't in the security considerations
section it doesn't affect security. Most of this document does. section it doesn't affect security. Most of this document does.
9. IANA Considerations 7.1. Packet Reflection Attack Mitigation
A small ClientHello that results in a large block of handshake
messages from a server can be used in packet reflection attacks to
amplify the traffic generated by an attacker.
Certificate caching [RFC7924] can reduce the size of the server's
handshake messages significantly.
A client SHOULD also pad [RFC7685] its ClientHello to at least 1024
octets (TODO: tune this value). A server is less likely to generate
a packet reflection attack if the data it sends is a small multiple
of the data it receives. A server SHOULD use a HelloRetryRequest if
the size of the handshake messages it sends is likely to exceed the
size of the ClientHello.
7.2. Peer Denial of Service
QUIC, TLS and HTTP/2 all contain a messages that have legitimate uses
in some contexts, but that can be abused to cause a peer to expend
processing resources without having any observable impact on the
state of the connection. If processing is disproportionately large
in comparison to the observable effects on bandwidth or state, then
this could allow a malicious peer to exhaust processing capacity
without consequence.
QUIC prohibits the sending of empty "STREAM" frames unless they are
marked with the FIN bit. This prevents "STREAM" frames from being
sent that only waste effort.
TLS records SHOULD always contain at least one octet of a handshake
messages or alert. Records containing only padding are permitted
during the handshake, but an excessive number might be used to
generate unnecessary work. Once the TLS handshake is complete,
endpoints SHOULD NOT send TLS application data records unless it is
to hide the length of QUIC records. QUIC packet protection does not
include any allowance for padding; padded TLS application data
records can be used to mask the length of QUIC frames.
While there are legitimate uses for some redundant packets,
implementations SHOULD track redundant packets and treat excessive
volumes of any non-productive packets as indicative of an attack.
8. IANA Considerations
This document has no IANA actions. Yet. This document has no IANA actions. Yet.
10. References 9. References
10.1. Normative References 9.1. Normative References
[I-D.hamilton-quic-transport-protocol]
Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC:
A UDP-Based Multiplexed and Secure Transport", draft-
hamilton-quic-transport-protocol-00 (work in progress),
July 2016.
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-11 (work in progress), Version 1.3", draft-ietf-tls-tls13-17 (work in progress),
December 2015. October 2016.
[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",
draft-tsvwg-quic-protocol-02 (work in progress), January
2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<http://www.rfc-editor.org/info/rfc5116>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <http://www.rfc-editor.org/info/rfc7301>. July 2014, <http://www.rfc-editor.org/info/rfc7301>.
10.2. Informative References 9.2. Informative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>. <http://www.rfc-editor.org/info/rfc793>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <http://www.rfc-editor.org/info/rfc7230>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <http://www.rfc-editor.org/info/rfc7258>. 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<http://www.rfc-editor.org/info/rfc7540>. <http://www.rfc-editor.org/info/rfc7540>.
[RFC7685] Langley, A., "A Transport Layer Security (TLS) ClientHello
Padding Extension", RFC 7685, DOI 10.17487/RFC7685,
October 2015, <http://www.rfc-editor.org/info/rfc7685>.
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", RFC 7924,
DOI 10.17487/RFC7924, July 2016,
<http://www.rfc-editor.org/info/rfc7924>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
Christian Huitema's knowledge of QUIC is far better than my own. Christian Huitema's knowledge of QUIC is far better than my own.
This would be even more inaccurate and useless if not for his This would be even more inaccurate and useless if not for his
assistance. This document has variously benefited from a long series assistance. This document has variously benefited from a long series
of discussions with Ryan Hamilton, Jana Iyengar, Adam Langley, of discussions with Jana Iyengar, Adam Langley, Roberto Peon, Eric
Roberto Peon, Ian Swett, and likely many others who are merely Rescorla, Ian Swett, and likely many others who are merely forgotten
forgotten by a faulty meat computer. by a faulty meat computer.
Authors' Addresses Authors' Addresses
Martin Thomson Martin Thomson
Mozilla Mozilla
Email: martin.thomson@gmail.com Email: martin.thomson@gmail.com
Ryan Hamilton Ryan Hamilton
Google Google
 End of changes. 107 change blocks. 
514 lines changed or deleted 658 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/