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: September 25, 2017 sn3rd
March 13, 2017 March 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) can be
used to secure QUIC. used to 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
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 September 25, 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 3, line 25 skipping to change at page 3, line 25
9.2. QUIC Transport Parameters Extension . . . . . . . . . . . 31 9.2. QUIC Transport Parameters Extension . . . . . . . . . . . 31
9.3. Priming 0-RTT . . . . . . . . . . . . . . . . . . . . . . 31 9.3. Priming 0-RTT . . . . . . . . . . . . . . . . . . . . . . 31
10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32
10.1. Packet Reflection Attack Mitigation . . . . . . . . . . 32 10.1. Packet Reflection Attack Mitigation . . . . . . . . . . 32
10.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 32 10.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 32
11. Error codes . . . . . . . . . . . . . . . . . . . . . . . . . 33 11. Error codes . . . . . . . . . . . . . . . . . . . . . . . . . 33
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
13.1. Normative References . . . . . . . . . . . . . . . . . . 33 13.1. Normative References . . . . . . . . . . . . . . . . . . 33
13.2. Informative References . . . . . . . . . . . . . . . . . 34 13.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 35 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 34
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 35 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 35
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 35 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 35
C.1. Since draft-ietf-quic-tls-01: . . . . . . . . . . . . . . 35 C.1. Since draft-ietf-quic-tls-01: . . . . . . . . . . . . . . 35
C.2. Since draft-ietf-quic-tls-00: . . . . . . . . . . . . . . 35 C.2. Since draft-ietf-quic-tls-00: . . . . . . . . . . . . . . 35
C.3. Since draft-thomson-quic-tls-01: . . . . . . . . . . . . 36 C.3. Since draft-thomson-quic-tls-01: . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
QUIC [QUIC-TRANSPORT] provides a multiplexed transport. When used This document describes how QUIC [QUIC-TRANSPORT] can be secured
for HTTP [RFC7230] semantics [QUIC-HTTP] it provides several key using Transport Layer Security (TLS) version 1.3
advantages over HTTP/1.1 [RFC7230] or HTTP/2 [RFC7540] over TCP [I-D.ietf-tls-tls13]. TLS 1.3 provides critical latency improvements
[RFC0793]. for connection establishment over previous versions. Absent packet
loss, most new connections can be established and secured within a
This document describes how QUIC can be secured using Transport Layer single round trip; on subsequent connections between the same client
Security (TLS) version 1.3 [I-D.ietf-tls-tls13]. TLS 1.3 provides and server, the client can often send application data immediately,
critical latency improvements for connection establishment over that is, 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 can act a
security component of QUIC. The same design could work for TLS 1.2, security component of QUIC. The same design could work for TLS 1.2,
though few of the benefits QUIC provides would be realized due to the though few of the benefits QUIC provides would be realized due to the
handshake latency in versions of TLS prior to 1.3. handshake latency in versions of TLS prior to 1.3.
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
skipping to change at page 6, line 34 skipping to change at page 6, line 34
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 8, line 9 skipping to change at page 8, line 9
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 15, line 37 skipping to change at page 15, line 37
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 33, line 38 skipping to change at page 33, line 38
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 line 1639 skipping to change at page 36, line 24
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. 14 change blocks. 
40 lines changed or deleted 24 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/