draft-ietf-httpbis-http2-tls13-03.txt		draft-ietf-httpbis-http2-tls13-latest.txt
	HTTP Working Group D. Benjamin		HTTP Working Group D. Benjamin
	Internet-Draft Google LLC		Internet-Draft Google LLC
	Updates: 7540 (if approved) October 17, 2019		Updates: 7540 (if approved) October 26, 2022
	Intended status: Standards Track		Intended status: Standards Track
	Expires: April 19, 2020		Expires: April 29, 2023
	Using TLS 1.3 with HTTP/2		Using TLS 1.3 with HTTP/2
	draft-ietf-httpbis-http2-tls13-03		draft-ietf-httpbis-http2-tls13-latest
	Abstract		Abstract
	This document updates RFC 7540 by forbidding TLS 1.3 post-handshake		This document updates RFC 7540 by forbidding TLS 1.3 post-handshake
	authentication, as an analog to the existing TLS 1.2 renegotiation		authentication, as an analog to the existing TLS 1.2 renegotiation
	restriction.		restriction.
	Note to Readers		Note to Readers
	_RFC EDITOR: please remove this section before publication_		_RFC EDITOR: please remove this section before publication_
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	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 April 19, 2020.		This Internet-Draft will expire on April 29, 2023.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2022 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 36 ¶		skipping to change at page 2, line 36 ¶
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 4		5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
	7.1. Normative References . . . . . . . . . . . . . . . . . . 4		7.1. Normative References . . . . . . . . . . . . . . . . . . 4
	7.2. Informative References . . . . . . . . . . . . . . . . . 5		7.2. Informative References . . . . . . . . . . . . . . . . . 5
	7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 5		7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
	1. Introduction		1. Introduction
	TLS 1.2 [RFC5246] and earlier support renegotiation, a mechanism for		TLS 1.2 [RFC5246] and earlier versions of TLS support renegotiation,
	changing parameters and keys partway through a connection. This was		a mechanism for changing parameters and keys partway through a
	sometimes used to implement reactive client authentication in		connection. This was sometimes used to implement reactive client
	HTTP/1.1 [RFC7230], where the server decides whether to request a		authentication in HTTP/1.1 [RFC7230], where the server decides
	client certificate based on the HTTP request.		whether or not to request a client certificate based on the HTTP
			request.
	HTTP/2 [RFC7540] multiplexes multiple HTTP requests over a single		HTTP/2 [RFC7540] multiplexes multiple HTTP requests over a single
	connection, which is incompatible with the mechanism above. Clients		connection, which is incompatible with the mechanism above. Clients
	cannot correlate the certificate request with the HTTP request which		cannot correlate the certificate request with the HTTP request that
	triggered it. Thus, Section 9.2.1 of [RFC7540] forbids		triggered it. Thus, Section 9.2.1 of [RFC7540] forbids
	renegotiation.		renegotiation.
	TLS 1.3 [RFC8446] updates TLS 1.2 to remove renegotiation in favor of		TLS 1.3 [RFC8446] removes renegotiation and replaces it with separate
	separate post-handshake authentication and key update mechanisms.		post-handshake authentication and key update mechanisms. Post-
	The former shares the same problems with multiplexed protocols, but		handshake authentication has the same problems with multiplexed
	the prohibition in [RFC7540] only applies to TLS 1.2 renegotiation.		protocols as TLS 1.2 renegotiation, but the prohibition in [RFC7540]
			only applies to renegotiation.
	This document updates HTTP/2 to similarly forbid TLS 1.3 post-		This document updates HTTP/2 [RFC7540] to similarly forbid TLS 1.3
	handshake authentication.		post-handshake authentication.
	2. Requirements Language		2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. Post-Handshake Authentication in HTTP/2		3. Post-Handshake Authentication in HTTP/2
	skipping to change at page 3, line 31 ¶		skipping to change at page 3, line 33 ¶
	PROTOCOL_ERROR.		PROTOCOL_ERROR.
	[RFC7540] permitted renegotiation before the HTTP/2 connection		[RFC7540] permitted renegotiation before the HTTP/2 connection
	preface to provide confidentiality of the client certificate. TLS		preface to provide confidentiality of the client certificate. TLS
	1.3 encrypts the client certificate in the initial handshake, so this		1.3 encrypts the client certificate in the initial handshake, so this
	is no longer necessary. HTTP/2 servers MUST NOT send post-handshake		is no longer necessary. HTTP/2 servers MUST NOT send post-handshake
	TLS 1.3 CertificateRequest messages before the connection preface.		TLS 1.3 CertificateRequest messages before the connection preface.
	The above applies even if the client offered the		The above applies even if the client offered the
	"post_handshake_auth" TLS extension. This extension is advertised		"post_handshake_auth" TLS extension. This extension is advertised
	independently of the selected ALPN protocol [RFC7301], so it is not		independently of the selected Application-Layer Protocol Negotiation
	sufficient to resolve the conflict with HTTP/2. HTTP/2 clients that		(ALPN) protocol [RFC7301], so it is not sufficient to resolve the
	also offer other ALPN protocols, notably HTTP/1.1, in a TLS		conflict with HTTP/2. HTTP/2 clients that also offer other ALPN
	ClientHello MAY include the "post_handshake_auth" extension to		protocols, notably HTTP/1.1, in a TLS ClientHello MAY include the
	support those other protocols. This does not indicate support in		"post_handshake_auth" extension to support those other protocols.
	HTTP/2.		This does not indicate support in HTTP/2.
	4. Other Post-Handshake TLS Messages in HTTP/2		4. Other Post-Handshake TLS Messages in HTTP/2
	[RFC8446] defines two other messages that are exchanged after the		[RFC8446] defines two other messages that are exchanged after the
	handshake is complete, KeyUpdate and NewSessionTicket.		handshake is complete: KeyUpdate and NewSessionTicket.
	KeyUpdate messages only affect TLS itself and do not require any		KeyUpdate messages only affect TLS itself and do not require any
	interaction with the application protocol. HTTP/2 implementations		interaction with the application protocol. HTTP/2 implementations
	MUST support key updates when TLS 1.3 is negotiated.		MUST support key updates when TLS 1.3 is negotiated.
	NewSessionTicket messages are also permitted. Though these interact		NewSessionTicket messages are also permitted. Though these interact
	with HTTP when early data is enabled, these interactions are defined		with HTTP when early data is enabled, these interactions are defined
	in [RFC8470] and allowed for in the design of HTTP/2.		in [RFC8470] and are allowed for in the design of HTTP/2.
	Unless the use of a new type of TLS message depends on an interaction		Unless the use of a new type of TLS message depends on an interaction
	with the application-layer protocol, that TLS message can be sent		with the application-layer protocol, that TLS message can be sent
	after the handshake completes.		after the handshake completes.
	5. Security Considerations		5. Security Considerations
	This document resolves a compatibility concern between HTTP/2 and TLS		This document resolves a compatibility concern between HTTP/2 and TLS
	1.3 when supporting post-handshake authentication with HTTP/1.1.		1.3 when supporting post-handshake authentication with HTTP/1.1.
	This lowers the barrier for deploying TLS 1.3, a major security		This lowers the barrier for deploying TLS 1.3, a major security
End of changes. 12 change blocks.
	25 lines changed or deleted		27 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/