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: December 29, 2017 sn3rd
June 13, 2017 June 27, 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 December 29, 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 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 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).
 End of changes. 12 change blocks. 
16 lines changed or deleted 19 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/