draft-ietf-quic-tls-02.txt   draft-ietf-quic-tls-latest.txt 
QUIC Working Group M. Thomson, Ed. QUIC Working Group M. Thomson, Ed.
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track S. Turner, Ed. Intended status: Standards Track S. Turner, Ed.
Expires: September 14, 2017 sn3rd Expires: October 26, 2017 sn3rd
March 13, 2017 April 24, 2017
Using Transport Layer Security (TLS) to Secure QUIC Using Transport Layer Security (TLS) to Secure QUIC
draft-ietf-quic-tls-02 draft-ietf-quic-tls-latest
Abstract Abstract
This document describes how Transport Layer Security (TLS) can be This document describes how Transport Layer Security (TLS) is used to
used to secure QUIC. secure QUIC.
Note to Readers Note to Readers
Discussion of this draft takes place on the QUIC working group Discussion of this draft takes place on the QUIC working group
mailing list (quic@ietf.org), which is archived at mailing list (quic@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/search/?email_list=quic . https://mailarchive.ietf.org/arch/search/?email_list=quic .
Working Group information can be found at https://github.com/quicwg ; Working Group information can be found at https://github.com/quicwg ;
source code and issues list for this draft can be found at source code and issues list for this draft can be found at
https://github.com/quicwg/base-drafts/labels/tls . https://github.com/quicwg/base-drafts/labels/tls .
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 14, 2017. This Internet-Draft will expire on October 26, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 23 skipping to change at page 2, line 23
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. TLS Overview . . . . . . . . . . . . . . . . . . . . . . 5 3.1. TLS Overview . . . . . . . . . . . . . . . . . . . . . . 5
3.2. TLS Handshake . . . . . . . . . . . . . . . . . . . . . . 6 3.2. TLS Handshake . . . . . . . . . . . . . . . . . . . . . . 6
4. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Handshake and Setup Sequence . . . . . . . . . . . . . . 8 4.1. Handshake and Setup Sequence . . . . . . . . . . . . . . 7
4.2. Interface to TLS . . . . . . . . . . . . . . . . . . . . 9 4.2. Interface to TLS . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Handshake Interface . . . . . . . . . . . . . . . . . 9 4.2.1. Handshake Interface . . . . . . . . . . . . . . . . . 9
4.2.2. Source Address Validation . . . . . . . . . . . . . . 11 4.2.2. Source Address Validation . . . . . . . . . . . . . . 10
4.2.3. Key Ready Events . . . . . . . . . . . . . . . . . . 11 4.2.3. Key Ready Events . . . . . . . . . . . . . . . . . . 11
4.2.4. Secret Export . . . . . . . . . . . . . . . . . . . . 12 4.2.4. Secret Export . . . . . . . . . . . . . . . . . . . . 12
4.2.5. TLS Interface Summary . . . . . . . . . . . . . . . . 12 4.2.5. TLS Interface Summary . . . . . . . . . . . . . . . . 12
4.3. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 13 4.3. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 12
4.4. ClientHello Size . . . . . . . . . . . . . . . . . . . . 13 4.4. ClientHello Size . . . . . . . . . . . . . . . . . . . . 13
4.5. Peer Authentication . . . . . . . . . . . . . . . . . . . 14 4.5. Peer Authentication . . . . . . . . . . . . . . . . . . . 13
4.6. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 14 4.6. TLS Errors . . . . . . . . . . . . . . . . . . . . . . . 14
5. QUIC Packet Protection . . . . . . . . . . . . . . . . . . . 14 5. QUIC Packet Protection . . . . . . . . . . . . . . . . . . . 14
5.1. Installing New Keys . . . . . . . . . . . . . . . . . . . 15 5.1. Installing New Keys . . . . . . . . . . . . . . . . . . . 14
5.2. QUIC Key Expansion . . . . . . . . . . . . . . . . . . . 15 5.2. QUIC Key Expansion . . . . . . . . . . . . . . . . . . . 14
5.2.1. 0-RTT Secret . . . . . . . . . . . . . . . . . . . . 15 5.2.1. 0-RTT Secret . . . . . . . . . . . . . . . . . . . . 15
5.2.2. 1-RTT Secrets . . . . . . . . . . . . . . . . . . . . 16 5.2.2. 1-RTT Secrets . . . . . . . . . . . . . . . . . . . . 15
5.2.3. Packet Protection Key and IV . . . . . . . . . . . . 17 5.2.3. Packet Protection Key and IV . . . . . . . . . . . . 16
5.3. QUIC AEAD Usage . . . . . . . . . . . . . . . . . . . . . 18 5.3. QUIC AEAD Usage . . . . . . . . . . . . . . . . . . . . . 17
5.4. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 19 5.4. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 18
5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 19 5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 18
6. Key Phases . . . . . . . . . . . . . . . . . . . . . . . . . 20 6. Key Phases . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Packet Protection for the TLS Handshake . . . . . . . . . 20 6.1. Packet Protection for the TLS Handshake . . . . . . . . . 19
6.1.1. Initial Key Transitions . . . . . . . . . . . . . . . 21 6.1.1. Initial Key Transitions . . . . . . . . . . . . . . . 20
6.1.2. Retransmission and Acknowledgment of Unprotected 6.1.2. Retransmission and Acknowledgment of Unprotected
Packets . . . . . . . . . . . . . . . . . . . . . . . 22 Packets . . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Key Update . . . . . . . . . . . . . . . . . . . . . . . 22 6.2. Key Update . . . . . . . . . . . . . . . . . . . . . . . 21
7. Client Address Validation . . . . . . . . . . . . . . . . . . 24 7. Client Address Validation . . . . . . . . . . . . . . . . . . 23
7.1. HelloRetryRequest Address Validation . . . . . . . . . . 24 7.1. HelloRetryRequest Address Validation . . . . . . . . . . 23
7.2. NewSessionTicket Address Validation . . . . . . . . . . . 25 7.2. NewSessionTicket Address Validation . . . . . . . . . . . 24
7.3. Address Validation Token Integrity . . . . . . . . . . . 26 7.3. Address Validation Token Integrity . . . . . . . . . . . 25
8. Pre-handshake QUIC Messages . . . . . . . . . . . . . . . . . 26 8. Pre-handshake QUIC Messages . . . . . . . . . . . . . . . . . 25
8.1. Unprotected Packets Prior to Handshake Completion . . . . 27 8.1. Unprotected Packets Prior to Handshake Completion . . . . 26
8.1.1. STREAM Frames . . . . . . . . . . . . . . . . . . . . 27 8.1.1. STREAM Frames . . . . . . . . . . . . . . . . . . . . 26
8.1.2. ACK Frames . . . . . . . . . . . . . . . . . . . . . 27 8.1.2. ACK Frames . . . . . . . . . . . . . . . . . . . . . 26
8.1.3. WINDOW_UPDATE Frames . . . . . . . . . . . . . . . . 28 8.1.3. WINDOW_UPDATE Frames . . . . . . . . . . . . . . . . 27
8.1.4. Denial of Service with Unprotected Packets . . . . . 28 8.1.4. Denial of Service with Unprotected Packets . . . . . 27
8.2. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 29 8.2. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 28
8.3. Receiving Out-of-Order Protected Frames . . . . . . . . . 29 8.3. Receiving Out-of-Order Protected Frames . . . . . . . . . 28
9. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 30 9. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 29
9.1. Protocol and Version Negotiation . . . . . . . . . . . . 30 9.1. Protocol and Version Negotiation . . . . . . . . . . . . 29
9.2. QUIC Transport Parameters Extension . . . . . . . . . . . 31 9.2. QUIC Transport Parameters Extension . . . . . . . . . . . 29
9.3. Priming 0-RTT . . . . . . . . . . . . . . . . . . . . . . 31 9.3. Priming 0-RTT . . . . . . . . . . . . . . . . . . . . . . 30
10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
10.1. Packet Reflection Attack Mitigation . . . . . . . . . . 32 10.1. Packet Reflection Attack Mitigation . . . . . . . . . . 30
10.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 32 10.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 31
11. Error codes . . . . . . . . . . . . . . . . . . . . . . . . . 33 11. Error codes . . . . . . . . . . . . . . . . . . . . . . . . . 31
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
13.1. Normative References . . . . . . . . . . . . . . . . . . 33 13.1. Normative References . . . . . . . . . . . . . . . . . . 32
13.2. Informative References . . . . . . . . . . . . . . . . . 34 13.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 35 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 33
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 35 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 33
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 35 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 33
C.1. Since draft-ietf-quic-tls-01: . . . . . . . . . . . . . . 35 C.1. Since draft-ietf-quic-tls-01: . . . . . . . . . . . . . . 33
C.2. Since draft-ietf-quic-tls-00: . . . . . . . . . . . . . . 35 C.2. Since draft-ietf-quic-tls-00: . . . . . . . . . . . . . . 34
C.3. Since draft-thomson-quic-tls-01: . . . . . . . . . . . . 36 C.3. Since draft-thomson-quic-tls-01: . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
QUIC [QUIC-TRANSPORT] provides a multiplexed transport. When used This document describes how QUIC [QUIC-TRANSPORT] is secured using
for HTTP [RFC7230] semantics [QUIC-HTTP] it provides several key Transport Layer Security (TLS) version 1.3 [I-D.ietf-tls-tls13]. TLS
advantages over HTTP/1.1 [RFC7230] or HTTP/2 [RFC7540] over TCP 1.3 provides critical latency improvements for connection
[RFC0793]. establishment over previous versions. Absent packet loss, most new
connections can be established and secured within a single round
This document describes how QUIC can be secured using Transport Layer trip; on subsequent connections between the same client and server,
Security (TLS) version 1.3 [I-D.ietf-tls-tls13]. TLS 1.3 provides the client can often send application data immediately, that is,
critical latency improvements for connection establishment over using a zero round trip setup.
previous versions. Absent packet loss, most new connections can be
established 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, using a zero round trip
setup.
This document describes how the standardized TLS 1.3 can act a This document describes how the standardized TLS 1.3 acts a security
security component of QUIC. The same design could work for TLS 1.2, component of QUIC. The same design could work for TLS 1.2, though
though few of the benefits QUIC provides would be realized due to the 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.
2. Notational Conventions 2. 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].
This document uses the terminology established in [QUIC-TRANSPORT]. This document uses the terminology established in [QUIC-TRANSPORT].
skipping to change at page 5, line 39 skipping to change at page 5, line 39
stream 1 and associated packets. Stream 1 is reserved for a TLS stream 1 and associated packets. Stream 1 is reserved for a TLS
connection. This is a complete TLS connection as it would appear connection. This is a complete TLS connection as it would appear
when layered over TCP; the only difference is that QUIC provides the when layered over TCP; the only difference is that QUIC provides the
reliability and ordering that would otherwise be provided by TCP. reliability and ordering that would otherwise be provided by TCP.
At certain points during the TLS handshake, keying material is At certain points during the TLS handshake, keying material is
exported from the TLS connection for use by QUIC. This keying exported from the TLS connection for use by QUIC. This keying
material is used to derive packet protection keys. Details on how material is used to derive packet protection keys. Details on how
and when keys are derived and used are included in Section 5. and when keys are derived and used are included in Section 5.
This arrangement means that some TLS messages receive redundant
protection from both the QUIC packet protection and the TLS record
protection. These messages are limited in number; the TLS connection
is rarely needed once the handshake completes.
3.1. TLS Overview 3.1. TLS Overview
TLS provides two endpoints a way to establish a means of TLS provides two endpoints with a way to establish a means of
communication over an untrusted medium (that is, the Internet) that communication over an untrusted medium (that is, the Internet) that
ensures that messages they exchange cannot be observed, modified, or ensures that messages they exchange cannot be observed, modified, or
forged. forged.
TLS features can be separated into two basic functions: an TLS features can be separated into two basic functions: an
authenticated key exchange and record protection. QUIC primarily authenticated key exchange and record protection. QUIC primarily
uses the authenticated key exchange provided by TLS but provides its uses the authenticated key exchange provided by TLS but provides its
own packet protection. own packet protection.
The TLS authenticated key exchange occurs between two entities: The TLS authenticated key exchange occurs between two entities:
client and server. The client initiates the exchange and the server client and server. The client initiates the exchange and the server
responds. If the key exchange completes successfully, both client responds. If the key exchange completes successfully, both client
and server will agree on a secret. TLS supports both pre-shared key and server will agree on a secret. TLS supports both pre-shared key
(PSK) and Diffie-Hellman (DH) key exchanges. PSK is the basis for (PSK) and Diffie-Hellman (DH) key exchanges. PSK is the basis for
0-RTT; the latter provides perfect forward secrecy (PFS) when the DH 0-RTT; the latter provides perfect forward secrecy (PFS) when the DH
keys are destroyed. keys are destroyed.
After completing the TLS handshake, the client will have learned and After completing the TLS handshake, the client will have learned and
authenticated an identity for the server and the server is optionally authenticated an identity for the server and the server is optionally
able to learn and authenticate an identity for the client. TLS able to learn and authenticate an identity for the client. TLS
supports X.509 certificate-based authentication [RFC5280] for both supports X.509 [RFC5280] certificate-based authentication for both
server and client. server and client.
The TLS key exchange is resistent to tampering by attackers and it The TLS key exchange is resistent to tampering by attackers and it
produces shared secrets that cannot be controlled by either produces shared secrets that cannot be controlled by either
participating peer. participating peer.
3.2. TLS Handshake 3.2. TLS Handshake
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, 1-RTT handshake in which the client is able to send o A full 1-RTT handshake in which the client is able to send
application data after one round trip and the server immediately application data after one round trip and the server immediately
after receiving the first handshake message from the client. after receiving the first handshake message from the client.
o A 0-RTT handshake in which the client uses information it has o A 0-RTT handshake in which the client uses information it has
previously learned about the server to send immediately. This previously learned about the server to send application data
data can be replayed by an attacker so it MUST NOT carry a self- immediately. This application data can be replayed by an attacker
contained trigger for any non-idempotent action. 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 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 and details. in Figure 2, see [I-D.ietf-tls-tls13] for more options and details.
Client Server Client Server
ClientHello ClientHello
(0-RTT Application Data) --------> (0-RTT Application Data) -------->
ServerHello ServerHello
{EncryptedExtensions} {EncryptedExtensions}
skipping to change at page 7, line 36 skipping to change at page 7, line 21
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 is also used to exchange key from the client. HelloRetryRequest is also used to
verify that the client is correctly able to receive packets on the verify that the client is correctly able to receive packets on the
address it claims to have (see [QUIC-TRANSPORT]). address it claims to have (see [QUIC-TRANSPORT]).
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 is the basis for 0-RTT data, reduce the number of public key operations. This is the basis for
even if the remainder of the connection is protected by a new 0-RTT data, even if the remainder of the connection is protected
Diffie-Hellman exchange. by a new Diffie-Hellman exchange.
4. TLS Usage 4. TLS Usage
QUIC reserves stream 1 for a TLS connection. Stream 1 contains a QUIC reserves stream 1 for a TLS connection. Stream 1 contains a
complete TLS connection, which includes the TLS record layer. Other complete TLS connection, which includes the TLS record layer. Other
than the definition of a QUIC-specific extension (see Section-TBD), than the definition of a QUIC-specific extension (see Section-TBD),
TLS is unmodified for this use. This means that TLS will apply TLS is unmodified for this use. This means that TLS will apply
confidentiality and integrity protection to its records. In confidentiality and integrity protection to its records. In
particular, TLS record protection is what provides confidentiality particular, TLS record protection is what provides confidentiality
protection for the TLS handshake messages sent by the server. protection for the TLS handshake messages sent by the server.
QUIC permits a client to send frames on streams starting from the QUIC permits a client to send frames on streams starting from the
first packet. The initial packet from a client contains a stream first packet. The initial packet from a client contains a stream
frame for stream 1 that contains the first TLS handshake messages frame for stream 1 that contains the first TLS handshake messages
from the client. This allows the TLS handshake to start with the from the client. This allows the TLS handshake to start with the
first packet that a client sends. first packet that a client sends.
QUIC packets are protected using a scheme that is specific to QUIC, QUIC packets are protected using a scheme that is specific to QUIC,
see Section 5. Keys are exported from the TLS connection when they see Section 5. Keys are exported from the TLS connection when they
become available using a TLS exporter (see Section 7.3.3 of become available using a TLS exporter (see Section 7.5 of
[I-D.ietf-tls-tls13] and Section 5.2). After keys are exported from [I-D.ietf-tls-tls13] and Section 5.2). After keys are exported from
TLS, QUIC manages its own key schedule. TLS, QUIC manages its own key schedule.
4.1. Handshake and Setup Sequence 4.1. Handshake and Setup Sequence
The integration of QUIC with a TLS handshake is shown in more detail 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 in Figure 3. QUIC "STREAM" frames on stream 1 carry the TLS
handshake. QUIC performs loss recovery [QUIC-RECOVERY] for this handshake. QUIC performs loss recovery [QUIC-RECOVERY] for this
stream and ensures that TLS handshake messages are delivered in the stream and ensures that TLS handshake messages are delivered in the
correct order. correct order.
skipping to change at page 11, line 31 skipping to change at page 11, line 15
o abort the connection. o abort the connection.
If QUIC requests source address validation, it also provides a new If QUIC requests source address validation, it also provides a new
address validation token. TLS includes that along with any address validation token. TLS includes that along with any
information it requires in the cookie extension of a TLS information it requires in the cookie extension of a TLS
HelloRetryRequest message. In the other cases, the connection either HelloRetryRequest message. In the other cases, the connection either
proceeds or terminates with a handshake error. proceeds or terminates with a handshake error.
The client echoes the cookie extension in a second ClientHello. A The client echoes the cookie extension in a second ClientHello. A
ClientHello that contains a valid cookie extension will be always be ClientHello that contains a valid cookie extension will always be in
in response to a HelloRetryRequest. If address validation was response to a HelloRetryRequest. If address validation was requested
requested by QUIC, then this will include an address validation by QUIC, then this will include an address validation token. TLS
token. TLS makes a second address validation request of QUIC, makes a second address validation request of QUIC, including the
including the value extracted from the cookie extension. In response value extracted from the cookie extension. In response to this
to this request, QUIC cannot ask for client address validation, it request, QUIC cannot ask for client address validation, it can only
can only abort or permit the connection attempt to proceed. abort or permit the connection attempt to proceed.
QUIC can provide a new address validation token for use in session QUIC can provide a new address validation token for use in session
resumption at any time after the handshake is complete. Each time a resumption at any time after the handshake is complete. Each time a
new token is provided TLS generates a NewSessionTicket message, with new token is provided TLS generates a NewSessionTicket message, with
the token included in the ticket. the token included in the ticket.
See Section 7 for more details on client address validation. See Section 7 for more details on client address validation.
4.2.3. Key Ready Events 4.2.3. Key Ready Events
skipping to change at page 15, line 8 skipping to change at page 14, line 23
respectively. respectively.
5. QUIC Packet Protection 5. QUIC Packet Protection
QUIC packet protection provides authenticated encryption of packets. QUIC packet protection provides authenticated encryption of packets.
This provides confidentiality and integrity protection for the This provides confidentiality and integrity protection for the
content of packets (see Section 5.3). Packet protection uses keys content of packets (see Section 5.3). Packet protection uses keys
that are exported from the TLS connection (see Section 5.2). that are exported from the TLS connection (see Section 5.2).
Different keys are used for QUIC packet protection and TLS record Different keys are used for QUIC packet protection and TLS record
protection. Having separate QUIC and TLS record protection means protection. TLS handshake messages are protected solely with TLS
that TLS records can be protected by two different keys. This record protection, but post-handshake messages are redundantly
redundancy is limited to only a few TLS records, and is maintained proteted with both both the QUIC packet protection and the TLS record
for the sake of simplicity. protection. These messages are limited in number, and so the
additional overhead is small.
5.1. Installing New Keys 5.1. Installing New Keys
As TLS reports the availability of keying material, the packet As TLS reports the availability of keying material, the packet
protection keys and initialization vectors (IVs) are updated (see protection keys and initialization vectors (IVs) are updated (see
Section 5.2). The selection of AEAD function is also updated to Section 5.2). The selection of AEAD function is also updated to
match the AEAD negotiated by TLS. match the AEAD negotiated by TLS.
For packets other than any unprotected handshake packets (see For packets other than any unprotected handshake packets (see
Section 6.1), once a change of keys has been made, packets with Section 6.1), once a change of keys has been made, packets with
higher packet numbers MUST use the new keying material. The higher packet numbers MUST be sent with the new keying material. The
KEY_PHASE bit on these packets is inverted each time new keys are KEY_PHASE bit on these packets is inverted each time new keys are
installed to signal the use of the new keys to the recipient (see installed to signal the use of the new keys to the recipient (see
Section 6 for details). Section 6 for details).
An endpoint retransmits stream data in a new packet. New packets An endpoint retransmits stream data in a new packet. New packets
have new packet numbers and use the latest packet protection keys. have new packet numbers and use the latest packet protection keys.
This simplifies key management when there are key updates (see This simplifies key management when there are key updates (see
Section 6.2). Section 6.2).
5.2. QUIC Key Expansion 5.2. QUIC Key Expansion
QUIC uses a system of packet protection secrets, keys and IVs that QUIC uses a system of packet protection secrets, keys and IVs that
are modelled on the system used in TLS [I-D.ietf-tls-tls13]. The are modelled on the system used in TLS [I-D.ietf-tls-tls13]. The
secrets that QUIC uses as the basis of its key schedule are obtained secrets that QUIC uses as the basis of its key schedule are obtained
using TLS exporters (see Section 7.3.3 of [I-D.ietf-tls-tls13]). using TLS exporters (see Section 7.5 of [I-D.ietf-tls-tls13]).
QUIC uses HKDF with the same hash function negotiated by TLS for key QUIC uses HKDF with the same hash function negotiated by TLS for key
derivation. For example, if TLS is using the TLS_AES_128_GCM_SHA256, derivation. For example, if TLS is using the TLS_AES_128_GCM_SHA256,
the SHA-256 hash function is used. the SHA-256 hash function is used.
5.2.1. 0-RTT Secret 5.2.1. 0-RTT Secret
0-RTT keys are those keys that are used in resumed connections prior 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 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 might be replayed and so has some restrictions on its use, see
skipping to change at page 17, line 17 skipping to change at page 16, line 26
"QUIC client 1-RTT Secret", "QUIC client 1-RTT Secret",
"", Hash.length) "", Hash.length)
server_pp_secret_<N+1> server_pp_secret_<N+1>
= HKDF-Expand-Label(server_pp_secret_<N>, = HKDF-Expand-Label(server_pp_secret_<N>,
"QUIC server 1-RTT Secret", "QUIC server 1-RTT Secret",
"", Hash.length) "", Hash.length)
This allows for a succession of new secrets to be created as needed. This allows for a succession of new secrets to be created as needed.
HKDF-Expand-Label uses HKDF-Expand [RFC5869] with a specially HKDF-Expand-Label uses HKDF-Expand [RFC5869] with a specially
formatted info parameter. The info parameter that includes the formatted info parameter, as shown:
output length (in this case, the size of the PRF hash output) encoded
on two octets in network byte order, the length of the prefixed Label HKDF-Expand-Label(Secret, Label, HashValue, Length) =
as a single octet, the value of the Label prefixed with "TLS 1.3, ", HKDF-Expand(Secret, HkdfLabel, Length)
and a zero octet to indicate an empty HashValue. For example, the
client packet protection secret uses an info parameter of: Where HkdfLabel is specified as:
struct {
uint16 length = Length;
opaque label<10..255> = "TLS 1.3, " + Label;
uint8 hashLength; // Always 0
} HkdfLabel;
For example, the client packet protection secret uses an info
parameter of:
info = (HashLen / 256) || (HashLen % 256) || 0x21 || info = (HashLen / 256) || (HashLen % 256) || 0x21 ||
"TLS 1.3, QUIC client 1-RTT secret" || 0x00 "TLS 1.3, QUIC client 1-RTT secret" || 0x00
5.2.3. Packet Protection Key and IV 5.2.3. Packet Protection Key and IV
The complete key expansion uses an identical process for key The complete key expansion uses an identical process for key
expansion as defined in Section 7.3 of [I-D.ietf-tls-tls13], using expansion as defined in Section 7.3 of [I-D.ietf-tls-tls13], using
different values for the input secret. QUIC uses the AEAD function different values for the input secret. QUIC uses the AEAD function
negotiated by TLS. negotiated by TLS.
The packet protection key and IV used to protect the 0-RTT packets The packet protection key and IV used to protect the 0-RTT packets
sent by a client use the QUIC 0-RTT secret. This uses the HKDF- sent by a client are derived from the QUIC 0-RTT secret. The packet
Expand-Label with the PRF hash function negotiated by TLS. protection keys and IVs for 1-RTT packets sent by the client and
server are derived from the current generation of client_pp_secret
The length of the output is determined by the requirements of the and server_pp_secret respectively. The length of the output is
AEAD function selected by TLS. The key length is the AEAD key size. determined by the requirements of the AEAD function selected by TLS.
As defined in Section 5.3 of [I-D.ietf-tls-tls13], the IV length is The key length is the AEAD key size. As defined in Section 5.3 of
the larger of 8 or N_MIN (see Section 4 of [RFC5116]). [I-D.ietf-tls-tls13], the IV length is the larger of 8 or N_MIN (see
Section 4 of [RFC5116]). For any secret S, the corresponding key and
client_0rtt_key = HKDF-Expand-Label(client_0rtt_secret, IV are derived as shown below:
"key", "", key_length)
client_0rtt_iv = HKDF-Expand-Label(client_0rtt_secret,
"iv", "", iv_length)
Similarly, the packet protection key and IV used to protect 1-RTT
packets sent by both client and server use the current packet
protection secret.
client_pp_key_<N> = HKDF-Expand-Label(client_pp_secret_<N>,
"key", "", key_length)
client_pp_iv_<N> = HKDF-Expand-Label(client_pp_secret_<N>,
"iv", "", iv_length)
server_pp_key_<N> = HKDF-Expand-Label(server_pp_secret_<N>,
"key", "", key_length)
server_pp_iv_<N> = HKDF-Expand-Label(server_pp_secret_<N>,
"iv", "", iv_length)
The client protects (or encrypts) packets with the client packet key = HKDF-Expand-Label(S, "key", "", key_length)
protection key and IV; the server protects packets with the server iv = HKDF-Expand-Label(S, "iv", "", iv_length)
packet protection key.
The QUIC record protection initially starts without keying material. The QUIC record protection initially starts without keying material.
When the TLS state machine reports that the ClientHello has been When the TLS state machine reports that the ClientHello has been
sent, the 0-RTT keys can be generated and installed for writing. sent, the 0-RTT keys can be generated and installed for writing.
When the TLS state machine reports completion of the handshake, the When the TLS state machine reports completion of the handshake, the
1-RTT keys can be generated and installed for writing. 1-RTT keys can be generated and installed for writing.
5.3. QUIC AEAD Usage 5.3. QUIC AEAD Usage
The Authentication Encryption with Associated Data (AEAD) [RFC5116] The Authentication Encryption with Associated Data (AEAD) [RFC5116]
function used for QUIC packet protection is AEAD that is negotiated function used for QUIC packet protection is AEAD that is negotiated
for use with the TLS connection. For example, if TLS is using the for use with the TLS connection. For example, if TLS is using the
TLS_AES_128_GCM_SHA256, the AEAD_AES_128_GCM function is used. TLS_AES_128_GCM_SHA256, the AEAD_AES_128_GCM function is used.
Regular QUIC packets are protected by an AEAD [RFC5116]. Version Regular QUIC packets are protected by an AEAD algorithm [RFC5116].
negotiation and public reset packets are not protected. Version negotiation and public reset packets are not protected.
Once TLS has provided a key, the contents of regular QUIC packets Once TLS has provided a key, the contents of regular QUIC packets
immediately after any TLS messages have been sent are protected by immediately after any TLS messages have been sent are protected by
the AEAD selected by TLS. the AEAD selected by TLS.
The key, K, for the AEAD is either the client packet protection key The key, K, is either the client packet protection key
(client_pp_key_n) or the server packet protection key (client_pp_key_n) or the server packet protection key
(server_pp_key_n), derived as defined in Section 5.2. (server_pp_key_n), derived as defined in Section 5.2.
The nonce, N, for the AEAD is formed by combining either the packet The nonce, N, is formed by combining the packet protection IV (either
protection IV (either client_pp_iv_n or server_pp_iv_n) with packet client_pp_iv_n or server_pp_iv_n) with the packet number. The 64
numbers. The 64 bits of the reconstructed QUIC packet number in bits of the reconstructed QUIC packet number in network byte order is
network byte order is left-padded with zeros to the size of the IV. left-padded with zeros to the size of the IV. The exclusive OR of
The exclusive OR of the padded packet number and the IV forms the the padded packet number and the IV forms the AEAD nonce.
AEAD nonce.
The associated data, A, for the AEAD is the contents of the QUIC The associated data, A, for the AEAD is the contents of the QUIC
header, starting from the flags octet in the common header. header, starting from the flags octet in the common header.
The input plaintext, P, for the AEAD is the contents of the QUIC The input plaintext, P, for the AEAD is the contents of the QUIC
frame following the packet number, as described in [QUIC-TRANSPORT]. frame following the packet number, as described in [QUIC-TRANSPORT].
The output ciphertext, C, of the AEAD is transmitted in place of P. The output ciphertext, C, of the AEAD is transmitted in place of P.
Prior to TLS providing keys, no record protection is performed and Prior to TLS providing keys, no record protection is performed and
skipping to change at page 29, line 5 skipping to change at page 28, line 5
can be safely dropped. can be safely dropped.
Since only TLS handshake packets and acknowledgments are sent in the Since only TLS handshake packets and acknowledgments are sent in the
clear, an attacker is able to force implementations to rely on clear, an attacker is able to force implementations to rely on
retransmission for packets that are lost or shadowed. Thus, an retransmission for packets that are lost or shadowed. Thus, an
attacker that intends to deny service to an endpoint has to drop or attacker that intends to deny service to an endpoint has to drop or
shadow protected packets in order to ensure that their victim shadow protected packets in order to ensure that their victim
continues to accept unprotected packets. The ability to shadow continues to accept unprotected packets. The ability to shadow
packets means that an attacker does not need to be on path. packets means that an attacker does not need to be on path.
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.
In addition to causing valid packets to be dropped, an attacker can In addition to causing valid packets to be dropped, an attacker can
generate packets with an intent of causing the recipient to expend generate packets with an intent of causing the recipient to expend
processing resources. See Section 10.2 for a discussion of these processing resources. See Section 10.2 for a discussion of these
risks. risks.
To avoid receiving TLS packets that contain no useful data, a TLS To avoid receiving TLS packets that contain no useful data, a TLS
implementation MUST reject empty TLS handshake records and any record implementation MUST reject empty TLS handshake records and any record
that is not permitted by the TLS state machine. Any TLS application that is not permitted by the TLS state machine. Any TLS application
data or alerts that is received prior to the end of the handshake data or alerts that is received prior to the end of the handshake
MUST be treated as a fatal error. MUST be treated as a fatal error.
skipping to change at page 31, line 26 skipping to change at page 30, line 14
The "extension_data" field of the quic_transport_parameters extension The "extension_data" field of the quic_transport_parameters extension
contains a value that is defined by the version of QUIC that is in contains a value that is defined by the version of QUIC that is in
use. The quic_transport_parameters extension carries a use. The quic_transport_parameters extension carries a
TransportParameters when the version of QUIC defined in TransportParameters when the version of QUIC defined in
[QUIC-TRANSPORT] is used. [QUIC-TRANSPORT] is used.
9.3. Priming 0-RTT 9.3. Priming 0-RTT
QUIC uses TLS without modification. Therefore, it is possible to use 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 a pre-shared key that was established in a TLS handshake over TCP to
enable 0-RTT in QUIC. Similarly, QUIC can provide a pre-shared key enable 0-RTT in QUIC. Similarly, QUIC can provide a pre-shared key
that can be used to enable 0-RTT in TCP. that can be used to enable 0-RTT in TCP.
All the restrictions on the use of 0-RTT apply, with the exception of All the restrictions on the use of 0-RTT apply, with the exception of
the ALPN label, which MUST only change to a label that is explicitly the ALPN label, which MUST only change to a label that is explicitly
designated as being compatible. The client indicates which ALPN designated as being compatible. The client indicates which ALPN
label it has chosen by placing that ALPN label first in the ALPN label it has chosen by placing that ALPN label first in the ALPN
extension. extension.
The certificate that the server uses MUST be considered valid for The certificate that the server uses MUST be considered valid for
skipping to change at page 33, line 38 skipping to change at page 32, line 23
13.1. Normative References 13.1. Normative References
[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-19 (work in progress), Version 1.3", draft-ietf-tls-tls13-19 (work in progress),
March 2017. March 2017.
[QUIC-TRANSPORT] [QUIC-TRANSPORT]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport". Multiplexed and Secure Transport", draft-ietf-quic-
transport-latest (work in progress).
[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 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<http://www.rfc-editor.org/info/rfc5116>. <http://www.rfc-editor.org/info/rfc5116>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
<http://www.rfc-editor.org/info/rfc5869>. <http://www.rfc-editor.org/info/rfc5869>.
[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>.
[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>.
13.2. Informative References 13.2. Informative References
[AEBounds] [AEBounds]
Luykx, A. and K. Paterson, "Limits on Authenticated Luykx, A. and K. Paterson, "Limits on Authenticated
Encryption Use in TLS", March 2016, Encryption Use in TLS", March 2016,
<http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>. <http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.
[QUIC-HTTP] [QUIC-HTTP]
Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over
QUIC". QUIC", draft-ietf-quic-http-latest (work in progress).
[QUIC-RECOVERY] [QUIC-RECOVERY]
Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control". and Congestion Control", draft-ietf-quic-recovery-latest
(work in progress).
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>. <http://www.rfc-editor.org/info/rfc2818>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <http://www.rfc-editor.org/info/rfc5280>.
[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>.
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", RFC 7924, (TLS) Cached Information Extension", RFC 7924,
DOI 10.17487/RFC7924, July 2016, DOI 10.17487/RFC7924, July 2016,
<http://www.rfc-editor.org/info/rfc7924>. <http://www.rfc-editor.org/info/rfc7924>.
Appendix A. Contributors Appendix A. Contributors
Ryan Hamilton was originally an author of this specification. Ryan Hamilton was originally an author of this specification.
Appendix B. Acknowledgments Appendix B. Acknowledgments
skipping to change at page 36, line 25 skipping to change at page 35, line 4
o Updated authors/editors list. o Updated authors/editors list.
o Added status note. o Added status note.
Authors' Addresses Authors' Addresses
Martin Thomson (editor) Martin Thomson (editor)
Mozilla Mozilla
Email: martin.thomson@gmail.com Email: martin.thomson@gmail.com
Sean Turner (editor) Sean Turner (editor)
sn3rd sn3rd
Email: sean@sn3rd.com
 End of changes. 40 change blocks. 
166 lines changed or deleted 129 lines changed or added

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