wdiff draft-thomson-quic-tls-00.txt draft-thomson-quic-tls-01.txt

Network Working Group M. Thomson
Internet-Draft Mozilla
Intended status: Standards Track R. Hamilton
Expires: September 22, 2016 April 28, 2017 Google
March 21,
October 25, 2016

Porting QUIC to

Using Transport Layer Security (TLS)
draft-thomson-quic-tls-00

Abstract

The QUIC experiment defines a custom security protocol. This was
necessary to gain handshake latency improvements. Secure QUIC
draft-thomson-quic-tls-01

Abstract

This document describes how that security protocol might Transport Layer Security (TLS) can be replaced with TLS.
used to secure QUIC.

Status of This Memo

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 22, 2016. April 28, 2017.

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.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Handshake Overview . . . . . . . . . . . . . . . . . . . 4
3. QUIC over TLS Structure . . in Stream 1 . . . . . . . . . . . . . . . . . 5
4. Mapping of QUIC to QUIC over TLS . . . . . . 5
3.1. Handshake and Setup Sequence . . . . . . . . 6
4.1. Protocol and Version Negotiation . . . . . . . . . 6
4. QUIC Record Protection . . . 7
4.2. Source Address Validation . . . . . . . . . . . . . . . . 8
5. Record Protection
4.1. Key Phases . . . . . . . . . . . . . . . . . . . . . . . 8
5.1.
4.1.1. Retransmission of TLS Handshake Encryption . . . . . . . . . . Messages . . . . . . 9
5.2.
4.1.2. Key Update . . . . . . . . . . . . . . . . . . . . . 10
4.2. QUIC Key Expansion . . 9
5.3. Sequence Number Reconstruction . . . . . . . . . . . . . 10
5.4. Alternative Design: Exporters . . . . 11
4.3. QUIC AEAD application . . . . . . . . . . 10
6. Pre-handshake QUIC Messages . . . . . . . . 12
4.4. Sequence Number Reconstruction . . . . . . . . . 11
6.1. QUIC Extension . . . . 12
5. Pre-handshake QUIC Messages . . . . . . . . . . . . . . . . . 11
6.2. 13
5.1. Unprotected Frames Prior to Handshake Completion . . . . 15
6.2.1. 14
5.1.1. STREAM Frames . . . . . . . . . . . . . . . . . . . . 15
6.2.2. 14
5.1.2. ACK Frames . . . . . . . . . . . . . . . . . . . . . 15
6.2.3.
5.1.3. WINDOW_UPDATE Frames . . . . . . . . . . . . . . . . 15
6.2.4. FEC
5.1.4. Denial of Service with Unprotected Packets . . . . . 15
5.2. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 16
6.3.
5.3. Protected Frames Prior to Handshake Completion . . . . . 16
7. Connection ID 17
6. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 18
6.1. Protocol and Version Negotiation . . . . . . . . . . . . 18
6.2. QUIC Extension . . . . 17
8. . . . . . . . . . . . . . . . . . 18
6.3. Source Address Validation . . . . . . . . . . . . . . . . 19
6.4. Priming 0-RTT . . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. 20
7.1. Packet Reflection Attack Mitigation . . . . . . . . . . . 20
7.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. 21
9.1. Normative References . . . . . . . . . . . . . . . . . . 18
10.2. 21
9.2. Informative References . . . . . . . . . . . . . . . . . 18 21
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 19 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 22

1. Introduction

QUIC [I-D.tsvwg-quic-protocol] [I-D.hamilton-quic-transport-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

This document describes how QUIC can be secured using Transport Layer
Security (TLS) version 1.3 [I-D.ietf-tls-tls13]. TLS 1.3 provides
critical latency improvements for connection establishment. establishment over
previous versions. Absent packet loss, most new connections can be
established with and secured within 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. TLS 1.3 uses a similar design and aims to provide
the same set of improvements.

This document describes how the standardized TLS 1.3 might serve as can act a
security layer for 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
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

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].

2. Protocol Overview

QUIC [I-D.tsvwg-quic-protocol] [I-D.hamilton-quic-transport-protocol] can be separated into
several modules:

1. The basic frame envelope describes the common packet layout.
This layer includes connection identification, version
negotiation, and includes the indicators markers that allow the framing,
public reset, framing and FEC modules
public reset to be identified.

2. The public reset is an unprotected frame packet that allows an
intermediary (an entity that is not part of the security context)
to request the termination of a QUIC connection.

3. The forward error correction (FEC) module provides redundant
entropy that allows for Version negotiation frames are used to be repaired in event agree on a common version
of loss. QUIC to use.

4. Framing comprises most of the QUIC protocol. Framing provides a
number of different types of frame, each with a specific purpose.
Framing supports frames for both congestion management and stream
multiplexing. Framing additionally provides a liveness testing
capability (the PING frame).

5. Crypto Encryption provides confidentiality and integrity protection for
frames. All frames are protected after based on keying material
derived from the handshake completes TLS connection running on stream 1. Prior to
this, data is protected with the 0-RTT keys.

6. Multiplexed streams are the primary payload of QUIC. These
provide reliable, in-order delivery of data and are used to carry
the encryption handshake and transport parameters (stream 1),
HTTP header fields (stream 3), and HTTP requests and responses.

Frames for managing multiplexing include those for creating and
destroying streams as well as flow control and priority frames.

7. Congestion management includes packet acknowledgment and other
signal required to ensure effective use of available link
capacity.

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.

The relative relationship of these components are pictorally
represented in Figure 1.

+----+------+

*HS = Crypto Handshake
+--------------------------------------------+

Figure 1: QUIC Structure

This document describes a replacement of defines 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.

2.1. Handshake Overview

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
data after one round trip and the server immediately after
receiving the first message from the client.

o A 0-RTT handshake in which the client uses information about the
server to send immediately. This data can be replayed by an
attacker so it MUST NOT carry a self-contained trigger for any
non-idempotent action.

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. options and details.

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:

o The server can respond to a ClientHello with a HelloRetryRequest,
which adds an additional round trip prior to the basic exchange.
This is needed if the server wishes to request a different key
exchange key from the client. HelloRetryRequest might is also be used to
verify that the client is correctly able to receive packets on the
address it claims to have (see Section 4.2). 6.3).

o A pre-shared key mode can be used for subsequent handshakes to
avoid public key operations. This might be is the basis for 0-RTT, 0-RTT data,
even if the remainder of the connection is protected by a new
Diffie-Hellman exchange.

3. QUIC over TLS Structure in Stream 1

QUIC completes its cryptographic handshake on stream 1, which means
that the negotiation of keying material happens within after the QUIC
protocol. QUIC over TLS does the same, relying on
protocol has started. This simplifies the ordered
delivery guarantees provided by use of TLS since QUIC is
able to ensure that the TLS handshake packets are delivered reliably
and in order.

+-----+---------+
| TLS | HTTP |
+-----+----------+------------+
| Streams | Congestion |
+----------------+------------+
| Frames |
| +------------+
| | FEC +--------+
| +----------+------------+ Public |
| | TLS Record Protection | Reset |
+-----+-----------------------+--------+
| Envelope |
+--------------------------------------+
| UDP |
+--------------------------------------+

Figure 3: QUIC over TLS

In this design the

QUIC envelope Stream 1 carries QUIC frames until the a complete TLS
handshake completes. After the handshake successfully completes connection. This includes the
key exchange, QUIC frames are then protected by
TLS record
protection.

QUIC stream 1 is used to exchange TLS handshake packets. layer in its entirety. QUIC provides for reliable and in-order in-
order delivery of the TLS handshake
messages. messages on this stream.

Prior to the completion of the TLS handshake, QUIC frames can be
exchanged. However, these frames are not authenticated or
confidentiality protected. Section 6 5 covers some of the implications
of this design.

Alternative Design: TLS could be used to protect the entire design and limitations on QUIC
envelope. operation during this phase.

Once complete, QUIC version negotiation could be subsumed by TLS and
ALPN [RFC7301]. The only unprotected packets frames are then public
resets and ACK frames, both of which could be given first octet
values that would easily distinguish them from other TLS packets.
This requires that the protected using QUIC sequence numbers be moved to the
outside of the record. record
protection, see Section 4. Mapping of QUIC to QUIC over TLS

Several changes to the structure

3.1. Handshake and Setup Sequence

The integration of QUIC are necessary to make with a
layered design practical.

These changes produce the TLS handshake is shown in more detail
in Figure 4. In this
handshake, 3. QUIC STREAM "STREAM" frames on stream 1 carry the TLS
handshake. QUIC is responsible for ensuring that the handshake
packets are re-
sent re-sent in case of loss and that they can be ordered
correctly.

QUIC operates without any record protection until the handshake
completes, just as TLS over TCP does not include record protection
for the handshake messages. Once complete, QUIC frames and forward
error control (FEC) messages are encapsulated in using TLS record
protection.

Client Server

@A QUIC STREAM Frame <stream 1> Frame(s) <1>:
ClientHello
+ QUIC Setup Parameters
(Finished)
-------->
(Replayable
0-RTT Key -> @B

@B QUIC STREAM Frame(s) <1>:
(Finished)
Replayable QUIC Frames <any stream>)
(end_of_early_data <1>) stream>
-------->

QUIC STREAM Frame <1> <1>: @B/A
ServerHello
{EncryptedExtensions}
{ServerConfiguration}
{Certificate}
{CertificateVerify}
{Finished}
{Handshake Messages}
<--------
1-RTT Key -> @C

QUIC Frames @C
<-------- [QUIC Frames/FEC]
@B QUIC STREAM Frame <1> Frame(s) <1>:
(end_of_early_data <1>)
{Finished}
-------->

[QUIC Frames/FEC]

@C QUIC Frames <-------> [QUIC Frames/FEC] QUIC Frames @C

Figure 4: 3: QUIC over TLS Handshake

The remainder of this document describes

In Figure 3, symbols mean:

o "<" and ">" enclose stream numbers.

o "@" indicates the changes to 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 allow are protected by the protocols to operate together.

4.1. Protocol and Version Negotiation

The QUIC version negotiation mechanism TLS
Handshake keys.

If 0-RTT is used to negotiate not possible, then the
version of QUIC that is used prior to client does not send frames
protected by the completion of 0-RTT key (@B). The only key transition on the
handshake. However, this packet
client is from cleartext (@A) to 1-RTT protection (@C).

If 0-RTT data is not authenticated, enabling an
active attacker accepted by the server, then the server sends
its handshake messages without protection (@A). The client still
transitions from @A to force a version downgrade.

To ensure that @B, but it can stop sending 0-RTT data and
progress immediately to 1-RTT data when it receives a cleartext
ServerHello.

4. QUIC version downgrade Record Protection

QUIC provides a record protection layer that is not forced responsible for
authenticated encryption of packets. The record protection layer
uses keys provided by an attacker,
version information is copied into the TLS handshake, which provides connection and authenticated encryption
to provide confidentiality and integrity protection for the content
of packets.

Different keys are used for QUIC negotiation. and TLS record protection. Having
separate QUIC and TLS record protection means that TLS records can be
protected by two different keys. This doesn't prevent
version downgrade during redundancy is maintained for
the handshake, though it does prevent a
connection from completing with a downgraded version, see
Section 6.1.

ISSUE: sake of simplicity.

4.1. Key Phases

The transition to use of a new QUIC version negotiation has poor performance in key occurs immediately after
sending the
event TLS handshake messages that produced the key transition.
Every time that a client new set of keys is forced to downgrade from their preferred
version.

4.2. Source Address Validation

QUIC implementations describe a source address token. This used for protecting outbound
messages, the KEY_PHASE bit in the public flags is an
opaque blob that a server provides to clients when they first use a
given source address. toggled. The client returns this token in subsequent
KEY_PHASE bit on unencrypted messages as a return routeability check. That is, the client returns
this token to prove that it is able to receive packets at 0.

The KEY_PHASE bit on the source
address that it claims.

Since this token public flags is opaque and consumed only by the server, it can be
included most significant bit
(0x80).

The KEY_PHASE bit allows a recipient to detect a change in keying
material without needing to receive the TLS 1.3 configuration identifier for 0-RTT
handshakes. Servers message that use 0-RTT triggers the
change. This avoids head-of-line blocking around transitions between
keys without relying on trial decryption.

The following transitions are advised defined:

o The client transitions to provide new
configuration identifiers using 0-RTT keys after every handshake sending the
ClientHello. This causes the KEY_PHASE bit on packets sent by the
client to avoid passive
linkability of connections 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 same client.

A server that client is under load might include
accepted. This transition causes the same information in KEY_PHASE bit on packets
sent by the
cookie extension/field of a HelloRetryRequest. (Note: server to be set to 1. If the current
version of TLS 1.3 does not include server rejects 0-RTT
data, the ability to include server's handshake messages are sent without QUIC-level
record protection with a cookie
in HelloRetryRequest.)

5. Record Protection

Each KEY_PHASE of 0. TLS handshake messages
will still be protected by TLS record is encapsulated in protection based on the QUIC envelope. TLS
handshake traffic keys.

o The server transitions to using 1-RTT keys after sending its
Finished message. This provides
length information, which means that causes the length field can KEY_PHASE bit to be dropped 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 record. KeyUpdate message. The sequence number 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 record protection is changed to deal interchanged with the potential values that are
currently in use for protecting outbound packets. Once a change of
keys has been made, packets to be dropped or lost. The QUIC with higher sequence number numbers MUST use the
new keying material until a newer set of keys (and AEAD) are used.
The exception to this is used in place that retransmissions of the monotonically increasing TLS
record sequence number. This means 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 TLS record protection
employed is closer previous keys for a short period. Retaining old
keys allows the recipient to DTLS decode reordered packets around a change
in both its form and the guarantees that
are provided.

QUIC keys. Keys SHOULD be discarded when an endpoints has a single, contiguous sequence number space. In comparison,
TLS restarts its received all
packets with sequence number each time that record protection
keys are changed. The numbers lower than the lowest sequence number restart in TLS ensures
used for the new key, or when it determines that a
compromise reordering of the current traffic those
packets is unlikely. 0-RTT keys SHOULD be retained until the
handshake is complete.

The KEY_PHASE bit does not allow an attacker to
truncate the directly indicate which keys are in use.
Depending on whether 0-RTT data that is was sent after a key update by sending
additional and accepted, packets under
protected with keys derived from the old key (causing new packets same secret might be marked with
different KEY_PHASE values.

4.1.1. Retransmission of TLS Handshake Messages

TLS handshake messages need to be
discarded). retransmitted with the same level
of cryptographic protection that was originally used to protect them.
Newer keys cannot be used to protect QUIC does not rely on there being packets that carry TLS
messages.

A client would be unable to decrypt retransmissions of a continuous sequence server's
handshake messages that are protected using the 1-RTT keys, since the
calculation of the application data packets; QUIC uses authenticated repair mechansims
that operate above keys depends on the layer contents of encryption. QUIC can therefore
operate without restarting sequence numbers.

5.1. TLS Handshake Encryption

TLS 1.3 adds encryption for
the handshake messages.

This introduces an
additional transition between different record protection keys during restriction means the handshake. A consequence creation of this is that it becomes more
important an exception to explicitly identify the transition from one set of
requirement to always use new keys for sending once they are
available. A server MUST mark the retransmitted handshake messages
with the same KEY_PHASE as the original messages to allow a recipient
to distinguish the next (see Section 5.2).

5.2. messages.

4.1.2. Key Update

Each time that

Once the TLS record protection keys are changed, handshake is complete, the KEY_PHASE bit allows for the
processing of messages without having to receive the TLS KeyUpdate
message initiating that triggers the change could be lost. key update. This results in
subsequent packets being indecipherable allows endpoints to start
using updated keys immediately without the peer concern that receives
them. Key changes happen a lost
KeyUpdate will cause their messages to be indecipherable to their
peer..

An endpoint MUST NOT initiate more than one key update at a time. A
new key update cannot be sent until the conclusion of the handshake and and
immediately after endpoint has received a
matching KeyUpdate message.

TLS relies on message from its peer; or, if the endpoint did not
initiate the original key update, it has received an ordered, reliable transport and therefore provides
no other mechanism acknowledgment
of its own KeyUpdate.

This ensures that there are at most two keys to ensure distinguish between
at any one time, for which the KEY_PHASE bit is sufficient.

Initiating Peer Responding Peer

@M KeyUpdate
New Keys -> @N
@N QUIC Frames
-------->
KeyUpdate @N
<--------
-- Initiating Peer can initiate another KeyUpdate --
@N Acknowledgment
-------->
-- Responding Peer can initiate another KeyUpdate --

Figure 4: Key Update

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 receives the message
initiating peer.

A server cannot initiate a key change prior to receiving update until it has received the subsequent messages
that are
client's Finished message. Otherwise, packets protected using by the new key.
updated keys could be confused for retransmissions of handshake
messages. A similar mechanism here would
introduce head-of-line blocking.

The simplest solution here is to steal client cannot initiate a single bit from key update until it has
received an acknowledgment that its Finished message has been
received.

Note: This models the
unprotected part of key changes in the QUIC header that signals handshake as a key updates, similar
to how DTLS signals update
initiated by the epoch on each packet. The epoch bit is
encoded into 0x80 of server, with the QUIC public flags.

Each time Finished message in the epoch bit changes, an attempt is made to update place of
KeyUpdate.

4.2. QUIC Key Expansion

The following table shows QUIC keys, when they are generated and the
TLS secret from which they are derived:

+-------+----------------------+----------------------------+
| Key | TLS Secret | Phase |
+-------+----------------------+----------------------------+
| 0-RTT | early_traffic_secret | "QUIC 0-RTT key expansion" |
| | | |
| 1-RTT | traffic_secret_N | "QUIC 1-RTT key expansion" |
+-------+----------------------+----------------------------+

0-RTT keys are those keys that are used in resumed connections prior
to read. Peers 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 prohibited from used after sending or receiving a
ClientHello.

1-RTT keys are used after the TLS handshake completes. There are
potentially multiple sets of 1-RTT keys; new 1-RTT keys are created
by sending a TLS KeyUpdate messages until they see message. 1-RTT keys are used after
sending a reciprocal Finished or KeyUpdate to prevent message.

The complete key expansion uses the chance that a transition is undetected same process for key expansion as a result
defined in Section 7.3 of two changes [I-D.ietf-tls-tls13]. For example, the
Client Write Key for the data sent immediately after sending the TLS
Finished message is:

label = "QUIC 1-RTT key expansion, client write key"
client_write = HKDF-Expand-Label(traffic_secret_0, label,
"", key_length)

This results in this bit. 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.

The transition QUIC record protection initially starts without keying material.
When the TLS state machine produces the corresponding secret, new
keys are generated from cleartext the TLS connection and used to encrypted packets protect the
QUIC record protection.

The Authentication Encryption with Associated Data (AEAD) [RFC5116]
function used is exempt from
this limit of the same one key change. Two key changes occur during that is negotiated for use with the
handshake. The server sends packets in TLS
connection. For example, if TLS is using the clear, plus
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, the AEAD_AES_128_GCM
function is used.

4.3. QUIC AEAD application

Regular QUIC packets are protected using handshake by an AEAD [RFC5116]. Version
negotiation and application data keys. With only public reset packets are not protected.

Once TLS has provided a
single bit available to discriminate between keys, key, the contents of regular QUIC packets
immediately after any TLS messages have been sent are protected
with by
the application data keys will have AEAD selected by TLS.

The key, K, for the same bit value AEAD is either the Client Write Key or the Server
Write Key, derived as
cleartext packets. This condition will be easily identified and
handled, likely defined in Section 4.2.

The nonce, N, for the AEAD is formed by discarding combining either the application 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.

The associated data, since A, for the
encrypted packets will be highly unlikely AEAD is an empty sequence.

The input plaintext, P, for the AEAD is the contents of the QUIC
frame following the packet number, as described in
[I-D.hamilton-quic-transport-protocol]

The output ciphertext, C, of the AEAD is transmitted in place of P.

Prior to TLS providing keys, no record protection is performed and
the plaintext, P, is transmitted unmodified.

Note: QUIC defined a null-encryption that had an additional, hash-
based checksum for cleartext packets. This might be valid.

5.3. added here,
but it is more complex.

4.4. Sequence Number Reconstruction

Each peer maintains a 48-bit send sequence number that is incremented with each
every packet that is sent (even retransmissions). sent, including retransmissions. The least
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
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
the packets it receives. This is based on the sequence number of
packets that it has received. A simple scheme predicts the receive
sequence number of an incoming packet by incrementing the sequence
number of the most recent packet to be successfully decrypted by one
and expecting the sequence number to be within a range centered on
that value. The receive epoch value is incremented each time that
the epoch bit (0x80) changes.

The sequence number used for record protection is

A more sophisticated algorithm can almost double the 64-bit value
obtained search space by concatenating
checking backwards from the epoch and most recent 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 received (or
abandoned) packet. If a packet was received, then the TLS record protection design so packet
contains a sequence number that the overall effort
required to design and analyze is kept minimal.

One concern with using exporters greater than the most recent
sequence number. If no such packet was found, the number is that TLS doesn't define an
exporter for use prior assumed
to be in the end of smaller window centered on the handshake. That means next sequence number, as
in the
creation of simpler scheme.

Note: QUIC has a special exporter for use single, contiguous sequence number space. In
comparison, TLS restarts its sequence number each time that record
protection keys are changed. The sequence number restart 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 TLS
ensures that
there wouldn't be demand for such a thing, compromise of the possibility has
already been raised.)

An exporter-based scheme might opt current traffic keys does not
allow an attacker to use truncate the handshake traffic
keys data that is sent after a key
update by sending additional packets under the old key (causing
new packets to protect be discarded). QUIC does not assume a reliable
transport and is therefore required to handle attacks where
packets during the handshake, relying instead on are dropped in other ways. TLS maintains a separate protection
sequence number that is used for record protection on the TLS handshake records.
connection that is hosted on stream 1. This complicates
implementations somewhat, so an exporter might still be used.

In the end, using an exporter doesn't alter the design significantly.
Given the risks, a modification sequence number is
reset according to the record protocol is probably
safer.

6. rules in the TLS protocol.

5. Pre-handshake QUIC Messages

Implementations MUST NOT exchange data on any stream other than
stream 1 prior to the completion of the TLS handshake completing. handshake. However, QUIC
requires the use of several types of frame for managing loss
detection and recovery. In addition, it might be useful to use the
data acquired during the exchange of unauthenticated messages for
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
unauthenticated packet needs tobe to be limited. In particular, state
established by these packets cannot be retained once record
protection commences.

There are several approaches possible for dealing with
unauthenticated packets prior to handshake completion:

o discard and ignore them

o use them, but reset any state that is established once the
handshake completes

o use them and authenticate them afterwards; failing the handshake
if they can't be authenticated

o save them and use them when they can be properly authenticated

o treat them as a fatal error

Different strategies are appropriate for different types of data.
This document proposes that all strategies are possible depending on
the type of message.

o Transport parameters and options are made usable and authenticated
as part of the TLS handshake (see Section 6.1). 6.2).

o Most unprotected messages are treated as fatal errors when
received except for the small number necessary to permit the
handshake to complete (see Section 6.2). 5.1).

o Protected packets can either be discarded, but can be discarded or 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
accommodated adequately by defining new versions of QUIC for
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. 5.3).

5.1. Unprotected Frames Prior to Handshake Completion

This section describes the handling of messages that are sent and
received prior to the completion of the TLS handshake.

Sending and receiving unprotected messages is hazardous. Unless
expressly permitted, receipt of an unprotected message of any kind
MUST be treated as a fatal error.

6.2.1.

5.1.1. STREAM Frames

"STREAM" frames for stream 1 are permitted. These carry the TLS
handshake messages.

Receiving unprotected "STREAM" frames that do not contain TLS
handshake messages for other streams MUST be
treated as a fatal error.

6.2.2.

5.1.2. ACK Frames

"ACK" frames are permitted prior to the handshake being complete.
However, an unauthenticated
Information learned from "ACK" frame can only be used to obtain
NACK ranges. Timestamps MUST NOT frames cannot be included in an unprotected ACK
frame, entirely relied upon,
since these might be modified by an attacker with the intent
of altering congestion control response. Information on FEC-revived
packets is redundant, since use of FEC in this phase is prohibited. able to inject these packets. Timing and packet
retransmission information from "ACK" frames MAY be sent a second time once record protection is
enabled. Once protected, timestamps can be included.

Editor's Note: This prohibition critical to the
functioning of the protocol, but these frames might be a little too strong, but
this is the spoofed or
altered.

Endpoints MUST NOT use an unprotected "ACK" frame to acknowledge data
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 obviously safe option. If the amount serve as a denial
of damage
that service, since an attacker endpoint that can do by modifying timestamps read protected data is limited, then
it might be OK always
permitted to permit send protected data.

An endpoint SHOULD use data from unprotected or 0-RTT-protected "ACK"
frames only during the inclusion of timestamps. Note that
an attacker need not initial handshake and while they have
insufficient information from 1-RTT-protected "ACK" frames. Once
sufficient information has been obtained from protected messages,
information obtained from less reliable sources can be on-path to inject an ACK.

6.2.3. discarded.

5.1.3. WINDOW_UPDATE Frames

Sending a

"WINDOW_UPDATE" frames MUST NOT be sent unprotected.

Though data is exchanged on stream 1 might be necessary 1, the initial flow control window
is is sufficiently large to permit allow the completion TLS handshake to complete.
This limits the maximum size 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
treated as handshake and would prevent a fatal error.
server or client from using an abnormally large certificate chain.

Stream 1 is exempt from the connection-level flow control window.

The position

5.1.4. Denial of Service with Unprotected Packets

Accepting unprotected - specifically unauthenticated - packets
presents a denial of service risk to endpoints. An attacker that is
able to inject unprotected packets can cause a recipient to drop even
protected packets with a matching sequence number. The spurious
packet shadows the flow control window genuine packet, causing the genuine packet to be
ignored as redundant.

Once the TLS handshake is complete, both peers MUST ignore
unprotected packets. The handshake is complete when the server
receives a client's Finished message and when a client receives an
acknowledgement that their Finished message was received. From that
point onward, unprotected messages can be reset safely dropped. Note that
the client could retransmit its Finished message to defaults
once the server, so
the server cannot reject such a message.

Since only TLS handshake packets and acknowledgments are sent in the
clear, an attacker is complete. able to force implementations to rely on
retransmission for packets that are lost or shadowed. Thus, an
attacker that intends to deny service to an endpoint has to drop or
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.

ISSUE: This might result 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 window
position initial value,
so that peers can be sure that they haven't missed an initial
message.

In addition to denying endpoints messages, an attacker to generate
packets that cause no state change in a recipient. See Section 7.2
for either a discussion of these risks.

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 connection TLS state machine. Any TLS application
data or stream 1 being smaller alerts - other than a single end_of_early_data at the
number
appropriate time - that is received prior to the end of octets 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 have been sent
restrictions on those streams. A
"WINDOW_UPDATE" frame might therefore be their use are necessary to prevent avoid replay attacks on
the
connection from being stalled.

Note: This is protocol.

A client MUST only potentially problematic for servers, who might
need use 0-RTT keys to send large certificate chains. In other cases, this is
unlikely given protect data that QUIC - like HTTP [RFC7230] - is a protocol
where the server is unable idempotent.
A client MAY wish to apply additional restrictions on what data it
sends prior to exercise the opportunity completion of the TLS
presents handshake. A client
otherwise treats 0-RTT keys as equivalent to send first.

If 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 a large certificate chain, or later modifications
or extensions been rejected. In
addition to QUIC permit the server 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 first, its end_of_early_data alert only after it has
received all of the server's handshake messages. Alternatively
phrased, a client
might reduce the chance of stalling due is encouraged to flow control in this
first round trip by setting larger values for use 0-RTT keys until 1-RTT keys
become available. This prevents stalling of the initial stream
and connection flow control windows 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 "quic_parameters"
extension (Section 6.1).

Editor's Note: Unlike "ACK", 0-RTT key if it decides to accept a 0-RTT key. A server MUST
still include the prohibition on "WINDOW_UPDATE" is
much less of an imposition on implementations. And, given that early_data extension in its ServerHello message.

This restriction prevents a
spurious "WINDOW_UPDATE" might be used server from responding to create a great deal of
memory pressure on an endpoint, request using
frames protected by the restriction seems justifiable.
Besides, I understand 0-RTT keys. This ensures that all
application data from the server are always protected with keys that
have forward secrecy. However, this one a lot better.

6.2.4. FEC Packets

FEC packets MUST NOT results in head-of-line blocking
at the client because server responses cannot be sent prior to completing decrypted until all
the TLS handshake.
Endpoints MUST treat receipt of an unprotected FEC packet as a fatal
error.

6.3. 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
endpoint before the final handshake messages are received. If these
can be decrypted successfully, such packets MAY be stored and used
once the handshake is complete.

Unless expressly permitted below, encrypted packets MUST NOT be used
prior to completing the TLS handshake, in particular the receipt of a
valid Finished message and any authentication of the peer. If
packets are processed prior to completion of the handshake, an
attacker might use the willingness of an implementation to use these
packets to mount attacks.

TLS handshake messages are covered by record protection during the
handshake, once key agreement has completed. This means that
protected messages need to be decrypted to determine if they are TLS
handshake messages or not. Similarly, "ACK" and "WINDOW_UPDATE"
frames might be needed to successfully complete the TLS handshake.

Any timestamps present in "ACK" frames MUST be ignored rather than
causing a fatal error. Timestamps on protected frames MAY be saved
and used once the TLS handshake completes successfully.

An endpoint MUST MAY save the last protected "WINDOW_UPDATE" frame it
receives for each stream and apply the values once the TLS handshake
completes.

Editor's Note: Ugh. This last one is pretty ugly. Maybe we should
just make Failing to do this might result in temporary stalling of
affected streams.

6. QUIC-Specific Additions to the TLS Handshake

QUIC uses the TLS handshake exempt from flow control up 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.

6.1. Protocol and Version Negotiation

The QUIC version negotiation mechanism is used to negotiate the
Finished message. Then we can prohibit unauthenticated
"WINDOW_UPDATE" messages. We would still likely want
version of QUIC that is used prior to account
for the packets sent and received, since completion of the
handshake. However, this packet is not authenticated, enabling an
active attacker to do otherwise would
create some hairy special cases. That means force a version downgrade.

To ensure that stalling a QUIC version downgrade is
possible, but not forced by an attacker,
version information is copied into the TLS handshake, which provides
integrity protection for the QUIC negotiation. This does not prevent
version downgrade during the handshake, though it means that we can avoid ugly rules like such a
downgrade causes a handshake failure.

Protocols that use the
above.

7. Connection ID

The QUIC connection transport MUST use Application Layer
Protocol Negotiation (ALPN) [RFC7301]. The ALPN identifier serves for the
protocol MUST be specific to identify the QUIC version that it operates over.
When constructing a connection and to
allow ClientHello, clients MUST include a server to resume list of all
the ALPN identifiers that they support, regardless of whether the
QUIC version that they have currently selected supports that
protocol.

Servers SHOULD select an existing connection from a new application protocol based solely on the
information in the ClientHello, not using the QUIC version that the
client
address has selected. If the protocol that is selected is not
supported with the QUIC version that is in case of mobility events. However, use, the server MUST
either send a QUIC version negotiation packet if this creates is possible, or
fail the connection otherwise.

6.2. QUIC Extension

QUIC defines an
identifier that a passive observer [RFC7258] can extension for use to correlate
connections. with TLS. That extension defines
transport-related parameters. This provides integrity protection for
these values. Including these in the TLS 1.3 offers connection resumption using pre-shared keys, which handshake also allows make the
values that a client sets available to send 0-RTT application data. This mode could
be used to continue a connection rather server one-round trip
earlier than rely on a publicly
visible correlator. parameters that are carried in QUIC frames. This only requires
document does not define that servers produce extension.

6.3. Source Address Validation

QUIC implementations describe a new
ticket on every connection and source address token. This is an
opaque blob that a server might provide to clients do not resume from the
same ticket more than once. when they first
use a given source address. The advantage of relying on 0-RTT modes for mobility events 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
this it claims. This prevents the server from
being used in packet reflection attacks (see Section 7.1).

A source address token is also more robust. If 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 point pre-shared key identifiers after every handshake to avoid
linkability of attachment results in
contacting 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 instance - one that lacks is under load might include a source address token in
the session state -
then cookie extension of a fallback 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 easy.

The main drawback with possible to use
a clean restart or anything resembling pre-shared key that was obtained in a
restart is TLS connection over TCP to
enable 0-RTT in QUIC. Similarly, QUIC can provide a pre-shared key
that accumulated state can be lost. Aside from progress used to enable 0-RTT in TCP.

All the restrictions on incomplete requests, the state use of 0-RTT apply, and the HPACK header compression
table could certificate
MUST be quite valuable. Existing QUIC implementations 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
connection ID to route packets to source IP address remains
constant, the server that port number is handling the
connection, which avoids likely to be different. Packet
reflection attacks are still possible in this sort situation, though the
set of problem. hosts that can initiate these attacks is greatly reduced. A lightweight state resurrection extension
server might be used choose to avoid
having source address validation for such a
connection, or allow an increase to recreate any expensive state.

8. 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
current set of issues is well captured in the relevant sections of
the main text.

Never assume that because it isn't in the security considerations
section it doesn't affect security. Most of this document does.

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.

10.

9. References

10.1.

9.1. Normative References

[I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-11 (work in progress),
December 2015.

[I-D.tsvwg-quic-protocol]

[I-D.hamilton-quic-transport-protocol]
Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC:
A UDP-Based Secure Multiplexed and Reliable Secure Transport", draft-
hamilton-quic-transport-protocol-00 (work in progress),
July 2016.

[I-D.ietf-tls-tls13]
Rescorla, E., "The Transport for HTTP/2",
draft-tsvwg-quic-protocol-02 Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-17 (work in progress), January
October 2016.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<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,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <http://www.rfc-editor.org/info/rfc7301>.

10.2.

9.2. Informative References

[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>.

[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.

[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <http://www.rfc-editor.org/info/rfc7258>.

[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<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

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, Eric
Rescorla, Ian Swett, and likely many others who are merely forgotten
by a faulty meat computer.

Authors' Addresses

Martin Thomson
Mozilla

Email: martin.thomson@gmail.com

Ryan Hamilton
Google

Email: rch@google.com