draft-ietf-quic-tls-04.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: December 15, 2017 sn3rd Expires: January 22, 2018 sn3rd
June 13, 2017 July 21, 2017
Using Transport Layer Security (TLS) to Secure QUIC Using Transport Layer Security (TLS) to Secure QUIC
draft-ietf-quic-tls-04 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), 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 December 15, 2017. This Internet-Draft will expire on January 22, 2018.
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 6 skipping to change at page 3, line 6
6.1. Integrity Check Processing . . . . . . . . . . . . . . . 19 6.1. Integrity Check Processing . . . . . . . . . . . . . . . 19
6.2. The 64-bit FNV-1a Algorithm . . . . . . . . . . . . . . . 20 6.2. The 64-bit FNV-1a Algorithm . . . . . . . . . . . . . . . 20
7. Key Phases . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Key Phases . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Packet Protection for the TLS Handshake . . . . . . . . . 21 7.1. Packet Protection for the TLS Handshake . . . . . . . . . 21
7.1.1. Initial Key Transitions . . . . . . . . . . . . . . . 21 7.1.1. Initial Key Transitions . . . . . . . . . . . . . . . 21
7.1.2. Retransmission and Acknowledgment of Unprotected 7.1.2. Retransmission and Acknowledgment of Unprotected
Packets . . . . . . . . . . . . . . . . . . . . . . . 22 Packets . . . . . . . . . . . . . . . . . . . . . . . 22
7.2. Key Update . . . . . . . . . . . . . . . . . . . . . . . 23 7.2. Key Update . . . . . . . . . . . . . . . . . . . . . . . 23
8. Client Address Validation . . . . . . . . . . . . . . . . . . 24 8. Client Address Validation . . . . . . . . . . . . . . . . . . 24
8.1. HelloRetryRequest Address Validation . . . . . . . . . . 24 8.1. HelloRetryRequest Address Validation . . . . . . . . . . 25
8.1.1. Stateless Address Validation . . . . . . . . . . . . 25 8.1.1. Stateless Address Validation . . . . . . . . . . . . 25
8.1.2. Sending HelloRetryRequest . . . . . . . . . . . . . . 26 8.1.2. Sending HelloRetryRequest . . . . . . . . . . . . . . 26
8.2. NewSessionTicket Address Validation . . . . . . . . . . . 26 8.2. NewSessionTicket Address Validation . . . . . . . . . . . 26
8.3. Address Validation Token Integrity . . . . . . . . . . . 27 8.3. Address Validation Token Integrity . . . . . . . . . . . 27
9. Pre-handshake QUIC Messages . . . . . . . . . . . . . . . . . 27 9. Pre-handshake QUIC Messages . . . . . . . . . . . . . . . . . 27
9.1. Unprotected Packets Prior to Handshake Completion . . . . 28 9.1. Unprotected Packets Prior to Handshake Completion . . . . 28
9.1.1. STREAM Frames . . . . . . . . . . . . . . . . . . . . 28 9.1.1. STREAM Frames . . . . . . . . . . . . . . . . . . . . 28
9.1.2. ACK Frames . . . . . . . . . . . . . . . . . . . . . 28 9.1.2. ACK Frames . . . . . . . . . . . . . . . . . . . . . 28
9.1.3. Updates to Data and Stream Limits . . . . . . . . . . 29 9.1.3. Updates to Data and Stream Limits . . . . . . . . . . 29
9.1.4. Denial of Service with Unprotected Packets . . . . . 29 9.1.4. Denial of Service with Unprotected Packets . . . . . 29
9.2. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 30 9.2. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 30
9.3. Receiving Out-of-Order Protected Frames . . . . . . . . . 30 9.3. Receiving Out-of-Order Protected Frames . . . . . . . . . 30
10. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 31 10. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 31
10.1. Protocol and Version Negotiation . . . . . . . . . . . . 31 10.1. Protocol and Version Negotiation . . . . . . . . . . . . 31
10.2. QUIC Transport Parameters Extension . . . . . . . . . . 31 10.2. QUIC Transport Parameters Extension . . . . . . . . . . 32
10.3. Priming 0-RTT . . . . . . . . . . . . . . . . . . . . . 32 10.3. Priming 0-RTT . . . . . . . . . . . . . . . . . . . . . 32
11. Security Considerations . . . . . . . . . . . . . . . . . . . 32 11. Security Considerations . . . . . . . . . . . . . . . . . . . 33
11.1. Packet Reflection Attack Mitigation . . . . . . . . . . 33 11.1. Packet Reflection Attack Mitigation . . . . . . . . . . 33
11.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 33 11.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 33
12. Error codes . . . . . . . . . . . . . . . . . . . . . . . . . 33 12. Error codes . . . . . . . . . . . . . . . . . . . . . . . . . 34
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
14.1. Normative References . . . . . . . . . . . . . . . . . . 34 14.1. Normative References . . . . . . . . . . . . . . . . . . 34
14.2. Informative References . . . . . . . . . . . . . . . . . 35 14.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 36 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 36
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 36 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 36
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 36 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 36
C.1. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 36 C.1. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 36
C.2. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 36 C.2. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 36
C.3. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 37 C.3. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 37
skipping to change at page 16, line 45 skipping to change at page 16, line 45
HKDF-Expand-Label uses HKDF-Expand [RFC5869] with a specially HKDF-Expand-Label uses HKDF-Expand [RFC5869] with a specially
formatted info parameter, as shown: formatted info parameter, as shown:
HKDF-Expand-Label(Secret, Label, HashValue, Length) = HKDF-Expand-Label(Secret, Label, HashValue, Length) =
HKDF-Expand(Secret, HkdfLabel, Length) HKDF-Expand(Secret, HkdfLabel, Length)
Where HkdfLabel is specified as: Where HkdfLabel is specified as:
struct { struct {
uint16 length = Length; uint16 length = Length;
opaque label<10..255> = "TLS 1.3, " + Label; opaque label<10..255> = "tls13 " + Label;
uint8 hashLength; // Always 0 uint8 hashLength; // Always 0
} HkdfLabel; } HkdfLabel;
For example, the client packet protection secret uses an info For example, the client packet protection secret uses an info
parameter of: parameter of:
info = (HashLen / 256) || (HashLen % 256) || 0x21 || info = (HashLen / 256) || (HashLen % 256) || 0x1f ||
"TLS 1.3, QUIC client 1-RTT secret" || 0x00 "tls13 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 are derived from the QUIC 0-RTT secret. The packet sent by a client are derived from the QUIC 0-RTT secret. The packet
skipping to change at page 18, line 12 skipping to change at page 18, line 12
(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, is formed by combining the packet protection IV (either The nonce, N, is formed by combining the packet protection IV (either
client_pp_iv_n or server_pp_iv_n) with the packet number. The 64 client_pp_iv_n or server_pp_iv_n) with the packet number. The 64
bits of the reconstructed QUIC packet number in network byte order is bits of the reconstructed QUIC packet number in network byte order is
left-padded with zeros to the size of the IV. The exclusive OR of left-padded with zeros to the size of the IV. The exclusive OR of
the padded packet number and the IV forms the AEAD nonce. the padded packet number and the IV forms the 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 either the short or long
header.
The input plaintext, P, for the AEAD is the contents of the QUIC The input plaintext, P, for the AEAD is the content of the QUIC frame
frame following the packet number, as described in [QUIC-TRANSPORT]. following the header, 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
the plaintext, P, is transmitted unmodified. the plaintext, P, is transmitted unmodified.
5.4. Packet Numbers 5.4. Packet Numbers
QUIC has a single, contiguous packet number space. In comparison, QUIC has a single, contiguous packet number space. In comparison,
TLS restarts its sequence number each time that record protection TLS restarts its sequence number each time that record protection
skipping to change at page 19, line 31 skipping to change at page 19, line 31
[QUIC-TRANSPORT]; Section 7.5.1.1 also requires a secret to compute [QUIC-TRANSPORT]; Section 7.5.1.1 also requires a secret to compute
packet number gaps on connection ID transitions. That secret is packet number gaps on connection ID transitions. That secret is
computed as: computed as:
packet_number_secret packet_number_secret
= TLS-Exporter("EXPORTER-QUIC Packet Number Secret" = TLS-Exporter("EXPORTER-QUIC Packet Number Secret"
"", Hash.length) "", Hash.length)
6. Unprotected Packets 6. Unprotected Packets
QUIC adds an integrity check to all unprotected packets. Any packet QUIC adds an integrity check to all cleartext packets. Cleartext
that is not protected by the negotiated AEAD (see Section 5), packets are not protected by the negotiated AEAD (see Section 5), but
includes an integrity check. This check does not prevent the packet instead include an integrity check. This check does not prevent the
from being altered, it exists for added resilience against data packet from being altered, it exists for added resilience against
corruption and to provided added assurance that the sender intends to data corruption and to provide added assurance that the sender
use QUIC. intends to use QUIC.
Unprotected packets all use the long form of the QUIC header and so Cleartext packets all use the long form of the QUIC header and so
will include a version number. For this version of QUIC, the will include a version number. For this version of QUIC, the
integrity check uses the 64-bit FNV-1a hash (see Section 6.2). The integrity check uses the 64-bit FNV-1a hash (see Section 6.2). The
output of this hash is appended to the payload of the packet. output of this hash is appended to the payload of the packet.
The integrity check algorithm MAY change for other versions of the The integrity check algorithm MAY change for other versions of the
protocol. protocol.
6.1. Integrity Check Processing 6.1. Integrity Check Processing
An endpoint sending a packet that has a long header and a type that An endpoint sending a packet that has a long header and a type that
skipping to change at page 20, line 22 skipping to change at page 20, line 22
Unprotected packets that do not contain a valid integrity check MUST Unprotected packets that do not contain a valid integrity check MUST
be discarded. be discarded.
6.2. The 64-bit FNV-1a Algorithm 6.2. The 64-bit FNV-1a Algorithm
QUIC uses the 64-bit version of the alternative Fowler/Noll/Vo hash QUIC uses the 64-bit version of the alternative Fowler/Noll/Vo hash
(FNV-1a) [FNV]. (FNV-1a) [FNV].
FNV-1a can be expressed in pseudocode as: FNV-1a can be expressed in pseudocode as:
"hash := offset basis for each input octet: hash := hash XOR input hash := offset basis
octet hash := hash * prime " for each input octet:
hash := hash XOR input octet
hash := hash * prime
That is, a 64-bit unsigned integer is initialized with an offset That is, a 64-bit unsigned integer is initialized with an offset
basis. Then, for each octet of the input, the exclusive binary OR of basis. Then, for each octet of the input, the exclusive binary OR of
the value is taken, then multiplied by a prime. Any overflow from the value is taken, then multiplied by a prime. Any overflow from
multiplication is discarded. multiplication is discarded.
The offset basis for the 64-bit FNV-1a is the decimal value The offset basis for the 64-bit FNV-1a is the decimal value
14695981039346656037 (in hex, 0xcbf29ce484222325). The prime is 14695981039346656037 (in hex, 0xcbf29ce484222325). The prime is
1099511628211 (in hex, 0x100000001b3; or as an expression 2^40 + 2^8 1099511628211 (in hex, 0x100000001b3; or as an expression 2^40 + 2^8
+ 0xb3). + 0xb3).
skipping to change at page 34, line 39 skipping to change at page 34, line 49
Section 5.2.2; "EXPORTER-QUIC Packet Number Secret" Section 5.6. Section 5.2.2; "EXPORTER-QUIC Packet Number Secret" Section 5.6.
The DTLS column is to be marked No. The Recommended column is to The DTLS column is to be marked No. The Recommended column is to
be marked Yes. be marked Yes.
14. References 14. References
14.1. Normative References 14.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-20 (work in progress), Version 1.3", draft-ietf-tls-tls13-21 (work in progress),
April 2017. July 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", draft-ietf-quic- Multiplexed and Secure Transport", draft-ietf-quic-
transport-latest (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,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
 End of changes. 15 change blocks. 
25 lines changed or deleted 28 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/