draft-ietf-quic-tls-28.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: November 20, 2020 sn3rd Expires: December 7, 2020 sn3rd
May 19, 2020 June 5, 2020
Using TLS to Secure QUIC Using TLS to Secure QUIC
draft-ietf-quic-tls-28 draft-ietf-quic-tls-latest
Abstract Abstract
This document describes how Transport Layer Security (TLS) is used to This document describes how Transport Layer Security (TLS) is 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 [1]), which is archived at mailing list (quic@ietf.org [1]), 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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 November 20, 2020. This Internet-Draft will expire on December 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 36 skipping to change at page 3, line 36
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
11.1. Normative References . . . . . . . . . . . . . . . . . . 42 11.1. Normative References . . . . . . . . . . . . . . . . . . 42
11.2. Informative References . . . . . . . . . . . . . . . . . 43 11.2. Informative References . . . . . . . . . . . . . . . . . 43
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 44 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Appendix A. Sample Packet Protection . . . . . . . . . . . . . . 44 Appendix A. Sample Packet Protection . . . . . . . . . . . . . . 44
A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 44 A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 44
A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 45 A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 45
A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 47 A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 47
A.4. Retry . . . . . . . . . . . . . . . . . . . . . . . . . . 48 A.4. Retry . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 48 A.5. ChaCha20-Poly1305 Short Header Packet . . . . . . . . . . 48
B.1. Since draft-ietf-quic-tls-27 . . . . . . . . . . . . . . 48 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 50
B.2. Since draft-ietf-quic-tls-26 . . . . . . . . . . . . . . 49 B.1. Since draft-ietf-quic-tls-27 . . . . . . . . . . . . . . 50
B.3. Since draft-ietf-quic-tls-25 . . . . . . . . . . . . . . 49 B.2. Since draft-ietf-quic-tls-26 . . . . . . . . . . . . . . 50
B.4. Since draft-ietf-quic-tls-24 . . . . . . . . . . . . . . 49 B.3. Since draft-ietf-quic-tls-25 . . . . . . . . . . . . . . 50
B.5. Since draft-ietf-quic-tls-23 . . . . . . . . . . . . . . 49 B.4. Since draft-ietf-quic-tls-24 . . . . . . . . . . . . . . 50
B.6. Since draft-ietf-quic-tls-22 . . . . . . . . . . . . . . 49 B.5. Since draft-ietf-quic-tls-23 . . . . . . . . . . . . . . 50
B.7. Since draft-ietf-quic-tls-21 . . . . . . . . . . . . . . 49 B.6. Since draft-ietf-quic-tls-22 . . . . . . . . . . . . . . 51
B.8. Since draft-ietf-quic-tls-20 . . . . . . . . . . . . . . 49 B.7. Since draft-ietf-quic-tls-21 . . . . . . . . . . . . . . 51
B.9. Since draft-ietf-quic-tls-18 . . . . . . . . . . . . . . 50 B.8. Since draft-ietf-quic-tls-20 . . . . . . . . . . . . . . 51
B.10. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 50 B.9. Since draft-ietf-quic-tls-18 . . . . . . . . . . . . . . 51
B.11. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 50 B.10. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 51
B.12. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 50 B.11. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 51
B.13. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 50 B.12. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 52
B.14. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 51 B.13. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 52
B.15. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 51 B.14. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 52
B.16. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 51 B.15. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 52
B.17. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 51 B.16. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 52
B.18. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 51 B.17. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 52
B.19. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 51 B.18. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 53
B.20. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 51 B.19. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 53
B.21. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 52 B.20. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 53
B.22. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 52 B.21. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 53
B.23. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 52 B.22. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 53
B.24. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 52 B.23. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 53
B.25. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 53 B.24. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 54
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 53 B.25. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
This document describes how QUIC [QUIC-TRANSPORT] is secured using This document describes how QUIC [QUIC-TRANSPORT] is secured using
TLS [TLS13]. TLS [TLS13].
TLS 1.3 provides critical latency improvements for connection TLS 1.3 provides critical latency improvements for connection
establishment over previous versions. Absent packet loss, most new establishment over previous versions. Absent packet loss, most new
connections can be established and secured within a single round connections can be established and secured within a single round
trip; on subsequent connections between the same client and server, trip; on subsequent connections between the same client and server,
skipping to change at page 16, line 49 skipping to change at page 16, line 49
QUIC can use the session resumption feature of TLS 1.3. It does this QUIC can use the session resumption feature of TLS 1.3. It does this
by carrying NewSessionTicket messages in CRYPTO frames after the by carrying NewSessionTicket messages in CRYPTO frames after the
handshake is complete. Session resumption is the basis of 0-RTT, but handshake is complete. Session resumption is the basis of 0-RTT, but
can be used without also enabling 0-RTT. can be used without also enabling 0-RTT.
Endpoints that use session resumption might need to remember some Endpoints that use session resumption might need to remember some
information about the current connection when creating a resumed information about the current connection when creating a resumed
connection. TLS requires that some information be retained; see connection. TLS requires that some information be retained; see
Section 4.6.1 of [TLS13]. QUIC itself does not depend on any state Section 4.6.1 of [TLS13]. QUIC itself does not depend on any state
being retained when resuming a connection, unless 0-RTT is also used; being retained when resuming a connection, unless 0-RTT is also used;
see Section 4.6 and Section 7.3.1 of [QUIC-TRANSPORT]. Application see Section 4.6 and Section 7.4.1 of [QUIC-TRANSPORT]. Application
protocols could depend on state that is retained between resumed protocols could depend on state that is retained between resumed
connections. connections.
Clients can store any state required for resumption along with the Clients can store any state required for resumption along with the
session ticket. Servers can use the session ticket to help carry session ticket. Servers can use the session ticket to help carry
state. state.
Session resumption allows servers to link activity on the original Session resumption allows servers to link activity on the original
connection with the resumed connection, which might be a privacy connection with the resumed connection, which might be a privacy
issue for clients. Clients can choose not to enable resumption to issue for clients. Clients can choose not to enable resumption to
skipping to change at page 38, line 21 skipping to change at page 38, line 21
handshake as a workaround for bugs in some middleboxes. The TLS 1.3 handshake as a workaround for bugs in some middleboxes. The TLS 1.3
middlebox compatibility mode involves setting the legacy_session_id middlebox compatibility mode involves setting the legacy_session_id
field to a 32-byte value in the ClientHello and ServerHello, then field to a 32-byte value in the ClientHello and ServerHello, then
sending a change_cipher_spec record. Both field and record carry no sending a change_cipher_spec record. Both field and record carry no
semantic content and are ignored. semantic content and are ignored.
This mode has no use in QUIC as it only applies to middleboxes that This mode has no use in QUIC as it only applies to middleboxes that
interfere with TLS over TCP. QUIC also provides no means to carry a interfere with TLS over TCP. QUIC also provides no means to carry a
change_cipher_spec record. A client MUST NOT request the use of the change_cipher_spec record. A client MUST NOT request the use of the
TLS 1.3 compatibility mode. A server SHOULD treat the receipt of a TLS 1.3 compatibility mode. A server SHOULD treat the receipt of a
TLS ClientHello that with a non-empty legacy_session_id field as a TLS ClientHello with a non-empty legacy_session_id field as a
connection error of type PROTOCOL_VIOLATION. connection error of type PROTOCOL_VIOLATION.
9. Security Considerations 9. Security Considerations
All of the security considerations that apply to TLS also apply to All of the security considerations that apply to TLS also apply to
the use of TLS in QUIC. Reading all of [TLS13] and its appendices is the use of TLS in QUIC. Reading all of [TLS13] and its appendices is
the best way to gain an understanding of the security properties of the best way to gain an understanding of the security properties of
QUIC. QUIC.
This section summarizes some of the more important security aspects This section summarizes some of the more important security aspects
skipping to change at page 42, line 41 skipping to change at page 42, line 41
"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, <https://www.rfc-editor.org/info/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF [CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
<https://www.rfc-editor.org/info/rfc8439>. <https://www.rfc-editor.org/info/rfc8439>.
[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", draft-ietf-quic-recovery-28 (work and Congestion Control", draft-ietf-quic-recovery-latest
in progress). (work in progress).
[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", draft-ietf-quic- Multiplexed and Secure Transport", draft-ietf-quic-
transport-28 (work in progress). 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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
skipping to change at page 43, line 44 skipping to change at page 43, line 44
[IMC] Katz, J. and Y. Lindell, "Introduction to Modern [IMC] Katz, J. and Y. Lindell, "Introduction to Modern
Cryptography, Second Edition", ISBN 978-1466570269, Cryptography, Second Edition", ISBN 978-1466570269,
November 2014. November 2014.
[NAN] Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed: [NAN] Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed:
AEAD Revisited", Advances in Cryptology - CRYPTO 2019 pp. AEAD Revisited", Advances in Cryptology - CRYPTO 2019 pp.
235-265, DOI 10.1007/978-3-030-26948-7_9, 2019. 235-265, DOI 10.1007/978-3-030-26948-7_9, 2019.
[QUIC-HTTP] [QUIC-HTTP]
Bishop, M., Ed., "Hypertext Transfer Protocol Version 3 Bishop, M., Ed., "Hypertext Transfer Protocol Version 3
(HTTP/3)", draft-ietf-quic-http-28 (work in progress). (HTTP/3)", draft-ietf-quic-http-latest (work in progress).
[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,
<https://www.rfc-editor.org/info/rfc2818>. <https://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,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
skipping to change at page 48, line 34 skipping to change at page 48, line 34
A.4. Retry A.4. Retry
This shows a Retry packet that might be sent in response to the This shows a Retry packet that might be sent in response to the
Initial packet in Appendix A.2. The integrity check includes the Initial packet in Appendix A.2. The integrity check includes the
client-chosen connection ID value of 0x8394c8f03e515708, but that client-chosen connection ID value of 0x8394c8f03e515708, but that
value is not included in the final Retry packet: value is not included in the final Retry packet:
ffff00001c0008f067a5502a4262b574 6f6b656ef71a5f12afe3ecf8001a920e ffff00001c0008f067a5502a4262b574 6f6b656ef71a5f12afe3ecf8001a920e
6fdf1d63 6fdf1d63
A.5. ChaCha20-Poly1305 Short Header Packet
This example shows some of the steps required to protect a packet
with a short header. This example uses AEAD_CHACHA20_POLY1305.
In this example, TLS produces an application write secret from which
a server uses HKDF-Expand-Label to produce four values: a key, an IV,
a header protection key, and the secret that will be used after keys
are updated (this last value is not used further in this example).
secret
= 9ac312a7f877468ebe69422748ad00a1
5443f18203a07d6060f688f30f21632b
key = HKDF-Expand-Label(secret, "quic key", _, 32)
= c6d98ff3441c3fe1b2182094f69caa2e
d4b716b65488960a7a984979fb23e1c8
iv = HKDF-Expand-Label(secret, "quic iv", _, 12)
= e0459b3474bdd0e44a41c144
hp = HKDF-Expand-Label(secret, "quic hp", _, 32)
= 25a282b9e82f06f21f488917a4fc8f1b
73573685608597d0efcb076b0ab7a7a4
ku = HKDF-Expand-Label(secret, "quic ku", _, 32)
= 1223504755036d556342ee9361d25342
1a826c9ecdf3c7148684b36b714881f9
The following shows the steps involved in protecting a minimal packet
with an empty Destination Connection ID. This packet contains a
single PING frame (that is, a payload of just 0x01) and has a packet
number of 654360564. In this example, using a packet number of
length 3 (that is, 49140 is encoded) avoids having to pad the payload
of the packet; PADDING frames would be needed if the packet number is
encoded on fewer octets.
pn = 654360564 (decimal)
nonce = e0459b3474bdd0e46d417eb0
unprotected header = 4200bff4
payload plaintext = 01
payload ciphertext = 655e5cd55c41f69080575d7999c25a5bfb
The resulting ciphertext is the minimum size possible. One byte is
skipped to produce the sample for header protection.
sample = 5e5cd55c41f69080575d7999c25a5bfb
mask = aefefe7d03
header = 4cfe4189
The protected packet is the smallest possible packet size of 21
bytes.
packet = 4cfe4189655e5cd55c41f69080575d7999c25a5bfb
Appendix B. Change Log Appendix B. Change Log
*RFC Editor's Note:* Please remove this section prior to *RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document. publication of a final version of this document.
Issue and pull request numbers are listed with a leading octothorp. Issue and pull request numbers are listed with a leading octothorp.
B.1. Since draft-ietf-quic-tls-27 B.1. Since draft-ietf-quic-tls-27
o Allowed CONNECTION_CLOSE in any packet number space, with o Allowed CONNECTION_CLOSE in any packet number space, with
 End of changes. 10 change blocks. 
38 lines changed or deleted 94 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/