draft-ietf-quic-tls-04.txt		draft-ietf-quic-tls-05.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: December 15, 2017 sn3rd		Expires: February 16, 2018 sn3rd
	June 13, 2017		August 15, 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-05
	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 February 16, 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-04 . . . . . . . . . . . . . . 36
	C.2. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 36		C.2. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 36
	C.3. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 37		C.3. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 36
	C.4. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 37		C.4. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 36
			C.5. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 37
			C.6. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 37
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
	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 [I-D.ietf-tls-tls13]. TLS		Transport Layer Security (TLS) version 1.3 [I-D.ietf-tls-tls13]. TLS
	1.3 provides critical latency improvements for connection		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 6, line 26 ¶		skipping to change at page 6, line 26 ¶
	The TLS key exchange is resistent to tampering by attackers and it		The TLS key exchange is resistent to tampering by attackers and it
	produces shared secrets that cannot be controlled by either		produces shared secrets that cannot be controlled by either
	participating peer.		participating peer.
	3.2. TLS Handshake		3.2. TLS Handshake
	TLS 1.3 provides two basic handshake modes of interest to QUIC:		TLS 1.3 provides two basic handshake modes of interest to QUIC:
	o A full 1-RTT handshake in which the client is able to send		o A full 1-RTT handshake in which the client is able to send
	application data after one round trip and the server immediately		application data after one round trip and the server immediately
	after receiving the first handshake message from the client.		responds after receiving the first handshake message from the
			client.
	o A 0-RTT handshake in which the client uses information it has		o A 0-RTT handshake in which the client uses information it has
	previously learned about the server to send application data		previously learned about the server to send application data
	immediately. This application data can be replayed by an attacker		immediately. This application data can be replayed by an attacker
	so it MUST NOT carry a self-contained trigger for any non-		so it MUST NOT carry a self-contained trigger for any non-
	idempotent action.		idempotent action.
	A simplified TLS 1.3 handshake with 0-RTT application data is shown		A simplified TLS 1.3 handshake with 0-RTT application data is shown
	in Figure 2, see [I-D.ietf-tls-tls13] for more options and details.		in Figure 2, see [I-D.ietf-tls-tls13] for more options and details.
	skipping to change at page 13, line 25 ¶		skipping to change at page 13, line 25 ¶
	A badly configured TLS implementation could negotiate TLS 1.2 or		A badly configured TLS implementation could negotiate TLS 1.2 or
	another older version of TLS. An endpoint MUST terminate the		another older version of TLS. An endpoint MUST terminate the
	connection if a version of TLS older than 1.3 is negotiated.		connection if a version of TLS older than 1.3 is negotiated.
	4.4. ClientHello Size		4.4. ClientHello Size
	QUIC requires that the initial handshake packet from a client fit		QUIC requires that the initial handshake packet from a client fit
	within the payload of a single packet. The size limits on QUIC		within the payload of a single packet. The size limits on QUIC
	packets mean that a record containing a ClientHello needs to fit		packets mean that a record containing a ClientHello needs to fit
	within 1197 octets.		within 1171 octets.
	A TLS ClientHello can fit within this limit with ample space		A TLS ClientHello can fit within this limit with ample space
	remaining. However, there are several variables that could cause		remaining. However, there are several variables that could cause
	this limit to be exceeded. Implementations are reminded that large		this limit to be exceeded. Implementations are reminded that large
	session tickets or HelloRetryRequest cookies, multiple or large key		session tickets or HelloRetryRequest cookies, multiple or large key
	shares, and long lists of supported ciphers, signature algorithms,		shares, and long lists of supported ciphers, signature algorithms,
	versions, QUIC transport parameters, and other negotiable parameters		versions, QUIC transport parameters, and other negotiable parameters
	and extensions could cause this message to grow.		and extensions could cause this message to grow.
	For servers, the size of the session tickets and HelloRetryRequest		For servers, the size of the session tickets and HelloRetryRequest
	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 28, line 42 ¶		skipping to change at page 28, line 45 ¶
	9.1.2. ACK Frames		9.1.2. ACK Frames
	"ACK" frames are permitted prior to the handshake being complete.		"ACK" frames are permitted prior to the handshake being complete.
	Information learned from "ACK" frames cannot be entirely relied upon,		Information learned from "ACK" frames cannot be entirely relied upon,
	since an attacker is able to inject these packets. Timing and packet		since an attacker is able to inject these packets. Timing and packet
	retransmission information from "ACK" frames is critical to the		retransmission information from "ACK" frames is critical to the
	functioning of the protocol, but these frames might be spoofed or		functioning of the protocol, but these frames might be spoofed or
	altered.		altered.
	Endpoints MUST NOT use an unprotected "ACK" frame to acknowledge data		Endpoints MUST NOT use an "ACK" frame in an unprotected packet to
	that was protected by 0-RTT or 1-RTT keys. An endpoint MUST ignore		acknowledge packets that were protected by 0-RTT or 1-RTT keys. An
	an unprotected "ACK" frame if it claims to acknowledge data that was		endpoint MUST treat receipt of an "ACK" frame in an unprotected
	sent in a protected packet. Such an acknowledgement can only serve		packet that claims to acknowledge protected packets as a connection
	as a denial of service, since an endpoint that can read protected		error of type OPTIMISTIC_ACK. An endpoint that can read protected
	data is always able to send protected data.		data is always able to send protected data.
	ISSUE: What about 0-RTT data? Should we allow acknowledgment of		Note: 0-RTT data can be acknowledged by the server as it receives
	0-RTT with unprotected frames? If we don't, then 0-RTT data will		it, but any packets containing acknowledgments of 0-RTT data
	be unacknowledged until the handshake completes. This isn't a		cannot have packet protection removed by the client until the TLS
	problem if the handshake completes without loss, but it could mean		handshake is complete. The 1-RTT keys necessary to remove packet
	that 0-RTT stalls when a handshake packet disappears for any		protection cannot be derived until the client receives all server
	reason.		handshake messages.
	An endpoint SHOULD use data from unprotected or 0-RTT-protected "ACK"		An endpoint SHOULD use data from "ACK" frames carried in unprotected
	frames only during the initial handshake and while they have		packets or packets protected with 0-RTT keys only during the initial
	insufficient information from 1-RTT-protected "ACK" frames. Once		handshake. All "ACK" frames contained in unprotected packets that
	sufficient information has been obtained from protected messages,		are received after successful receipt of a packet protected with
	information obtained from less reliable sources can be discarded.		1-RTT keys MUST be discarded. An endpoint SHOULD therefore include
			acknowledgments for unprotected and any packets protected with 0-RTT
			keys until it sees an acknowledgment for a packet that is both
			protected with 1-RTT keys and contains an "ACK" frame.
	9.1.3. Updates to Data and Stream Limits		9.1.3. Updates to Data and Stream Limits
	"MAX_DATA", "MAX_STREAM_DATA", "BLOCKED", "STREAM_BLOCKED", and		"MAX_DATA", "MAX_STREAM_DATA", "BLOCKED", "STREAM_BLOCKED", and
	"MAX_STREAM_ID" frames MUST NOT be sent unprotected.		"MAX_STREAM_ID" frames MUST NOT be sent unprotected.
	Though data is exchanged on stream 0, the initial flow control window		Though data is exchanged on stream 0, the initial flow control window
	on that stream is sufficiently large to allow the TLS handshake to		on that stream is sufficiently large to allow the TLS handshake to
	complete. This limits the maximum size of the TLS handshake and		complete. This limits the maximum size of the TLS handshake and
	would prevent a server or client from using an abnormally large		would prevent a server or client from using an abnormally large
	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 (work in progress), June 2017.		transport (work in progress), August 2017.
	[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>.
	[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated		[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
	Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,		Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
	<http://www.rfc-editor.org/info/rfc5116>.		<http://www.rfc-editor.org/info/rfc5116>.
	skipping to change at page 35, line 32 ¶		skipping to change at page 35, line 42 ¶
	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>.
	[FNV] Fowler, G., Noll, L., Vo, K., Eastlake, D., and T. Hansen,		[FNV] Fowler, G., Noll, L., Vo, K., Eastlake, D., and T. Hansen,
	"The FNV Non-Cryptographic Hash Algorithm", draft-		"The FNV Non-Cryptographic Hash Algorithm", draft-
	eastlake-fnv-13 (work in progress), June 2017.		eastlake-fnv-13 (work in progress), June 2017.
	[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 (work in progress), June 2017.		QUIC", draft-ietf-quic-http (work in progress), August
			2017.
	[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 (work in		and Congestion Control", draft-ietf-quic-recovery (work in
	progress), June 2017.		progress), August 2017.
	[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,
	<http://www.rfc-editor.org/info/rfc2818>.		<http://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,
	<http://www.rfc-editor.org/info/rfc5280>.		<http://www.rfc-editor.org/info/rfc5280>.
	skipping to change at page 36, line 22 ¶		skipping to change at page 36, line 33 ¶
	Christian Huitema, Jana Iyengar, Adam Langley, Roberto Peon, Eric		Christian Huitema, Jana Iyengar, Adam Langley, Roberto Peon, Eric
	Rescorla, Ian Swett, and many others.		Rescorla, Ian Swett, and many others.
	Appendix C. Change Log		Appendix C. 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.
	C.1. Since draft-ietf-quic-tls-02		C.1. Since draft-ietf-quic-tls-04
			o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)
			C.2. Since draft-ietf-quic-tls-03
			No significant changes.
			C.3. Since draft-ietf-quic-tls-02
	o Updates to match changes in transport draft		o Updates to match changes in transport draft
	C.2. Since draft-ietf-quic-tls-01		C.4. Since draft-ietf-quic-tls-01
	o Use TLS alerts to signal TLS errors (#272, #374)		o Use TLS alerts to signal TLS errors (#272, #374)
	o Require ClientHello to fit in a single packet (#338)		o Require ClientHello to fit in a single packet (#338)
	o The second client handshake flight is now sent in the clear (#262,		o The second client handshake flight is now sent in the clear (#262,
	#337)		#337)
	o The QUIC header is included as AEAD Associated Data (#226, #243,		o The QUIC header is included as AEAD Associated Data (#226, #243,
	#302)		#302)
	skipping to change at page 37, line 5 ¶		skipping to change at page 37, line 21 ¶
	o Require at least TLS 1.3 (#138)		o Require at least TLS 1.3 (#138)
	o Define transport parameters as a TLS extension (#122)		o Define transport parameters as a TLS extension (#122)
	o Define handling for protected packets before the handshake		o Define handling for protected packets before the handshake
	completes (#39)		completes (#39)
	o Decouple QUIC version and ALPN (#12)		o Decouple QUIC version and ALPN (#12)
	C.3. Since draft-ietf-quic-tls-00		C.5. Since draft-ietf-quic-tls-00
	o Changed bit used to signal key phase		o Changed bit used to signal key phase
	o Updated key phase markings during the handshake		o Updated key phase markings during the handshake
	o Added TLS interface requirements section		o Added TLS interface requirements section
	o Moved to use of TLS exporters for key derivation		o Moved to use of TLS exporters for key derivation
	o Moved TLS error code definitions into this document		o Moved TLS error code definitions into this document
	C.4. Since draft-thomson-quic-tls-01		C.6. Since draft-thomson-quic-tls-01
	o Adopted as base for draft-ietf-quic-tls		o Adopted as base for draft-ietf-quic-tls
	o Updated authors/editors list		o Updated authors/editors list
	o Added status note		o Added status note
	Authors' Addresses		Authors' Addresses
	Martin Thomson (editor)		Martin Thomson (editor)
End of changes. 28 change blocks.
	54 lines changed or deleted		72 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/