draft-ietf-quic-tls-27.txt		draft-ietf-quic-tls-latest.txt
	QUIC Working Group M. Thomson, Ed.		QUIC Working Group M. Thomson, Ed.
	Internet-Draft Mozilla		Internet-Draft Mozilla
	Intended status: Standards Track S. Turner, Ed.		Intended status: Standards Track S. Turner, Ed.
	Expires: August 24, 2020 sn3rd		Expires: October 3, 2020 sn3rd
	February 21, 2020		April 1, 2020
	Using TLS to Secure QUIC		Using TLS to Secure QUIC
	draft-ietf-quic-tls-27		draft-ietf-quic-tls-latest
	Abstract		Abstract
	This document describes how Transport Layer Security (TLS) is used to		This document describes how Transport Layer Security (TLS) is used to
	secure QUIC.		secure QUIC.
	Note to Readers		Note to Readers
	Discussion of this draft takes place on the QUIC working group		Discussion of this draft takes place on the QUIC working group
	mailing list (quic@ietf.org), which is archived at		mailing list (quic@ietf.org), which is archived at
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 24, 2020.		This Internet-Draft will expire on October 3, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 8, line 43 ¶		skipping to change at page 8, line 43 ¶
	offset and length. Those frames are packaged into QUIC packets and		offset and length. Those frames are packaged into QUIC packets and
	encrypted under the current TLS encryption level. As with TLS over		encrypted under the current TLS encryption level. As with TLS over
	TCP, once TLS handshake data has been delivered to QUIC, it is QUIC's		TCP, once TLS handshake data has been delivered to QUIC, it is QUIC's
	responsibility to deliver it reliably. Each chunk of data that is		responsibility to deliver it reliably. Each chunk of data that is
	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 packet
	level. For instance, an implementation might bundle a Handshake		number space. For instance, an endpoint can 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.
	Some frames are prohibited in different encryption levels, others		Some frames are prohibited in different packet number spaces. The
	cannot be sent. The rules here generalize those of TLS, in that		rules here generalize those of TLS, in that frames associated with
	frames associated with establishing the connection can usually appear		establishing the connection can usually appear in packets in any
	at any encryption level, whereas those associated with transferring		packet number space, whereas those associated with transferring data
	data can only appear in the 0-RTT and 1-RTT encryption levels:		can only appear in the application data packet number space:
	o PADDING and PING frames MAY appear in packets of any encryption
	level.
	o CRYPTO frames and CONNECTION_CLOSE frames signaling errors at the		o PADDING, PING, and CRYPTO frames MAY appear in any packet number
	QUIC layer (type 0x1c) MAY appear in packets of any encryption		space.
	level except 0-RTT.
	o CONNECTION_CLOSE frames signaling application errors (type 0x1d)		o CONNECTION_CLOSE frames signaling errors at the QUIC layer (type
	MUST only be sent in packets at the 1-RTT encryption level.		0x1c) MAY appear in any packet number space. CONNECTION_CLOSE
			frames signaling application errors (type 0x1d) MUST only appear
			in the application data packet number space.
	o ACK frames MAY appear in packets of any encryption level other		o ACK frames MAY appear in any packet number space, but can only
	than 0-RTT, but can only acknowledge packets which appeared in		acknowledge packets which appeared in that packet number space.
	that packet number space.		However, as noted below, 0-RTT packets cannot contain ACK frames.
	o All other frame types MUST only be sent in the 0-RTT and 1-RTT		o All other frame types MUST only be sent in the application data
	levels.		packet number space.
	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, HANDSHAKE_DONE, NEW_TOKEN,		packets for various reasons: ACK, CRYPTO, HANDSHAKE_DONE, NEW_TOKEN,
	PATH_RESPONSE, and RETIRE_CONNECTION_ID.		PATH_RESPONSE, and RETIRE_CONNECTION_ID. A server MAY treat receipt
			of these frames in 0-RTT packets as a connection error of type
			PROTOCOL_VIOLATION.
	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 keys were used to protect a given packet, as
	shown in Table 1. When multiple packets of different encryption		shown in Table 1. When packets of different types need to be sent,
	levels need to be sent, endpoints SHOULD use coalesced packets to		endpoints SHOULD use coalesced packets to send them in the same UDP
	send them in the same UDP datagram.		datagram.
	+---------------------+------------------+-----------+		+---------------------+-----------------+------------------+
	| Packet Type | Encryption Level | PN Space |		| Packet Type | Encryption Keys | PN Space |
	+---------------------+------------------+-----------+		+---------------------+-----------------+------------------+
	| Initial | Initial secrets | Initial |		| Initial | Initial secrets | Initial |
	| | | |		| | | |
	| 0-RTT Protected | 0-RTT | 0/1-RTT |		| 0-RTT Protected | 0-RTT | Application data |
	| | | |		| | | |
	| Handshake | Handshake | Handshake |		| Handshake | Handshake | Handshake |
	| | | |		| | | |
	| Retry | N/A | N/A |		| Retry | Retry | N/A |
	| | | |		| | | |
	| Version Negotiation | N/A | N/A |		| Version Negotiation | N/A | N/A |
	| | | |		| | | |
	| Short Header | 1-RTT | 0/1-RTT |		| Short Header | 1-RTT | Application data |
	+---------------------+------------------+-----------+		+---------------------+-----------------+------------------+
	Table 1: Encryption Levels by Packet Type		Table 1: Encryption Keys 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 4, the interface from QUIC to TLS consists of four		As shown in Figure 4, the interface from QUIC to TLS consists of four
	primary functions:		primary functions:
	o Sending and receiving handshake messages		o Sending and receiving handshake messages
	skipping to change at page 11, line 14 ¶		skipping to change at page 11, line 14 ¶
	Before starting the handshake QUIC provides TLS with the transport		Before starting the handshake QUIC provides TLS with the transport
	parameters (see Section 8.2) that it wishes to carry.		parameters (see Section 8.2) that it wishes to carry.
	A QUIC client starts TLS by requesting TLS handshake bytes from TLS.		A QUIC client starts TLS by requesting TLS handshake bytes from TLS.
	The client acquires handshake bytes before sending its first packet.		The client acquires handshake bytes before sending its first packet.
	A QUIC server starts the process by providing TLS with the client's		A QUIC server starts the process by providing TLS with the client's
	handshake bytes.		handshake bytes.
	At any time, the TLS stack at an endpoint will have a current sending		At any time, the TLS stack at an endpoint will have a current sending
	encryption level and receiving encryption level. Each encryption		encryption level and receiving encryption level. Encryption levels
	level is associated with a different flow of bytes, which is reliably		determine the packet type and keys that are used for protecting data.
	transmitted to the peer in CRYPTO frames. When TLS provides
	handshake bytes to be sent, they are appended to the current flow and		Each encryption level is associated with a different sequence of
	any packet that includes the CRYPTO frame is protected using keys		bytes, which is reliably transmitted to the peer in CRYPTO frames.
	from the corresponding encryption level.		When TLS provides handshake bytes to be sent, they are appended to
			the current flow. Any packet that includes the CRYPTO frame is
			protected using keys from the corresponding encryption level. Four
			encryption levels are used, producing keys for Initial, 0-RTT,
			Handshake, and 1-RTT packets. CRYPTO frames are carried in just
			three of these levels, omitting the 0-RTT level. These four levels
			correspond to three packet number spaces: Initial and Handshake
			encrypted packets use their own separate spaces; 0-RTT and 1-RTT
			packets use the application data packet number space.
	QUIC takes the unprotected content of TLS handshake records as the		QUIC takes the unprotected content of TLS handshake records as the
	content of CRYPTO frames. TLS record protection is not used by QUIC.		content of CRYPTO frames. TLS record protection is not used by QUIC.
	QUIC assembles CRYPTO frames into QUIC packets, which are protected		QUIC assembles CRYPTO frames into QUIC packets, which are protected
	using QUIC packet protection.		using QUIC packet protection.
	QUIC is only capable of conveying TLS handshake records in CRYPTO		QUIC is only capable of conveying TLS handshake records in CRYPTO
	frames. TLS alerts are turned into QUIC CONNECTION_CLOSE error		frames. TLS alerts are turned into QUIC CONNECTION_CLOSE error
	codes; see Section 4.9. TLS application data and other message types		codes; see Section 4.9. TLS application data and other message types
	cannot be carried by QUIC at any encryption level and is an error if		cannot be carried by QUIC at any encryption level and is an error if
	skipping to change at page 17, line 46 ¶		skipping to change at page 17, line 46 ¶
	the client is interpreted. Other applications using QUIC could have		the client is interpreted. Other applications using QUIC could have
	different requirements for determining whether to accept or reject		different requirements for determining whether to accept or reject
	early data.		early data.
	4.8. HelloRetryRequest		4.8. HelloRetryRequest
	In TLS over TCP, the HelloRetryRequest feature (see Section 4.1.4 of		In TLS over TCP, the HelloRetryRequest feature (see Section 4.1.4 of
	[TLS13]) can be used to correct a client's incorrect KeyShare		[TLS13]) can be used to correct a client's incorrect KeyShare
	extension as well as for a stateless round-trip check. From the		extension as well as for a stateless round-trip check. From the
	perspective of QUIC, this just looks like additional messages carried		perspective of QUIC, this just looks like additional messages carried
	in the Initial encryption level. Although it is in principle		in Initial packets. Although it is in principle possible to use this
	possible to use this feature for address verification in QUIC, QUIC		feature for address verification in QUIC, QUIC implementations SHOULD
	implementations SHOULD instead use the Retry feature (see Section 8.1		instead use the Retry feature (see Section 8.1 of [QUIC-TRANSPORT]).
	of [QUIC-TRANSPORT]). HelloRetryRequest is still used to request key		HelloRetryRequest is still used to request key shares.
	shares.
	4.9. TLS Errors		4.9. TLS Errors
	If TLS experiences an error, it generates an appropriate alert as		If TLS experiences an error, it generates an appropriate alert as
	defined in Section 6 of [TLS13].		defined in Section 6 of [TLS13].
	A TLS alert is turned into a QUIC connection error by converting the		A TLS alert is turned into a QUIC connection error by converting the
	one-byte alert description into a QUIC error code. The alert		one-byte alert description into a QUIC error code. The alert
	description is added to 0x100 to produce a QUIC error code from the		description is added to 0x100 to produce a QUIC error code from the
	range reserved for CRYPTO_ERROR. The resulting value is sent in a		range reserved for CRYPTO_ERROR. The resulting value is sent in a
	QUIC CONNECTION_CLOSE frame.		QUIC CONNECTION_CLOSE frame of type 0x1c.
	The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT		The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT
	generate alerts at the "warning" level.		generate alerts at the "warning" level.
	4.10. Discarding Unused Keys		4.10. Discarding Unused Keys
	After QUIC moves to a new encryption level, packet protection keys		After QUIC moves to a new encryption level, packet protection keys
	for previous encryption levels can be discarded. This occurs several		for previous encryption levels can be discarded. This occurs several
	times during the handshake, as well as when keys are updated; see		times during the handshake, as well as when keys are updated; see
	Section 6.		Section 6.
	skipping to change at page 42, line 11 ¶		skipping to change at page 42, line 11 ¶
	"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>.
	[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-27 (work		and Congestion Control", draft-ietf-quic-recovery-latest
	in progress).		(work in progress).
	[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-27 (work in progress).		transport-latest (work in progress).
	[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>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	skipping to change at page 42, line 49 ¶		skipping to change at page 42, line 49 ¶
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	11.2. Informative References		11.2. Informative References
	[AEBounds]		[AEBounds]
	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>.
	[HTTP2-TLS13]		[HTTP2-TLS13]
	Benjamin, D., "Using TLS 1.3 with HTTP/2", draft-ietf-		Benjamin, D., "Using TLS 1.3 with HTTP/2", RFC 8740,
	httpbis-http2-tls13-03 (work in progress), October 2019.		DOI 10.17487/RFC8740, February 2020,
			<https://www.rfc-editor.org/info/rfc8740>.
	[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.
	[NAN] Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed:		[NAN] Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed:
	AEAD Revisited", Advances in Cryptology - CRYPTO 2019 pp.		AEAD Revisited", Advances in Cryptology - CRYPTO 2019 pp.
	235-265, DOI 10.1007/978-3-030-26948-7_9, 2019.		235-265, DOI 10.1007/978-3-030-26948-7_9, 2019.
	[QUIC-HTTP]		[QUIC-HTTP]
	Bishop, M., Ed., "Hypertext Transfer Protocol Version 3		Bishop, M., Ed., "Hypertext Transfer Protocol Version 3
	(HTTP/3)", draft-ietf-quic-http-27 (work in progress).		(HTTP/3)", draft-ietf-quic-http-latest (work in progress).
	[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,
	<https://www.rfc-editor.org/info/rfc5280>.		<https://www.rfc-editor.org/info/rfc5280>.
End of changes. 20 change blocks.
	64 lines changed or deleted		72 lines changed or added
This html diff was produced by rfcdiff 1.44jr. The latest version is available from http://tools.ietf.org/tools/rfcdiff/