< draft-ietf-quic-tls-18.txt		draft-ietf-quic-tls-19.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: July 27, 2019 sn3rd		Expires: September 12, 2019 sn3rd
	January 23, 2019		March 11, 2019
	Using TLS to Secure QUIC		Using TLS to Secure QUIC
	draft-ietf-quic-tls-18		draft-ietf-quic-tls-19
	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 July 27, 2019.		This Internet-Draft will expire on September 12, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 6 ¶		skipping to change at page 3, line 6 ¶
	5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 24		5.6. Use of 0-RTT Keys . . . . . . . . . . . . . . . . . . . . 24
	5.7. Receiving Out-of-Order Protected Frames . . . . . . . . . 25		5.7. Receiving Out-of-Order Protected Frames . . . . . . . . . 25
	6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 25		6. Key Update . . . . . . . . . . . . . . . . . . . . . . . . . 25
	7. Security of Initial Messages . . . . . . . . . . . . . . . . 27		7. Security of Initial Messages . . . . . . . . . . . . . . . . 27
	8. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 28		8. QUIC-Specific Additions to the TLS Handshake . . . . . . . . 28
	8.1. Protocol and Version Negotiation . . . . . . . . . . . . 28		8.1. Protocol and Version Negotiation . . . . . . . . . . . . 28
	8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 28		8.2. QUIC Transport Parameters Extension . . . . . . . . . . . 28
	8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 29		8.3. Removing the EndOfEarlyData Message . . . . . . . . . . . 29
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 29		9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
	9.1. Packet Reflection Attack Mitigation . . . . . . . . . . . 29		9.1. Replay Attacks with 0-RTT . . . . . . . . . . . . . . . . 29
	9.2. Peer Denial of Service . . . . . . . . . . . . . . . . . 30		9.2. Packet Reflection Attack Mitigation . . . . . . . . . . . 30
	9.3. Header Protection Analysis . . . . . . . . . . . . . . . 30		9.3. Peer Denial of Service . . . . . . . . . . . . . . . . . 31
	9.4. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 31		9.4. Header Protection Analysis . . . . . . . . . . . . . . . 31
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32		9.5. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 32
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
	11.1. Normative References . . . . . . . . . . . . . . . . . . 32		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
	11.2. Informative References . . . . . . . . . . . . . . . . . 33		11.1. Normative References . . . . . . . . . . . . . . . . . . 33
	11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34		11.2. Informative References . . . . . . . . . . . . . . . . . 34
	Appendix A. Sample Initial Packet Protection . . . . . . . . . . 34		11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35
	A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 34		Appendix A. Sample Initial Packet Protection . . . . . . . . . . 35
	A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 35		A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 35
	A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 37		A.2. Client Initial . . . . . . . . . . . . . . . . . . . . . 36
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 38		A.3. Server Initial . . . . . . . . . . . . . . . . . . . . . 38
	B.1. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 38		Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 39
	B.2. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 38		B.1. Since draft-ietf-quic-tls-18 . . . . . . . . . . . . . . 39
	B.3. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 39		B.2. Since draft-ietf-quic-tls-17 . . . . . . . . . . . . . . 39
	B.4. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 39		B.3. Since draft-ietf-quic-tls-14 . . . . . . . . . . . . . . 39
	B.5. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 39		B.4. Since draft-ietf-quic-tls-13 . . . . . . . . . . . . . . 40
	B.6. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 39		B.5. Since draft-ietf-quic-tls-12 . . . . . . . . . . . . . . 40
	B.7. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 39		B.6. Since draft-ietf-quic-tls-11 . . . . . . . . . . . . . . 40
	B.8. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 40		B.7. Since draft-ietf-quic-tls-10 . . . . . . . . . . . . . . 40
	B.9. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 40		B.8. Since draft-ietf-quic-tls-09 . . . . . . . . . . . . . . 41
	B.10. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 40		B.9. Since draft-ietf-quic-tls-08 . . . . . . . . . . . . . . 41
	B.11. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 40		B.10. Since draft-ietf-quic-tls-07 . . . . . . . . . . . . . . 41
	B.12. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 40		B.11. Since draft-ietf-quic-tls-05 . . . . . . . . . . . . . . 41
	B.13. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 40		B.12. Since draft-ietf-quic-tls-04 . . . . . . . . . . . . . . 41
	B.14. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 40		B.13. Since draft-ietf-quic-tls-03 . . . . . . . . . . . . . . 41
	B.15. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 41		B.14. Since draft-ietf-quic-tls-02 . . . . . . . . . . . . . . 41
	B.16. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 41		B.15. Since draft-ietf-quic-tls-01 . . . . . . . . . . . . . . 41
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41		B.16. Since draft-ietf-quic-tls-00 . . . . . . . . . . . . . . 42
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 41		B.17. Since draft-thomson-quic-tls-01 . . . . . . . . . . . . . 42
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 42
			Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 42
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
	1. Introduction		1. Introduction
	This document describes how QUIC [QUIC-TRANSPORT] is secured using		This document describes how QUIC [QUIC-TRANSPORT] is secured using
	TLS [TLS13].		TLS [TLS13].
	TLS 1.3 provides critical latency improvements for connection		TLS 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 5 ¶		skipping to change at page 6, line 7 ¶
	() Indicates messages protected by early data (0-RTT) keys		() Indicates messages protected by early data (0-RTT) keys
	{} Indicates messages protected using handshake keys		{} Indicates messages protected using handshake keys
	[] Indicates messages protected using application data		[] Indicates messages protected using application data
	(1-RTT) keys		(1-RTT) keys
	Figure 1: TLS Handshake with 0-RTT		Figure 1: TLS Handshake with 0-RTT
	Data is protected using a number of encryption levels:		Data is protected using a number of encryption levels:
	o Plaintext		o Initial Keys
	o Early Data (0-RTT) Keys		o Early Data (0-RTT) Keys
	o Handshake Keys		o Handshake Keys
	o Application Data (1-RTT) Keys		o Application Data (1-RTT) Keys
	Application data may appear only in the early data and application		Application data may appear only in the early data and application
	data levels. Handshake and Alert messages may appear in any level.		data levels. Handshake and Alert messages may appear in any level.
	skipping to change at page 6, line 33 ¶		skipping to change at page 6, line 35 ¶
	QUIC [QUIC-TRANSPORT] assumes responsibility for the confidentiality		QUIC [QUIC-TRANSPORT] assumes responsibility for the confidentiality
	and integrity protection of packets. For this it uses keys derived		and integrity protection of packets. For this it uses keys derived
	from a TLS handshake [TLS13], but instead of carrying TLS records		from a TLS handshake [TLS13], but instead of carrying TLS records
	over QUIC (as with TCP), TLS Handshake and Alert messages are carried		over QUIC (as with TCP), TLS Handshake and Alert messages are carried
	directly over the QUIC transport, which takes over the		directly over the QUIC transport, which takes over the
	responsibilities of the TLS record layer, as shown below.		responsibilities of the TLS record layer, as shown below.
	+--------------+--------------+ +-------------+		+--------------+--------------+ +-------------+
	| TLS | TLS | | QUIC |		| TLS | TLS | | QUIC |
	| Handshake | Alerts | | Applications|		| Handshake | Alerts | | Applications|
	| | | | (h2q, etc.) |		| | | | (h3, etc.) |
	+--------------+--------------+-+-------------+		+--------------+--------------+-+-------------+
	| |		| |
	| QUIC Transport |		| QUIC Transport |
	| (streams, reliability, congestion, etc.) |		| (streams, reliability, congestion, etc.) |
	| |		| |
	+---------------------------------------------+		+---------------------------------------------+
	| |		| |
	| QUIC Packet Protection |		| QUIC Packet Protection |
	| |		| |
	+---------------------------------------------+		+---------------------------------------------+
	skipping to change at page 8, line 11 ¶		skipping to change at page 8, line 11 ¶
	produced by TLS is associated with the set of keys that TLS is		produced by TLS is associated with the set of keys that TLS is
	currently using. If QUIC needs to retransmit that data, it MUST use		currently using. If QUIC needs to retransmit that data, it MUST use
	the same keys even if TLS has already updated to newer keys.		the same keys even if TLS has already updated to newer keys.
	One important difference between TLS records (used with TCP) and QUIC		One important difference between TLS records (used with TCP) and QUIC
	CRYPTO frames is that in QUIC multiple frames may appear in the same		CRYPTO frames is that in QUIC multiple frames may appear in the same
	QUIC packet as long as they are associated with the same encryption		QUIC packet as long as they are associated with the same encryption
	level. For instance, an implementation might bundle a Handshake		level. For instance, an implementation might bundle a Handshake
	message and an ACK for some Handshake data into the same packet.		message and an ACK for some Handshake data into the same packet.
	Each encryption level has a specific list of frames which may appear		Some frames are prohibited in different encryption levels, others
	in it. The rules here generalize those of TLS, in that frames		cannot be sent. The rules here generalize those of TLS, in that
	associated with establishing the connection can usually appear at any		frames associated with establishing the connection can usually appear
	encryption level, whereas those associated with transferring data can		at any encryption level, whereas those associated with transferring
	only appear in the 0-RTT and 1-RTT encryption levels:		data can only appear in the 0-RTT and 1-RTT encryption levels:
	o CRYPTO frames MAY appear in packets of any encryption level except
	0-RTT.
	o CONNECTION_CLOSE MAY appear in packets of any encryption level
	other than 0-RTT.
	o PADDING frames MAY appear in packets of any encryption level.		o PADDING frames MAY appear in packets of any encryption level.
			o CRYPTO and CONNECTION_CLOSE frames MAY appear in packets of any
			encryption level except 0-RTT.
	o ACK frames MAY appear in packets of any encryption level other		o ACK frames MAY appear in packets of any encryption level other
	than 0-RTT, but can only acknowledge packets which appeared in		than 0-RTT, but can only acknowledge packets which appeared in
	that packet number space.		that packet number space.
	o STREAM frames MUST ONLY appear in the 0-RTT and 1-RTT levels.		o All other frame types MUST only be sent in the 0-RTT and 1-RTT
			levels.
	o All other frame types MUST only appear at the 1-RTT levels.		Note that it is not possible to send the following frames in 0-RTT
			for various reasons: ACK, CRYPTO, NEW_TOKEN, PATH_RESPONSE, and
			RETIRE_CONNECTION_ID.
	Because packets could be reordered on the wire, QUIC uses the packet		Because packets could be reordered on the wire, QUIC uses the packet
	type to indicate which level a given packet was encrypted under, as		type to indicate which level a given packet was encrypted under, as
	shown in Table 1. When multiple packets of different encryption		shown in Table 1. When multiple packets of different encryption
	levels need to be sent, endpoints SHOULD use coalesced packets to		levels need to be sent, endpoints SHOULD use coalesced packets to
	send them in the same UDP datagram.		send them in the same UDP datagram.
	+-----------------+------------------+-----------+		+-----------------+------------------+-----------+
	| Packet Type | Encryption Level | PN Space |		| Packet Type | Encryption Level | PN Space |
	+-----------------+------------------+-----------+		+-----------------+------------------+-----------+
	skipping to change at page 18, line 24 ¶		skipping to change at page 18, line 24 ¶
	Each encryption level has separate secret values for protection of		Each encryption level has separate secret values for protection of
	packets sent in each direction. These traffic secrets are derived by		packets sent in each direction. These traffic secrets are derived by
	TLS (see Section 7.1 of [TLS13]) and are used by QUIC for all		TLS (see Section 7.1 of [TLS13]) and are used by QUIC for all
	encryption levels except the Initial encryption level. The secrets		encryption levels except the Initial encryption level. The secrets
	for the Initial encryption level are computed based on the client's		for the Initial encryption level are computed based on the client's
	initial Destination Connection ID, as described in Section 5.2.		initial Destination Connection ID, as described in Section 5.2.
	The keys used for packet protection are computed from the TLS secrets		The keys used for packet protection are computed from the TLS secrets
	using the KDF provided by TLS. In TLS 1.3, the HKDF-Expand-Label		using the KDF provided by TLS. In TLS 1.3, the HKDF-Expand-Label
	function described in Section 7.1 of [TLS13]) is used, using the hash		function described in Section 7.1 of [TLS13] is used, using the hash
	function from the negotiated cipher suite. Other versions of TLS		function from the negotiated cipher suite. Other versions of TLS
	MUST provide a similar function in order to be used QUIC.		MUST provide a similar function in order to be used with QUIC.
	The current encryption level secret and the label "quic key" are		The current encryption level secret and the label "quic key" are
	input to the KDF to produce the AEAD key; the label "quic iv" is used		input to the KDF to produce the AEAD key; the label "quic iv" is used
	to derive the IV, see Section 5.3. The header protection key uses		to derive the IV, see Section 5.3. The header protection key uses
	the "quic hp" label, see Section 5.4). Using these labels provides		the "quic hp" label, see Section 5.4. Using these labels provides
	key separation between QUIC and TLS, see Section 9.4.		key separation between QUIC and TLS, see Section 9.5.
	The KDF used for initial secrets is always the HKDF-Expand-Label		The KDF used for initial secrets is always the HKDF-Expand-Label
	function from TLS 1.3 (see Section 5.2).		function from TLS 1.3 (see Section 5.2).
	5.2. Initial Secrets		5.2. Initial Secrets
	Initial packets are protected with a secret derived from the		Initial packets are protected with a secret derived from the
	Destination Connection ID field from the client's first Initial		Destination Connection ID field from the client's first Initial
	packet of the connection. Specifically:		packet of the connection. Specifically:
	skipping to change at page 19, line 18 ¶		skipping to change at page 19, line 18 ¶
	The connection ID used with HKDF-Expand-Label is the Destination		The connection ID used with HKDF-Expand-Label is the Destination
	Connection ID in the Initial packet sent by the client. This will be		Connection ID in the Initial packet sent by the client. This will be
	a randomly-selected value unless the client creates the Initial		a randomly-selected value unless the client creates the Initial
	packet after receiving a Retry packet, where the Destination		packet after receiving a Retry packet, where the Destination
	Connection ID is selected by the server.		Connection ID is selected by the server.
	The value of initial_salt is a 20 byte sequence shown in the figure		The value of initial_salt is a 20 byte sequence shown in the figure
	in hexadecimal notation. Future versions of QUIC SHOULD generate a		in hexadecimal notation. Future versions of QUIC SHOULD generate a
	new salt value, thus ensuring that the keys are different for each		new salt value, thus ensuring that the keys are different for each
	version of QUIC. This prevents a middlebox that only recognizes one		version of QUIC. This prevents a middlebox that only recognizes one
	version of QUIC from seeing or modifying the contents of handshake		version of QUIC from seeing or modifying the contents of packets from
	packets from future versions.		future versions.
	The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for		The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for
	Initial packets even where the TLS versions offered do not include		Initial packets even where the TLS versions offered do not include
	TLS 1.3.		TLS 1.3.
	Appendix A contains test vectors for the initial packet encryption.		Appendix A contains test vectors for the initial packet encryption.
	Note: The Destination Connection ID is of arbitrary length, and it		Note: The Destination Connection ID is of arbitrary length, and it
	could be zero length if the server sends a Retry packet with a		could be zero length if the server sends a Retry packet with a
	zero-length Source Connection ID field. In this case, the Initial		zero-length Source Connection ID field. In this case, the Initial
	skipping to change at page 19, line 50 ¶		skipping to change at page 19, line 50 ¶
	used.		used.
	Packets are protected prior to applying header protection		Packets are protected prior to applying header protection
	(Section 5.4). The unprotected packet header is part of the		(Section 5.4). The unprotected packet header is part of the
	associated data (A). When removing packet protection, an endpoint		associated data (A). When removing packet protection, an endpoint
	first removes the header protection.		first removes the header protection.
	All QUIC packets other than Version Negotiation and Retry packets are		All QUIC packets other than Version Negotiation and Retry packets are
	protected with an AEAD algorithm [AEAD]. Prior to establishing a		protected with an AEAD algorithm [AEAD]. Prior to establishing a
	shared secret, packets are protected with AEAD_AES_128_GCM and a key		shared secret, packets are protected with AEAD_AES_128_GCM and a key
	derived from the destination connection ID in the client's first		derived from the Destination Connection ID in the client's first
	Initial packet (see Section 5.2). This provides protection against		Initial packet (see Section 5.2). This provides protection against
	off-path attackers and robustness against QUIC version unaware		off-path attackers and robustness against QUIC version unaware
	middleboxes, but not against on-path attackers.		middleboxes, but not against on-path attackers.
	QUIC can use any of the ciphersuites defined in [TLS13] with the		QUIC can use any of the ciphersuites defined in [TLS13] with the
	exception of TLS_AES_128_CCM_8_SHA256. The AEAD for that		exception of TLS_AES_128_CCM_8_SHA256. The AEAD for that
	ciphersuite, AEAD_AES_128_CCM_8 [CCM], does not produce a large		ciphersuite, AEAD_AES_128_CCM_8 [CCM], does not produce a large
	enough authentication tag for use with the header protection designs		enough authentication tag for use with the header protection designs
	provided (see Section 5.4). All other ciphersuites defined in		provided (see Section 5.4). All other ciphersuites defined in
	[TLS13] have a 16-byte authentication tag and produce an output 16		[TLS13] have a 16-byte authentication tag and produce an output 16
	skipping to change at page 29, line 8 ¶		skipping to change at page 29, line 8 ¶
	Including transport parameters in the TLS handshake provides		Including transport parameters in the TLS handshake provides
	integrity protection for these values.		integrity protection for these values.
	enum {		enum {
	quic_transport_parameters(0xffa5), (65535)		quic_transport_parameters(0xffa5), (65535)
	} ExtensionType;		} ExtensionType;
	The "extension_data" field of the quic_transport_parameters extension		The "extension_data" field of the quic_transport_parameters extension
	contains a value that is defined by the version of QUIC that is in		contains a value that is defined by the version of QUIC that is in
	use. The quic_transport_parameters extension carries a		use. The quic_transport_parameters extension carries a
	TransportParameters when the version of QUIC defined in		TransportParameters struct when the version of QUIC defined in
	[QUIC-TRANSPORT] is used.		[QUIC-TRANSPORT] is used.
	The quic_transport_parameters extension is carried in the ClientHello		The quic_transport_parameters extension is carried in the ClientHello
	and the EncryptedExtensions messages during the handshake.		and the EncryptedExtensions messages during the handshake.
	While the transport parameters are technically available prior to the		While the transport parameters are technically available prior to the
	completion of the handshake, they cannot be fully trusted until the		completion of the handshake, they cannot be fully trusted until the
	handshake completes, and reliance on them should be minimized.		handshake completes, and reliance on them should be minimized.
	However, any tampering with the parameters will cause the handshake		However, any tampering with the parameters will cause the handshake
	to fail.		to fail.
	skipping to change at page 29, line 47 ¶		skipping to change at page 29, line 47 ¶
	9. Security Considerations		9. Security Considerations
	There are likely to be some real clangers here eventually, but the		There are likely to be some real clangers here eventually, but the
	current set of issues is well captured in the relevant sections of		current set of issues is well captured in the relevant sections of
	the main text.		the main text.
	Never assume that because it isn't in the security considerations		Never assume that because it isn't in the security considerations
	section it doesn't affect security. Most of this document does.		section it doesn't affect security. Most of this document does.
	9.1. Packet Reflection Attack Mitigation		9.1. Replay Attacks with 0-RTT
			As described in Section 8 of [TLS13], use of TLS early data comes
			with an exposure to replay attack. The use of 0-RTT in QUIC is
			similarly vulnerable to replay attack.
			Endpoints MUST implement and use the replay protections described in
			[TLS13], however it is recognized that these protections are
			imperfect. Therefore, additional consideration of the risk of replay
			is needed.
			QUIC is not vulnerable to replay attack, except via the application
			protocol information it might carry. The management of QUIC protocol
			state based on the frame types defined in [QUIC-TRANSPORT] is not
			vulnerable to replay. Processing of QUIC frames is idempotent and
			cannot result in invalid connection states if frames are replayed,
			reordered or lost. QUIC connections do not produce effects that last
			beyond the lifetime of the connection, except for those produced by
			the application protocol that QUIC serves.
			Note: TLS session tickets and address validation tokens are used to
			carry QUIC configuration information between connections. These
			MUST NOT be used to carry application semantics. The potential
			for reuse of these tokens means that they require stronger
			protections against replay.
			A server that accepts 0-RTT on a connection incurs a higher cost than
			accepting a connection without 0-RTT. This includes higher
			processing and computation costs. Servers need to consider the
			probability of replay and all associated costs when accepting 0-RTT.
			Ultimately, the responsibility for managing the risks of replay
			attacks with 0-RTT lies with an application protocol. An application
			protocol that uses QUIC MUST describe how the protocol uses 0-RTT and
			the measures that are employed to protect against replay attack. An
			analysis of replay risk needs to consider all QUIC protocol features
			that carry application semantics.
			Disabling 0-RTT entirely is the most effective defense against replay
			attack.
			QUIC extensions MUST describe how replay attacks affects their
			operation, or prohibit their use in 0-RTT. Application protocols
			MUST either prohibit the use of extensions that carry application
			semantics in 0-RTT or provide replay mitigation strategies.
			9.2. Packet Reflection Attack Mitigation
	A small ClientHello that results in a large block of handshake		A small ClientHello that results in a large block of handshake
	messages from a server can be used in packet reflection attacks to		messages from a server can be used in packet reflection attacks to
	amplify the traffic generated by an attacker.		amplify the traffic generated by an attacker.
	QUIC includes three defenses against this attack. First, the packet		QUIC includes three defenses against this attack. First, the packet
	containing a ClientHello MUST be padded to a minimum size. Second,		containing a ClientHello MUST be padded to a minimum size. Second,
	if responding to an unverified source address, the server is		if responding to an unverified source address, the server is
	forbidden to send more than three UDP datagrams in its first flight		forbidden to send more than three UDP datagrams in its first flight
	(see Section 8.1 of [QUIC-TRANSPORT]). Finally, because		(see Section 8.1 of [QUIC-TRANSPORT]). Finally, because
	acknowledgements of Handshake packets are authenticated, a blind		acknowledgements of Handshake packets are authenticated, a blind
	attacker cannot forge them. Put together, these defenses limit the		attacker cannot forge them. Put together, these defenses limit the
	level of amplification.		level of amplification.
	9.2. Peer Denial of Service		9.3. Peer Denial of Service
	QUIC, TLS, and HTTP/2 all contain messages that have legitimate uses		QUIC, TLS, and HTTP/2 all contain messages that have legitimate uses
	in some contexts, but that can be abused to cause a peer to expend		in some contexts, but that can be abused to cause a peer to expend
	processing resources without having any observable impact on the		processing resources without having any observable impact on the
	state of the connection. If processing is disproportionately large		state of the connection. If processing is disproportionately large
	in comparison to the observable effects on bandwidth or state, then		in comparison to the observable effects on bandwidth or state, then
	this could allow a malicious peer to exhaust processing capacity		this could allow a malicious peer to exhaust processing capacity
	without consequence.		without consequence.
	QUIC prohibits the sending of empty "STREAM" frames unless they are		QUIC prohibits the sending of empty "STREAM" frames unless they are
	marked with the FIN bit. This prevents "STREAM" frames from being		marked with the FIN bit. This prevents "STREAM" frames from being
	sent that only waste effort.		sent that only waste effort.
	While there are legitimate uses for some redundant packets,		While there are legitimate uses for some redundant packets,
	implementations SHOULD track redundant packets and treat excessive		implementations SHOULD track redundant packets and treat excessive
	volumes of any non-productive packets as indicative of an attack.		volumes of any non-productive packets as indicative of an attack.
	9.3. Header Protection Analysis		9.4. Header Protection Analysis
	Header protection relies on the packet protection AEAD being a		Header protection relies on the packet protection AEAD being a
	pseudorandom function (PRF), which is not a property that AEAD		pseudorandom function (PRF), which is not a property that AEAD
	algorithms guarantee. Therefore, no strong assurances about the		algorithms guarantee. Therefore, no strong assurances about the
	general security of this mechanism can be shown in the general case.		general security of this mechanism can be shown in the general case.
	The AEAD algorithms described in this document are assumed to be		The AEAD algorithms described in this document are assumed to be
	PRFs.		PRFs.
	The header protection algorithms defined in this document take the		The header protection algorithms defined in this document take the
	form:		form:
	skipping to change at page 31, line 32 ¶		skipping to change at page 32, line 31 ¶
	reveal through timing side-channels that the packet number matches a		reveal through timing side-channels that the packet number matches a
	received packet. For authentication to be free from side-channels,		received packet. For authentication to be free from side-channels,
	the entire process of header protection removal, packet number		the entire process of header protection removal, packet number
	recovery, and packet protection removal MUST be applied together		recovery, and packet protection removal MUST be applied together
	without timing and other side-channels.		without timing and other side-channels.
	For the sending of packets, construction and protection of packet		For the sending of packets, construction and protection of packet
	payloads and packet numbers MUST be free from side-channels that		payloads and packet numbers MUST be free from side-channels that
	would reveal the packet number or its encoded size.		would reveal the packet number or its encoded size.
	9.4. Key Diversity		9.5. Key Diversity
	In using TLS, the central key schedule of TLS is used. As a result		In using TLS, the central key schedule of TLS is used. As a result
	of the TLS handshake messages being integrated into the calculation		of the TLS handshake messages being integrated into the calculation
	of secrets, the inclusion of the QUIC transport parameters extension		of secrets, the inclusion of the QUIC transport parameters extension
	ensures that handshake and 1-RTT keys are not the same as those that		ensures that handshake and 1-RTT keys are not the same as those that
	might be produced by a server running TLS over TCP. However, 0-RTT		might be produced by a server running TLS over TCP. To avoid the
	keys only include the ClientHello message and might therefore use the		possibility of cross-protocol key synchronization, additional
	same secrets. To avoid the possibility of cross-protocol key		measures are provided to improve key separation.
	synchronization, additional measures are provided to improve key
	separation.
	The QUIC packet protection keys and IVs are derived using a different		The QUIC packet protection keys and IVs are derived using a different
	label than the equivalent keys in TLS.		label than the equivalent keys in TLS.
	To preserve this separation, a new version of QUIC SHOULD define new		To preserve this separation, a new version of QUIC SHOULD define new
	labels for key derivation for packet protection key and IV, plus the		labels for key derivation for packet protection key and IV, plus the
	header protection keys.		header protection keys. This version of QUIC uses the string "quic".
			Other versions can use a version-specific label in place of that
			string.
	The initial secrets also use a key that is specific to the negotiated		The initial secrets use a key that is specific to the negotiated QUIC
	QUIC version. New QUIC versions SHOULD define a new salt value used		version. New QUIC versions SHOULD define a new salt value used in
	in calculating initial secrets.		calculating initial secrets.
	10. IANA Considerations		10. IANA Considerations
	This document does not create any new IANA registries, but it		This document does not create any new IANA registries, but it
	registers the values in the following registries:		registers the values in the following registries:
	o TLS ExtensionsType Registry [TLS-REGISTRIES] - IANA is to register		o TLS ExtensionsType Registry [TLS-REGISTRIES] - IANA is to register
	the quic_transport_parameters extension found in Section 8.2. The		the quic_transport_parameters extension found in Section 8.2. The
	Recommended column is to be marked Yes. The TLS 1.3 Column is to		Recommended column is to be marked Yes. The TLS 1.3 Column is to
	include CH and EE.		include CH and EE.
	skipping to change at page 32, line 37 ¶		skipping to change at page 33, line 37 ¶
	[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-18 (work		and Congestion Control", draft-ietf-quic-recovery-19 (work
	in progress), January 2019.		in progress), March 2019.
	[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-18 (work in progress), January 2019.		transport-19 (work in progress), March 2019.
	[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 33, line 45 ¶		skipping to change at page 34, line 45 ¶
	Transport Layer Security (TLS)", RFC 6655,		Transport Layer Security (TLS)", RFC 6655,
	DOI 10.17487/RFC6655, July 2012,		DOI 10.17487/RFC6655, July 2012,
	<https://www.rfc-editor.org/info/rfc6655>.		<https://www.rfc-editor.org/info/rfc6655>.
	[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-18 (work in progress), January		QUIC", draft-ietf-quic-http-19 (work in progress), March
	2019.		2019.
	[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,
	skipping to change at page 38, line 31 ¶		skipping to change at page 39, line 31 ¶
	15599ef5014ea38c44bdfd387c03b527 5c35e009b6238f831420047c7271281c		15599ef5014ea38c44bdfd387c03b527 5c35e009b6238f831420047c7271281c
	cb54df7884		cb54df7884
	Appendix B. Change Log		Appendix B. 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.
	B.1. Since draft-ietf-quic-tls-17		B.1. Since draft-ietf-quic-tls-18
			o Increased the set of permissible frames in 0-RTT (#2344, #2355)
			B.2. Since draft-ietf-quic-tls-17
	o Endpoints discard initial keys as soon as handshake keys are		o Endpoints discard initial keys as soon as handshake keys are
	available (#1951, #2045)		available (#1951, #2045)
	o Use of ALPN or equivalent is mandatory (#2263, #2284)		o Use of ALPN or equivalent is mandatory (#2263, #2284)
	B.2. Since draft-ietf-quic-tls-14		B.3. Since draft-ietf-quic-tls-14
	o Update the salt used for Initial secrets (#1970)		o Update the salt used for Initial secrets (#1970)
	o Clarify that TLS_AES_128_CCM_8_SHA256 isn't supported (#2019)		o Clarify that TLS_AES_128_CCM_8_SHA256 isn't supported (#2019)
	o Change header protection		o Change header protection
	* Sample from a fixed offset (#1575, #2030)		* Sample from a fixed offset (#1575, #2030)
	* Cover part of the first byte, including the key phase (#1322,		* Cover part of the first byte, including the key phase (#1322,
	#2006)		#2006)
	o TLS provides an AEAD and KDF function (#2046)		o TLS provides an AEAD and KDF function (#2046)
	* Clarify that the TLS KDF is used with TLS (#1997)		* Clarify that the TLS KDF is used with TLS (#1997)
	* Change the labels for calculation of QUIC keys (#1845, #1971,		* Change the labels for calculation of QUIC keys (#1845, #1971,
	#1991)		#1991)
	o Initial keys are discarded once Handshake are avaialble (#1951,		o Initial keys are discarded once Handshake are avaialble (#1951,
	#2045)		#2045)
	B.3. Since draft-ietf-quic-tls-13		B.4. Since draft-ietf-quic-tls-13
	o Updated to TLS 1.3 final (#1660)		o Updated to TLS 1.3 final (#1660)
	B.4. Since draft-ietf-quic-tls-12		B.5. Since draft-ietf-quic-tls-12
	o Changes to integration of the TLS handshake (#829, #1018, #1094,		o Changes to integration of the TLS handshake (#829, #1018, #1094,
	#1165, #1190, #1233, #1242, #1252, #1450)		#1165, #1190, #1233, #1242, #1252, #1450)
	* The cryptographic handshake uses CRYPTO frames, not stream 0		* The cryptographic handshake uses CRYPTO frames, not stream 0
	* QUIC packet protection is used in place of TLS record		* QUIC packet protection is used in place of TLS record
	protection		protection
	* Separate QUIC packet number spaces are used for the handshake		* Separate QUIC packet number spaces are used for the handshake
	* Changed Retry to be independent of the cryptographic handshake		* Changed Retry to be independent of the cryptographic handshake
	* Limit the use of HelloRetryRequest to address TLS needs (like		* Limit the use of HelloRetryRequest to address TLS needs (like
	key shares)		key shares)
	o Changed codepoint of TLS extension (#1395, #1402)		o Changed codepoint of TLS extension (#1395, #1402)
	B.5. Since draft-ietf-quic-tls-11		B.6. Since draft-ietf-quic-tls-11
	o Encrypted packet numbers.		o Encrypted packet numbers.
	B.6. Since draft-ietf-quic-tls-10		B.7. Since draft-ietf-quic-tls-10
	o No significant changes.		o No significant changes.
	B.7. Since draft-ietf-quic-tls-09		B.8. Since draft-ietf-quic-tls-09
	o Cleaned up key schedule and updated the salt used for handshake		o Cleaned up key schedule and updated the salt used for handshake
	packet protection (#1077)		packet protection (#1077)
	B.8. Since draft-ietf-quic-tls-08		B.9. Since draft-ietf-quic-tls-08
	o Specify value for max_early_data_size to enable 0-RTT (#942)		o Specify value for max_early_data_size to enable 0-RTT (#942)
	o Update key derivation function (#1003, #1004)		o Update key derivation function (#1003, #1004)
	B.9. Since draft-ietf-quic-tls-07		B.10. Since draft-ietf-quic-tls-07
	o Handshake errors can be reported with CONNECTION_CLOSE (#608,		o Handshake errors can be reported with CONNECTION_CLOSE (#608,
	#891)		#891)
	B.10. Since draft-ietf-quic-tls-05		B.11. Since draft-ietf-quic-tls-05
	No significant changes.		No significant changes.
	B.11. Since draft-ietf-quic-tls-04		B.12. Since draft-ietf-quic-tls-04
	o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)		o Update labels used in HKDF-Expand-Label to match TLS 1.3 (#642)
	B.12. Since draft-ietf-quic-tls-03		B.13. Since draft-ietf-quic-tls-03
	No significant changes.		No significant changes.
	B.13. Since draft-ietf-quic-tls-02		B.14. Since draft-ietf-quic-tls-02
	o Updates to match changes in transport draft		o Updates to match changes in transport draft
	B.14. Since draft-ietf-quic-tls-01		B.15. 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 40, line 47 ¶		skipping to change at page 42, line 4 ¶
	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)
	o Add interface necessary for client address validation (#275)		o Add interface necessary for client address validation (#275)
	o Define peer authentication (#140)		o Define peer authentication (#140)
	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)
	B.15. Since draft-ietf-quic-tls-00		B.16. 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
	B.16. Since draft-thomson-quic-tls-01		B.17. 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
	Acknowledgments		Acknowledgments
	This document has benefited from input from Dragana Damjanovic,		This document has benefited from input from Dragana Damjanovic,
End of changes. 46 change blocks.
	95 lines changed or deleted		147 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/