< draft-ietf-quic-tls-19.txt		draft-ietf-quic-tls-20.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: September 12, 2019 sn3rd		Expires: October 25, 2019 sn3rd
	March 11, 2019		April 23, 2019
	Using TLS to Secure QUIC		Using TLS to Secure QUIC
	draft-ietf-quic-tls-19		draft-ietf-quic-tls-20
	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 September 12, 2019.		This Internet-Draft will expire on October 25, 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. Replay Attacks with 0-RTT . . . . . . . . . . . . . . . . 29		9.1. Replay Attacks with 0-RTT . . . . . . . . . . . . . . . . 30
	9.2. Packet Reflection Attack Mitigation . . . . . . . . . . . 30		9.2. Packet Reflection Attack Mitigation . . . . . . . . . . . 31
	9.3. Peer Denial of Service . . . . . . . . . . . . . . . . . 31		9.3. Peer Denial of Service . . . . . . . . . . . . . . . . . 31
	9.4. Header Protection Analysis . . . . . . . . . . . . . . . 31		9.4. Header Protection Analysis . . . . . . . . . . . . . . . 31
	9.5. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 32		9.5. Key Diversity . . . . . . . . . . . . . . . . . . . . . . 32
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
	11.1. Normative References . . . . . . . . . . . . . . . . . . 33		11.1. Normative References . . . . . . . . . . . . . . . . . . 33
	11.2. Informative References . . . . . . . . . . . . . . . . . 34		11.2. Informative References . . . . . . . . . . . . . . . . . 34
	11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35		11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35
	Appendix A. Sample Initial Packet Protection . . . . . . . . . . 35		Appendix A. Sample Initial Packet Protection . . . . . . . . . . 35
	A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 35		A.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 35
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 5 ¶
	Note that it is not possible to send the following frames in 0-RTT		Note that it is not possible to send the following frames in 0-RTT
	for various reasons: ACK, CRYPTO, NEW_TOKEN, PATH_RESPONSE, and		for various reasons: ACK, CRYPTO, NEW_TOKEN, PATH_RESPONSE, and
	RETIRE_CONNECTION_ID.		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 |
	+-----------------+------------------+-----------+		+---------------------+------------------+-----------+
	| Initial | Initial secrets | Initial |		| Initial | Initial secrets | Initial |
	| | | |		| | | |
	| 0-RTT Protected | 0-RTT | 0/1-RTT |		| 0-RTT Protected | 0-RTT | 0/1-RTT |
	| | | |		| | | |
	| Handshake | Handshake | Handshake |		| Handshake | Handshake | Handshake |
	| | | |		| | | |
	| Retry | N/A | N/A |		| Retry | N/A | N/A |
	| | | |		| | | |
	| Short Header | 1-RTT | 0/1-RTT |		| Version Negotiation | N/A | N/A |
	+-----------------+------------------+-----------+		| | | |
			| Short Header | 1-RTT | 0/1-RTT |
			+---------------------+------------------+-----------+
	Table 1: Encryption Levels by Packet Type		Table 1: Encryption Levels by Packet Type
	Section 17 of [QUIC-TRANSPORT] shows how packets at the various		Section 17 of [QUIC-TRANSPORT] shows how packets at the various
	encryption levels fit into the handshake process.		encryption levels fit into the handshake process.
	4.1. Interface to TLS		4.1. Interface to TLS
	As shown in Figure 2, the interface from QUIC to TLS consists of		As shown in Figure 2, the interface from QUIC to TLS consists of
	three primary functions:		three primary functions:
	skipping to change at page 11, line 17 ¶		skipping to change at page 11, line 17 ¶
	When the handshake is complete, QUIC only needs to provide TLS with		When the handshake is complete, QUIC only needs to provide TLS with
	any data that arrives in CRYPTO streams. In the same way that is		any data that arrives in CRYPTO streams. In the same way that is
	done during the handshake, new data is requested from TLS after		done during the handshake, new data is requested from TLS after
	providing received data.		providing received data.
	Important: Until the handshake is reported as complete, the		Important: Until the handshake is reported as complete, the
	connection and key exchange are not properly authenticated at the		connection and key exchange are not properly authenticated at the
	server. Even though 1-RTT keys are available to a server after		server. Even though 1-RTT keys are available to a server after
	receiving the first handshake messages from a client, the server		receiving the first handshake messages from a client, the server
	cannot consider the client to be authenticated until it receives		cannot consider the client to be authenticated until it receives
	and validates the client's Finished message.		and validates the client's Finished message. A server MUST NOT
			process 1-RTT packets until the handshake is complete. A server
			MAY buffer or discard 1-RTT packets that it cannot read.
	The requirement for the server to wait for the client Finished		The requirement for the server to wait for the client Finished
	message creates a dependency on that message being delivered. A		message creates a dependency on that message being delivered. A
	client can avoid the potential for head-of-line blocking that this		client can avoid the potential for head-of-line blocking that this
	implies by sending a copy of the CRYPTO frame that carries the		implies by sending a copy of the CRYPTO frame that carries the
	Finished message in multiple packets. This enables immediate		Finished message in multiple packets. This enables immediate
	server processing for those packets.		server processing for those packets.
	4.1.2. Encryption Level Changes		4.1.2. Encryption Level Changes
	skipping to change at page 13, line 9 ¶		skipping to change at page 13, line 9 ¶
	4.1.3. TLS Interface Summary		4.1.3. TLS Interface Summary
	Figure 3 summarizes the exchange between QUIC and TLS for both client		Figure 3 summarizes the exchange between QUIC and TLS for both client
	and server. Each arrow is tagged with the encryption level used for		and server. Each arrow is tagged with the encryption level used for
	that transmission.		that transmission.
	Client Server		Client Server
	Get Handshake		Get Handshake
	Initial ------------->		Initial ------------->
	Rekey tx to 0-RTT Keys		Install tx 0-RTT Keys
	0-RTT --------------->		0-RTT --------------->
	Handshake Received		Handshake Received
	Get Handshake		Get Handshake
	<------------- Initial		<------------- Initial
	Rekey rx to 0-RTT keys		Install rx 0-RTT keys
	Handshake Received		Install Handshake keys
	Rekey rx to Handshake keys
	Get Handshake		Get Handshake
	<----------- Handshake		<----------- Handshake
	Rekey tx to 1-RTT keys		Install tx 1-RTT keys
	<--------------- 1-RTT		<--------------- 1-RTT
	Handshake Received		Handshake Received
	Rekey rx to Handshake keys		Install tx Handshake keys
	Handshake Received		Handshake Received
	Get Handshake		Get Handshake
	Handshake Complete		Handshake Complete
	Handshake ----------->		Handshake ----------->
	Rekey tx to 1-RTT keys		Install 1-RTT keys
	1-RTT --------------->		1-RTT --------------->
	Handshake Received		Handshake Received
	Rekey rx to 1-RTT keys		Install rx 1-RTT keys
	Get Handshake
	Handshake Complete		Handshake Complete
			Get Handshake
	<--------------- 1-RTT		<--------------- 1-RTT
	Handshake Received		Handshake Received
	Figure 3: Interaction Summary between QUIC and TLS		Figure 3: Interaction Summary between QUIC and TLS
	4.2. TLS Version		4.2. TLS Version
	This document describes how TLS 1.3 [TLS13] is used with QUIC.		This document describes how TLS 1.3 [TLS13] is used with QUIC.
	In practice, the TLS handshake will negotiate a version of TLS to		In practice, the TLS handshake will negotiate a version of TLS to
	skipping to change at page 28, line 31 ¶		skipping to change at page 28, line 31 ¶
	version information is copied into the TLS handshake, which provides		version information is copied into the TLS handshake, which provides
	integrity protection for the QUIC negotiation. This does not prevent		integrity protection for the QUIC negotiation. This does not prevent
	version downgrade prior to the completion of the handshake, though it		version downgrade prior to the completion of the handshake, though it
	means that a downgrade causes a handshake failure.		means that a downgrade causes a handshake failure.
	QUIC requires that the cryptographic handshake provide authenticated		QUIC requires that the cryptographic handshake provide authenticated
	protocol negotiation. TLS uses Application Layer Protocol		protocol negotiation. TLS uses Application Layer Protocol
	Negotiation (ALPN) [RFC7301] to select an application protocol.		Negotiation (ALPN) [RFC7301] to select an application protocol.
	Unless another mechanism is used for agreeing on an application		Unless another mechanism is used for agreeing on an application
	protocol, endpoints MUST use ALPN for this purpose. When using ALPN,		protocol, endpoints MUST use ALPN for this purpose. When using ALPN,
	endpoints MUST abort a connection if an application protocol is not		endpoints MUST immediately close a connection (see Section 10.3 in
	negotiated.		[QUIC-TRANSPORT]) if an application protocol is not negotiated with a
			no_application_protocol TLS alert (QUIC error code 0x178, see
			Section 4.8). While [RFC7301] only specifies that servers use this
			alert, QUIC clients MUST also use it to terminate a connection when
			ALPN negotiation fails.
	An application-layer protocol MAY restrict the QUIC versions that it		An application-layer protocol MAY restrict the QUIC versions that it
	can operate over. Servers MUST select an application protocol		can operate over. Servers MUST select an application protocol
	compatible with the QUIC version that the client has selected. If		compatible with the QUIC version that the client has selected. If
	the server cannot select a compatible combination of application		the server cannot select a compatible combination of application
	protocol and QUIC version, it MUST abort the connection. A client		protocol and QUIC version, it MUST abort the connection. A client
	MUST abort a connection if the server picks an incompatible		MUST abort a connection if the server picks an incompatible
	combination of QUIC version and ALPN identifier.		combination of QUIC version and ALPN identifier.
	8.2. QUIC Transport Parameters Extension		8.2. QUIC Transport Parameters Extension
	skipping to change at page 29, line 22 ¶		skipping to change at page 29, line 26 ¶
	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.
	Endpoints MUST NOT send this extension in a TLS connection that does		Endpoints MUST NOT send this extension in a TLS connection that does
	not use QUIC (such as the use of TLS with TCP defined in [TLS13]). A		not use QUIC (such as the use of TLS with TCP defined in [TLS13]). A
	fatal unsupported_extension alert MUST be sent if this extension is		fatal unsupported_extension alert MUST be sent by an implementation
	received when the transport is not QUIC.		that supports this extension if the extension is received when the
			transport is not QUIC.
	8.3. Removing the EndOfEarlyData Message		8.3. Removing the EndOfEarlyData Message
	The TLS EndOfEarlyData message is not used with QUIC. QUIC does not		The TLS EndOfEarlyData message is not used with QUIC. QUIC does not
	rely on this message to mark the end of 0-RTT data or to signal the		rely on this message to mark the end of 0-RTT data or to signal the
	change to Handshake keys.		change to Handshake keys.
	Clients MUST NOT send the EndOfEarlyData message. A server MUST		Clients MUST NOT send the EndOfEarlyData message. A server MUST
	treat receipt of a CRYPTO frame in a 0-RTT packet as a connection		treat receipt of a CRYPTO frame in a 0-RTT packet as a connection
	error of type PROTOCOL_VIOLATION.		error of type PROTOCOL_VIOLATION.
	skipping to change at page 33, line 37 ¶		skipping to change at page 33, line 43 ¶
	[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-19 (work		and Congestion Control", draft-ietf-quic-recovery-20 (work
	in progress), March 2019.		in progress), April 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-19 (work in progress), March 2019.		transport-20 (work in progress), April 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 34, line 45 ¶		skipping to change at page 34, line 50 ¶
	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-19 (work in progress), March		QUIC", draft-ietf-quic-http-20 (work in progress), April
	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 39, line 35 ¶		skipping to change at page 39, line 35 ¶
	*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-18		B.1. Since draft-ietf-quic-tls-18
	o Increased the set of permissible frames in 0-RTT (#2344, #2355)		o Increased the set of permissible frames in 0-RTT (#2344, #2355)
			o Transport parameter extension is mandatory (#2528, #2560)
	B.2. Since draft-ietf-quic-tls-17		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.3. 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)
End of changes. 19 change blocks.
	37 lines changed or deleted		47 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/