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: October 15, 2021 sn3rd
	January 15, 2021		April 13, 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 October 15, 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 16, line 29 ¶		skipping to change at page 16, line 29 ¶
	configured TLS implementation could negotiate TLS 1.2 or another		configured TLS implementation could negotiate TLS 1.2 or another
	older version of TLS. An endpoint MUST terminate the connection if a		older version of TLS. An endpoint MUST terminate the connection if a
	version of TLS older than 1.3 is negotiated.		version of TLS older than 1.3 is negotiated.
	4.3. ClientHello Size		4.3. ClientHello Size
	The first Initial packet from a client contains the start or all of		The first Initial packet from a client contains the start or all of
	its first cryptographic handshake message, which for TLS is the		its first cryptographic handshake message, which for TLS is the
	ClientHello. Servers might need to parse the entire ClientHello		ClientHello. Servers might need to parse the entire ClientHello
	(e.g., to access extensions such as Server Name Identification (SNI)		(e.g., to access extensions such as Server Name Identification (SNI)
	or Application Layer Protocol Negotiation (ALPN)) in order to decide		or Application-Layer Protocol Negotiation (ALPN)) in order to decide
	whether to accept the new incoming QUIC connection. If the		whether to accept the new incoming QUIC connection. If the
	ClientHello spans multiple Initial packets, such servers would need		ClientHello spans multiple Initial packets, such servers would need
	to buffer the first received fragments, which could consume excessive		to buffer the first received fragments, which could consume excessive
	resources if the client's address has not yet been validated. To		resources if the client's address has not yet been validated. To
	avoid this, servers MAY use the Retry feature (see Section 8.1 of		avoid this, servers MAY use the Retry feature (see Section 8.1 of
	[QUIC-TRANSPORT]) to only buffer partial ClientHello messages from		[QUIC-TRANSPORT]) to only buffer partial ClientHello messages from
	clients with a validated address.		clients with a validated address.
	QUIC packet and framing add at least 36 bytes of overhead to the		QUIC packet and framing add at least 36 bytes of overhead to the
	ClientHello message. That overhead increases if the client chooses a		ClientHello message. That overhead increases if the client chooses a
	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 21, line 6 ¶		skipping to change at page 21, line 6 ¶
	packets. Although it is in principle possible to use this feature		packets. Although it is in principle possible to use this feature
	for address verification, QUIC implementations SHOULD instead use the		for address verification, QUIC implementations SHOULD instead use the
	Retry feature; see Section 8.1 of [QUIC-TRANSPORT].		Retry feature; see Section 8.1 of [QUIC-TRANSPORT].
	4.8. TLS Errors		4.8. 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 converted into a QUIC connection error. The		A TLS alert is converted into a QUIC connection error. The
	AlertDescription value is added to 0x100 to produce a QUIC error code		AlertDescription value is added to 0x0100 to produce a QUIC error
	from the range reserved for CRYPTO_ERROR. The resulting value is		code from the range reserved for CRYPTO_ERROR. The resulting value
	sent in a QUIC CONNECTION_CLOSE frame of type 0x1c.		is sent in a QUIC CONNECTION_CLOSE frame of type 0x1c.
	QUIC is only able to convey an alert level of "fatal". In TLS 1.3,		QUIC is only able to convey an alert level of "fatal". In TLS 1.3,
	the only existing uses for the "warning" level are to signal		the only existing uses for the "warning" level are to signal
	connection close; see Section 6.1 of [TLS13]. As QUIC provides		connection close; see Section 6.1 of [TLS13]. As QUIC provides
	alternative mechanisms for connection termination and the TLS		alternative mechanisms for connection termination and the TLS
	connection is only closed if an error is encountered, a QUIC endpoint		connection is only closed if an error is encountered, a QUIC endpoint
	MUST treat any alert from TLS as if it were at the "fatal" level.		MUST treat any alert from TLS as if it were at the "fatal" level.
	QUIC permits the use of a generic code in place of a specific error		QUIC permits the use of a generic code in place of a specific error
	code; see Section 11 of [QUIC-TRANSPORT]. For TLS alerts, this		code; see Section 11 of [QUIC-TRANSPORT]. For TLS alerts, this
	includes replacing any alert with a generic alert, such as		includes replacing any alert with a generic alert, such as
	handshake_failure (0x128 in QUIC). Endpoints MAY use a generic error		handshake_failure (0x0128 in QUIC). Endpoints MAY use a generic
	code to avoid possibly exposing confidential information.		error code to avoid possibly exposing confidential information.
	4.9. Discarding Unused Keys		4.9. Discarding Unused Keys
	After QUIC has completed a move to a new encryption level, packet		After QUIC has completed a move to a new encryption level, packet
	protection keys for previous encryption levels can be discarded.		protection keys for previous encryption levels can be discarded.
	This occurs several times during the handshake, as well as when keys		This occurs several times during the handshake, as well as when keys
	are updated; see Section 6.		are updated; see Section 6.
	Packet protection keys are not discarded immediately when new keys		Packet protection keys are not discarded immediately when new keys
	are available. If packets from a lower encryption level contain		are available. If packets from a lower encryption level contain
	skipping to change at page 36, line 19 ¶		skipping to change at page 36, line 19 ¶
	the change. An endpoint that notices a changed Key Phase bit updates		the change. An endpoint that notices a changed Key Phase bit updates
	keys and decrypts the packet that contains the changed value.		keys and decrypts the packet that contains the changed value.
	Initiating a key update results in both endpoints updating keys.		Initiating a key update results in both endpoints updating keys.
	This differs from TLS where endpoints can update keys independently.		This differs from TLS where endpoints can update keys independently.
	This mechanism replaces the key update mechanism of TLS, which relies		This mechanism replaces the key update mechanism of TLS, which relies
	on KeyUpdate messages sent using 1-RTT encryption keys. Endpoints		on KeyUpdate messages sent using 1-RTT encryption keys. Endpoints
	MUST NOT send a TLS KeyUpdate message. Endpoints MUST treat the		MUST NOT send a TLS KeyUpdate message. Endpoints MUST treat the
	receipt of a TLS KeyUpdate message as a connection error of type		receipt of a TLS KeyUpdate message as a connection error of type
	0x10a, equivalent to a fatal TLS alert of unexpected_message; see		0x010a, equivalent to a fatal TLS alert of unexpected_message; see
	Section 4.8.		Section 4.8.
	Figure 9 shows a key update process, where the initial set of keys		Figure 9 shows a key update process, where the initial set of keys
	used (identified with @M) are replaced by updated keys (identified		used (identified with @M) are replaced by updated keys (identified
	with @N). The value of the Key Phase bit is indicated in brackets		with @N). The value of the Key Phase bit is indicated in brackets
	[].		[].
	Initiating Peer Responding Peer		Initiating Peer Responding Peer
	@M [0] QUIC Packets		@M [0] QUIC Packets
	skipping to change at page 42, line 22 ¶		skipping to change at page 42, line 22 ¶
	limits on the use of the associated AEAD function that preserves		limits on the use of the associated AEAD function that preserves
	margins for confidentiality and integrity. That is, limits MUST be		margins for confidentiality and integrity. That is, limits MUST be
	specified for the number of packets that can be authenticated and for		specified for the number of packets that can be authenticated and for
	the number of packets that can fail authentication. Providing a		the number of packets that can fail authentication. Providing a
	reference to any analysis upon which values are based - and any		reference to any analysis upon which values are based - and any
	assumptions used in that analysis - allows limits to be adapted to		assumptions used in that analysis - allows limits to be adapted to
	varying usage conditions.		varying usage conditions.
	6.7. Key Update Error Code		6.7. Key Update Error Code
	The KEY_UPDATE_ERROR error code (0xe) is used to signal errors		The KEY_UPDATE_ERROR error code (0x0e) 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 43, line 19 ¶		skipping to change at page 43, line 19 ¶
	8.1. Protocol Negotiation		8.1. Protocol Negotiation
	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]) to select an application protocol. Unless		Negotiation ([ALPN]) to select an application protocol. Unless
	another mechanism is used for agreeing on an application protocol,		another mechanism is used for agreeing on an application protocol,
	endpoints MUST use ALPN for this purpose.		endpoints MUST use ALPN for this purpose.
	When using ALPN, endpoints MUST immediately close a connection (see		When using ALPN, endpoints MUST immediately close a connection (see
	Section 10.2 of [QUIC-TRANSPORT]) with a no_application_protocol TLS		Section 10.2 of [QUIC-TRANSPORT]) with a no_application_protocol TLS
	alert (QUIC error code 0x178; see Section 4.8) if an application		alert (QUIC error code 0x0178; see Section 4.8) if an application
	protocol is not negotiated. While [ALPN] only specifies that servers		protocol is not negotiated. While [ALPN] only specifies that servers
	use this alert, QUIC clients MUST use error 0x178 to terminate a		use this alert, QUIC clients MUST use error 0x0178 to terminate a
	connection when ALPN negotiation fails.		connection when ALPN negotiation fails.
	An application protocol MAY restrict the QUIC versions that it can		An application protocol MAY restrict the QUIC versions that it can
	operate over. Servers MUST select an application protocol compatible		operate over. Servers MUST select an application protocol compatible
	with the QUIC version that the client has selected. The server MUST		with the QUIC version that the client has selected. The server MUST
	treat the inability to select a compatible application protocol as a		treat the inability to select a compatible application protocol as a
	connection error of type 0x178 (no_application_protocol). Similarly,		connection error of type 0x0178 (no_application_protocol).
	a client MUST treat the selection of an incompatible application		Similarly, a client MUST treat the selection of an incompatible
	protocol by a server as a connection error of type 0x178.		application protocol by a server as a connection error of type
			0x0178.
	8.2. QUIC Transport Parameters Extension		8.2. QUIC Transport Parameters Extension
	QUIC transport parameters are carried in a TLS extension. Different		QUIC transport parameters are carried in a TLS extension. Different
	versions of QUIC might define a different method for negotiating		versions of QUIC might define a different method for negotiating
	transport configuration.		transport configuration.
	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.
	skipping to change at page 44, line 5 ¶		skipping to change at page 44, line 6 ¶
	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.		use.
	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. Endpoints		and the EncryptedExtensions messages during the handshake. Endpoints
	MUST send the quic_transport_parameters extension; endpoints that		MUST send the quic_transport_parameters extension; endpoints that
	receive ClientHello or EncryptedExtensions messages without the		receive ClientHello or EncryptedExtensions messages without the
	quic_transport_parameters extension MUST close the connection with an		quic_transport_parameters extension MUST close the connection with an
	error of type 0x16d (equivalent to a fatal TLS missing_extension		error of type 0x016d (equivalent to a fatal TLS missing_extension
	alert, see Section 4.8).		alert, see Section 4.8).
	Transport parameters become available prior to the completion of the		Transport parameters become available prior to the completion of the
	handshake. A server might use these values earlier than handshake		handshake. A server might use these values earlier than handshake
	completion. However, the value of transport parameters is not		completion. However, the value of transport parameters is not
	authenticated until the handshake completes, so any use of these		authenticated until the handshake completes, so any use of these
	parameters cannot depend on their authenticity. Any tampering with		parameters cannot depend on their authenticity. Any tampering with
	transport parameters will cause the handshake to fail.		transport parameters will cause the handshake 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
	skipping to change at page 46, line 48 ¶		skipping to change at page 47, line 4 ¶
	[NAN] analyzes authenticated encryption algorithms that provide nonce		[NAN] analyzes authenticated encryption algorithms that provide nonce
	privacy, referred to as "Hide Nonce" (HN) transforms. The general		privacy, referred to as "Hide Nonce" (HN) transforms. The general
	header protection construction in this document is one of those		header protection construction in this document is one of those
	algorithms (HN1). Header protection is applied after the packet		algorithms (HN1). Header protection is applied after the packet
	protection AEAD, sampling a set of bytes ("sample") from the AEAD		protection AEAD, sampling a set of bytes ("sample") from the AEAD
	output and encrypting the header field using a pseudorandom function		output and encrypting the header field using a pseudorandom function
	(PRF) as follows:		(PRF) as follows:
	protected_field = field XOR PRF(hp_key, sample)		protected_field = field XOR PRF(hp_key, sample)
	The header protection variants in this document use a pseudorandom		The header protection variants in this document use a pseudorandom
	permutation (PRP) in place of a generic PRF. However, since all PRPs		permutation (PRP) in place of a generic PRF. However, since all PRPs
	are also PRFs [IMC], these variants do not deviate from the HN1		are also PRFs [IMC], these variants do not deviate from the HN1
	construction.		construction.
	As "hp_key" is distinct from the packet protection key, it follows		As "hp_key" is distinct from the packet protection key, it follows
	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. 20 change blocks.
	33 lines changed or deleted		33 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/