draft-ietf-quic-tls-09.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: August 1, 2018 sn3rd Expires: August 20, 2018 sn3rd
January 28, 2018 February 16, 2018
Using Transport Layer Security (TLS) to Secure QUIC Using Transport Layer Security (TLS) to Secure QUIC
draft-ietf-quic-tls-09 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 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 August 1, 2018. This Internet-Draft will expire on August 20, 2018.
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 3, line 14 skipping to change at page 3, line 14
7.1.1. Stateless Address Validation . . . . . . . . . . . . 25 7.1.1. Stateless Address Validation . . . . . . . . . . . . 25
7.1.2. Sending HelloRetryRequest . . . . . . . . . . . . . . 25 7.1.2. Sending HelloRetryRequest . . . . . . . . . . . . . . 25
7.2. NewSessionTicket Address Validation . . . . . . . . . . . 25 7.2. NewSessionTicket Address Validation . . . . . . . . . . . 25
7.3. Address Validation Token Integrity . . . . . . . . . . . 26 7.3. Address Validation Token Integrity . . . . . . . . . . . 26
8. Pre-handshake QUIC Messages . . . . . . . . . . . . . . . . . 26 8. Pre-handshake QUIC Messages . . . . . . . . . . . . . . . . . 26
8.1. Unprotected Packets Prior to Handshake Completion . . . . 27 8.1. Unprotected Packets Prior to Handshake Completion . . . . 27
8.1.1. STREAM Frames . . . . . . . . . . . . . . . . . . . . 27 8.1.1. STREAM Frames . . . . . . . . . . . . . . . . . . . . 27
8.1.2. ACK Frames . . . . . . . . . . . . . . . . . . . . . 28 8.1.2. ACK Frames . . . . . . . . . . . . . . . . . . . . . 28
8.1.3. Updates to Data and Stream Limits . . . . . . . . . . 28 8.1.3. Updates to Data and Stream Limits . . . . . . . . . . 28
8.1.4. Handshake Failures . . . . . . . . . . . . . . . . . 29 8.1.4. Handshake Failures . . . . . . . . . . . . . . . . . 29
8.1.5. Denial of Service with Unprotected Packets . . . . . 29 8.1.5. Address Verification . . . . . . . . . . . . . . . . 29
8.1.6. Denial of Service with Unprotected Packets . . . . . 29
8.2. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 30 8.2. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 30
8.3. Receiving Out-of-Order Protected Frames . . . . . . . . . 30 8.3. Receiving Out-of-Order Protected Frames . . . . . . . . . 30
9. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 30 9. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 31
9.1. Protocol and Version Negotiation . . . . . . . . . . . . 31 9.1. Protocol and Version Negotiation . . . . . . . . . . . . 31
9.2. QUIC Transport Parameters Extension . . . . . . . . . . . 31 9.2. QUIC Transport Parameters Extension . . . . . . . . . . . 31
9.3. Priming 0-RTT . . . . . . . . . . . . . . . . . . . . . . 32 9.3. Priming 0-RTT . . . . . . . . . . . . . . . . . . . . . . 32
10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32
10.1. Packet Reflection Attack Mitigation . . . . . . . . . . 32 10.1. Packet Reflection Attack Mitigation . . . . . . . . . . 33
10.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 33 10.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 33
11. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 33 11. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 33
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
13.1. Normative References . . . . . . . . . . . . . . . . . . 35 13.1. Normative References . . . . . . . . . . . . . . . . . . 35
13.2. Informative References . . . . . . . . . . . . . . . . . 36 13.2. Informative References . . . . . . . . . . . . . . . . . 36
13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 36 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 36
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 36 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 36
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 37 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 37
C.1. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 37 C.1. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 37
C.2. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 37 C.2. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 37
C.3. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 37 C.3. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 37
C.4. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 37 C.4. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 37
skipping to change at page 16, line 52 skipping to change at page 16, line 52
"client 1rtt" for the client and "server 1rtt" for the server, and "client 1rtt" for the client and "server 1rtt" for the server, and
the same output Length as the PRF hash function selected by TLS. the same output Length as the PRF hash function selected by TLS.
client_pp_secret_<N+1> = client_pp_secret_<N+1> =
QHKDF-Expand(client_pp_secret_<N>, "client 1rtt", Hash.length) QHKDF-Expand(client_pp_secret_<N>, "client 1rtt", Hash.length)
server_pp_secret_<N+1> = server_pp_secret_<N+1> =
QHKDF-Expand(server_pp_secret_<N>, "server 1rtt", Hash.length) QHKDF-Expand(server_pp_secret_<N>, "server 1rtt", Hash.length)
This allows for a succession of new secrets to be created as needed. This allows for a succession of new secrets to be created as needed.
HKDF-Expand-Label uses HKDF-Expand [RFC5869] as shown: QHKDF-Expand uses HKDF-Expand [RFC5869] as shown:
QHKDF-Expand(Secret, Label, Length) = QHKDF-Expand(Secret, Label, Length) =
HKDF-Expand(Secret, QuicHkdfLabel, Length) HKDF-Expand(Secret, QuicHkdfLabel, Length)
Where the info parameter, QuicHkdfLabel, is specified as: Where the info parameter, QuicHkdfLabel, is specified as:
struct { struct {
uint16 length = Length; uint16 length = Length;
opaque label<6..255> = "QUIC " + Label; opaque label<6..255> = "QUIC " + Label;
uint8 hashLength = 0; uint8 hashLength = 0;
} QuicHkdfLabel; } QuicHkdfLabel;
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) || 0x1f || info = (HashLen / 256) || (HashLen % 256) || 0x10 ||
"QUIC client 1rtt" || 0x00 "QUIC client 1rtt" || 0x00
5.2.4. Packet Protection Key and IV 5.2.4. 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 [TLS13], using different expansion as defined in Section 7.3 of [TLS13], using different
values for the input secret and labels. QUIC uses the AEAD function values for the input secret and labels. 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
skipping to change at page 29, line 18 skipping to change at page 29, line 18
Similarly, there is no need to increase the number of allowed streams Similarly, there is no need to increase the number of allowed streams
until the handshake completes. until the handshake completes.
8.1.4. Handshake Failures 8.1.4. Handshake Failures
The "CONNECTION_CLOSE" frame MAY be sent by either endpoint in a The "CONNECTION_CLOSE" frame MAY be sent by either endpoint in a
Handshake packet. This allows an endpoint to signal a fatal error Handshake packet. This allows an endpoint to signal a fatal error
with connection establishment. A "STREAM" frame carrying a TLS alert with connection establishment. A "STREAM" frame carrying a TLS alert
MAY be included in the same packet. MAY be included in the same packet.
8.1.5. Denial of Service with Unprotected Packets 8.1.5. Address Verification
In order to perform source-address verification before the handshake
is complete, "PATH_CHALLENGE" and "PATH_RESPONSE" frames MAY be
exchanged unprotected.
8.1.6. Denial of Service with Unprotected Packets
Accepting unprotected - specifically unauthenticated - packets Accepting unprotected - specifically unauthenticated - packets
presents a denial of service risk to endpoints. An attacker that is presents a denial of service risk to endpoints. An attacker that is
able to inject unprotected packets can cause a recipient to drop even able to inject unprotected packets can cause a recipient to drop even
protected packets with a matching sequence number. The spurious protected packets with a matching sequence number. The spurious
packet shadows the genuine packet, causing the genuine packet to be packet shadows the genuine packet, causing the genuine packet to be
ignored as redundant. ignored as redundant.
Once the TLS handshake is complete, both peers MUST ignore Once the TLS handshake is complete, both peers MUST ignore
unprotected packets. From that point onward, unprotected messages unprotected packets. From that point onward, unprotected messages
 End of changes. 10 change blocks. 
11 lines changed or deleted 18 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/