draft-ietf-quic-tls-34.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: July 19, 2021 sn3rd		Expires: September 3, 2021 sn3rd
	January 15, 2021		March 2, 2021
	Using TLS to Secure QUIC		Using TLS to Secure QUIC
	draft-ietf-quic-tls-34		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 July 19, 2021.		This Internet-Draft will expire on September 3, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 17, line 12 ¶		skipping to change at page 17, line 12 ¶
	parameters, and other negotiable parameters and extensions could		parameters, and other negotiable parameters and extensions could
	cause this message to grow.		cause this message to grow.
	For servers, in addition to connection IDs and tokens, the size of		For servers, in addition to connection IDs and tokens, the size of
	TLS session tickets can have an effect on a client's ability to		TLS session tickets can have an effect on a client's ability to
	connect efficiently. Minimizing the size of these values increases		connect efficiently. Minimizing the size of these values increases
	the probability that clients can use them and still fit their entire		the probability that clients can use them and still fit their entire
	ClientHello message in their first Initial packet.		ClientHello message in their first Initial packet.
	The TLS implementation does not need to ensure that the ClientHello		The TLS implementation does not need to ensure that the ClientHello
	is large enough to meet the requirements for QUIC packets. QUIC		is large enough to meet QUIC's requirements for datagrams that carry
	PADDING frames are added to increase the size of the packet as		Initial packets; see Section 14.1 of [QUIC-TRANSPORT]. QUIC
	necessary; see Section 14.1 of [QUIC-TRANSPORT].		implementations use PADDING frames or packet coalescing to ensure
			that datagrams are large enough.
	4.4. Peer Authentication		4.4. Peer Authentication
	The requirements for authentication depend on the application		The requirements for authentication depend on the application
	protocol that is in use. TLS provides server authentication and		protocol that is in use. TLS provides server authentication and
	permits the server to request client authentication.		permits the server to request client authentication.
	A client MUST authenticate the identity of the server. This		A client MUST authenticate the identity of the server. This
	typically involves verification that the identity of the server is		typically involves verification that the identity of the server is
	included in a certificate and that the certificate is issued by a		included in a certificate and that the certificate is issued by a
	skipping to change at page 42, line 31 ¶		skipping to change at page 42, line 31 ¶
	The KEY_UPDATE_ERROR error code (0xe) is used to signal errors		The KEY_UPDATE_ERROR error code (0xe) is used to signal errors
	related to key updates.		related to key updates.
	7. Security of Initial Messages		7. Security of Initial Messages
	Initial packets are not protected with a secret key, so they are		Initial packets are not protected with a secret key, so they are
	subject to potential tampering by an attacker. QUIC provides		subject to potential tampering by an attacker. QUIC provides
	protection against attackers that cannot read packets, but does not		protection against attackers that cannot read packets, but does not
	attempt to provide additional protection against attacks where the		attempt to provide additional protection against attacks where the
	attacker can observe and inject packets. Some forms of tampering -		attacker can observe and inject packets. Some forms of tampering --
	such as modifying the TLS messages themselves - are detectable, but		such as modifying the TLS messages themselves -- are detectable, but
	some - such as modifying ACKs - are not.		some -- such as modifying ACKs -- are not.
	For example, an attacker could inject a packet containing an ACK		For example, an attacker could inject a packet containing an ACK
	frame that makes it appear that a packet had not been received or to		frame that makes it appear that a packet had not been received or to
	create a false impression of the state of the connection (e.g., by		create a false impression of the state of the connection (e.g., by
	modifying the ACK Delay). Note that such a packet could cause a		modifying the ACK Delay). Note that such a packet could cause a
	legitimate packet to be dropped as a duplicate. Implementations		legitimate packet to be dropped as a duplicate. Implementations
	SHOULD use caution in relying on any data that is contained in		SHOULD use caution in relying on any data that is contained in
	Initial packets that is not otherwise authenticated.		Initial packets that is not otherwise authenticated.
	It is also possible for the attacker to tamper with data that is		It is also possible for the attacker to tamper with data that is
	skipping to change at page 47, line 18 ¶		skipping to change at page 47, line 18 ¶
	that header protection achieves AE2 security as defined in [NAN] and		that header protection achieves AE2 security as defined in [NAN] and
	therefore guarantees privacy of "field", the protected packet header.		therefore guarantees privacy of "field", the protected packet header.
	Future header protection variants based on this construction MUST use		Future header protection variants based on this construction MUST use
	a PRF to ensure equivalent security guarantees.		a PRF to ensure equivalent security guarantees.
	Use of the same key and ciphertext sample more than once risks		Use of the same key and ciphertext sample more than once risks
	compromising header protection. Protecting two different headers		compromising header protection. Protecting two different headers
	with the same key and ciphertext sample reveals the exclusive OR of		with the same key and ciphertext sample reveals the exclusive OR of
	the protected fields. Assuming that the AEAD acts as a PRF, if L		the protected fields. Assuming that the AEAD acts as a PRF, if L
	bits are sampled, the odds of two ciphertext samples being identical		bits are sampled, the odds of two ciphertext samples being identical
	approach 2^(-L/2), that is, the birthday bound. For the algorithms		approach 2^-L/2, that is, the birthday bound. For the algorithms
	described in this document, that probability is one in 2^64.		described in this document, that probability is one in 2^64.
	To prevent an attacker from modifying packet headers, the header is		To prevent an attacker from modifying packet headers, the header is
	transitively authenticated using packet protection; the entire packet		transitively authenticated using packet protection; the entire packet
	header is part of the authenticated additional data. Protected		header is part of the authenticated additional data. Protected
	fields that are falsified or modified can only be detected once the		fields that are falsified or modified can only be detected once the
	packet protection is removed.		packet protection is removed.
	9.5. Header Protection Timing Side-Channels		9.5. Header Protection Timing Side-Channels
	skipping to change at page 49, line 36 ¶		skipping to change at page 49, line 36 ¶
	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>.
	[HKDF] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand		[HKDF] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
	Key Derivation Function (HKDF)", RFC 5869,		Key Derivation Function (HKDF)", RFC 5869,
	DOI 10.17487/RFC5869, May 2010,		DOI 10.17487/RFC5869, May 2010,
	<https://www.rfc-editor.org/info/rfc5869>.		<https://www.rfc-editor.org/info/rfc5869>.
	[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-34 (work		and Congestion Control", draft-ietf-quic-recovery-latest
	in progress), January 2021.		(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-34 (work in progress), January 2021.		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>.
	[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,		[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
	"Randomness Requirements for Security", BCP 106, RFC 4086,		"Randomness Requirements for Security", BCP 106, RFC 4086,
	DOI 10.17487/RFC4086, June 2005,		DOI 10.17487/RFC4086, June 2005,
	<https://www.rfc-editor.org/info/rfc4086>.		<https://www.rfc-editor.org/info/rfc4086>.
	skipping to change at page 51, line 20 ¶		skipping to change at page 51, line 20 ¶
	[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-33 (work in progress),		(HTTP/3)", draft-ietf-quic-http-latest (work in progress).
	January 2021.
	[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>.
	skipping to change at page 57, line 51 ¶		skipping to change at page 57, line 51 ¶
	using the smaller packet size.		using the smaller packet size.
	For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the message length (l) is		For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the message length (l) is
	the length of the associated data in blocks plus the length of the		the length of the associated data in blocks plus the length of the
	plaintext in blocks.		plaintext in blocks.
	For AEAD_AES_128_CCM, the total number of block cipher operations is		For AEAD_AES_128_CCM, the total number of block cipher operations is
	the sum of: the length of the associated data in blocks, the length		the sum of: the length of the associated data in blocks, the length
	of the ciphertext in blocks, the length of the plaintext in blocks,		of the ciphertext in blocks, the length of the plaintext in blocks,
	plus 1. In this analysis, this is simplified to a value of twice the		plus 1. In this analysis, this is simplified to a value of twice the
	length of the packet in blocks (that is, "2l = 2^8" for packets that		length of the packet in blocks (that is, 2l = 2^8 for packets that
	are limited to 2^11 bytes, or "2l = 2^13" otherwise). This		are limited to 2^11 bytes, or 2l = 2^13 otherwise). This
	simplification is based on the packet containing all of the		simplification is based on the packet containing all of the
	associated data and ciphertext. This results in a 1 to 3 block		associated data and ciphertext. This results in a 1 to 3 block
	overestimation of the number of operations per packet.		overestimation of the number of operations per packet.
	B.1. Analysis of AEAD_AES_128_GCM and AEAD_AES_256_GCM Usage Limits		B.1. Analysis of AEAD_AES_128_GCM and AEAD_AES_256_GCM Usage Limits
	[GCM-MU] specify concrete bounds for AEAD_AES_128_GCM and		[GCM-MU] specify concrete bounds for AEAD_AES_128_GCM and
	AEAD_AES_256_GCM as used in TLS 1.3 and QUIC. This section documents		AEAD_AES_256_GCM as used in TLS 1.3 and QUIC. This section documents
	this analysis using several simplifying assumptions:		this analysis using several simplifying assumptions:
End of changes. 10 change blocks.
	18 lines changed or deleted		18 lines changed or added
This html diff was produced by rfcdiff 1.44jr. The latest version is available from http://tools.ietf.org/tools/rfcdiff/