< draft-ietf-quic-tls-15.txt   draft-ietf-quic-tls-16.txt >
QUIC M. Thomson, Ed. QUIC M. Thomson, Ed.
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track S. Turner, Ed. Intended status: Standards Track S. Turner, Ed.
Expires: April 6, 2019 sn3rd Expires: April 26, 2019 sn3rd
October 03, 2018 October 23, 2018
Using Transport Layer Security (TLS) to Secure QUIC Using Transport Layer Security (TLS) to Secure QUIC
draft-ietf-quic-tls-15 draft-ietf-quic-tls-16
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), 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 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 April 6, 2019. This Internet-Draft will expire on April 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 2, line 48 skipping to change at page 2, line 48
5.4. Packet Number Protection . . . . . . . . . . . . . . . . 19 5.4. Packet Number Protection . . . . . . . . . . . . . . . . 19
5.4.1. AES-Based Packet Number Protection . . . . . . . . . 20 5.4.1. AES-Based Packet Number Protection . . . . . . . . . 20
5.4.2. ChaCha20-Based Packet Number Protection . . . . . . . 20 5.4.2. ChaCha20-Based Packet Number Protection . . . . . . . 20
5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 20 5.5. Receiving Protected Packets . . . . . . . . . . . . . . . 20
5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 21 5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 21
5.7. Receiving Out-of-Order Protected Frames . . . . . . . . . 21 5.7. Receiving Out-of-Order Protected Frames . . . . . . . . . 21
6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 22 6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 22
7. Security of Initial Messages . . . . . . . . . . . . . . . . 23 7. Security of Initial Messages . . . . . . . . . . . . . . . . 23
8. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 24 8. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 24
8.1. Protocol and Version Negotiation . . . . . . . . . . . . 24 8.1. Protocol and Version Negotiation . . . . . . . . . . . . 24
8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 24 8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 25
8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 25 8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9.1. Packet Reflection Attack Mitigation . . . . . . . . . . . 25 9.1. Packet Reflection Attack Mitigation . . . . . . . . . . . 26
9.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 26 9.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 26
9.3. Packet Number Protection Analysis . . . . . . . . . . . . 26 9.3. Packet Number Protection Analysis . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.1. Normative References . . . . . . . . . . . . . . . . . . 27 11.1. Normative References . . . . . . . . . . . . . . . . . . 28
11.2. Informative References . . . . . . . . . . . . . . . . . 29 11.2. Informative References . . . . . . . . . . . . . . . . . 29
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 29 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 30
A.1. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 29 A.1. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 30
A.2. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 30 A.2. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 30
A.3. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 30 A.3. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 30
A.4. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 30 A.4. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 30
A.5. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 30 A.5. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 30
A.6. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 30 A.6. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 30
A.7. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 30 A.7. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 31
A.8. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 30 A.8. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 31
A.9. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 31 A.9. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 31
A.10. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 31 A.10. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 31
A.11. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 31 A.11. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 31
A.12. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 31 A.12. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 31
A.13. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 31 A.13. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 32
A.14. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 32 A.14. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 32
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 32 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 32
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
This document describes how QUIC [QUIC-TRANSPORT] is secured using This document describes how QUIC [QUIC-TRANSPORT] is secured using
Transport Layer Security (TLS) version 1.3 [TLS13]. TLS 1.3 provides Transport Layer Security (TLS) version 1.3 [TLS13]. TLS 1.3 provides
critical latency improvements for connection establishment over critical latency improvements for connection establishment over
skipping to change at page 22, line 25 skipping to change at page 22, line 25
header is used to indicate whether key updates have occurred. The header is used to indicate whether key updates have occurred. The
KEY_PHASE bit is initially set to 0 and then inverted with each key KEY_PHASE bit is initially set to 0 and then inverted with each key
update. update.
The KEY_PHASE bit allows a recipient to detect a change in keying The KEY_PHASE bit allows a recipient to detect a change in keying
material without necessarily needing to receive the first packet that material without necessarily needing to receive the first packet that
triggered the change. An endpoint that notices a changed KEY_PHASE triggered the change. An endpoint that notices a changed KEY_PHASE
bit can update keys and decrypt the packet that contains the changed bit can update keys and decrypt the packet that contains the changed
bit. bit.
This mechanism replaces the TLS KeyUpdate message. Endpoints MUST
NOT send a TLS KeyUpdate message. Endpoints MUST treat the receipt
of a TLS KeyUpdate message as a connection error of type 0x10a,
equivalent to a fatal TLS alert of unexpected_message (see
Section 4.8).
An endpoint MUST NOT initiate more than one key update at a time. A An endpoint MUST NOT initiate more than one key update at a time. A
new key cannot be used until the endpoint has received and new key cannot be used until the endpoint has received and
successfully decrypted a packet with a matching KEY_PHASE. successfully decrypted a packet with a matching KEY_PHASE.
A receiving endpoint detects an update when the KEY_PHASE bit doesn't A receiving endpoint detects an update when the KEY_PHASE bit does
match what it is expecting. It creates a new secret (see Section 7.2 not match what it is expecting. It creates a new secret (see
of [TLS13]) and the corresponding read key and IV. If the packet can Section 7.2 of [TLS13]) and the corresponding read key and IV using
be decrypted and authenticated using these values, then the keys it the same variation on HKDF as defined in Section 5.1; that is, the
uses for packet protection are also updated. The next packet sent by prefix "quic " is used in place of "tls13 ".
the endpoint will then use the new keys.
An endpoint doesn't need to send packets immediately when it detects If the packet can be decrypted and authenticated using the updated
that its peer has updated keys. The next packet that it sends will key and IV, then the keys the endpoint uses for packet protection are
simply use the new keys. If an endpoint detects a second update also updated. The next packet sent by the endpoint will then use the
before it has sent any packets with updated keys it indicates that new keys.
its peer has updated keys twice without awaiting a reciprocal update.
An endpoint MUST treat consecutive key updates as a fatal error and An endpoint does not always need to send packets when it detects that
its peer has updated keys. The next packet that it sends will simply
use the new keys. If an endpoint detects a second update before it
has sent any packets with updated keys, it indicates that its peer
has updated keys twice without awaiting a reciprocal update. An
endpoint MUST treat consecutive key updates as a fatal error and
abort the connection. abort the connection.
An endpoint SHOULD retain old keys for a short period to allow it to An endpoint SHOULD retain old keys for a short period to allow it to
decrypt packets with smaller packet numbers than the packet that decrypt packets with smaller packet numbers than the packet that
triggered the key update. This allows an endpoint to consume packets triggered the key update. This allows an endpoint to consume packets
that are reordered around the transition between keys. Packets with that are reordered around the transition between keys. Packets with
higher packet numbers always use the updated keys and MUST NOT be higher packet numbers always use the updated keys and MUST NOT be
decrypted with old keys. decrypted with old keys.
Keys and their corresponding secrets SHOULD be discarded when an Keys and their corresponding secrets SHOULD be discarded when an
skipping to change at page 28, line 15 skipping to change at page 28, line 28
[AES] "Advanced encryption standard (AES)", National Institute [AES] "Advanced encryption standard (AES)", National Institute
of Standards and Technology report, of Standards and Technology report,
DOI 10.6028/nist.fips.197, November 2001. DOI 10.6028/nist.fips.197, November 2001.
[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-15 (work and Congestion Control", draft-ietf-quic-recovery-16 (work
in progress), October 2018. in progress), October 2018.
[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-15 (work in progress), October 2018. transport-16 (work in progress), October 2018.
[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>.
[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, <https://www.rfc-editor.org/info/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
skipping to change at page 29, line 18 skipping to change at page 29, line 28
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>.
[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.
[QUIC-HTTP] [QUIC-HTTP]
Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over
QUIC", draft-ietf-quic-http-15 (work in progress), October QUIC", draft-ietf-quic-http-16 (work in progress), October
2018. 2018.
[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,
 End of changes. 15 change blocks. 
29 lines changed or deleted 39 lines changed or added

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