draft-ietf-httpbis-optimistic-upgrade-02.txt		draft-ietf-httpbis-optimistic-upgrade-latest.txt
	HTTPBIS Working Group		HTTPBIS Working Group
	Internet-Draft Meta Platforms, Inc.		Internet-Draft Meta Platforms, Inc.
	Updates: 9298 (if approved) March 17, 2025		Updates: 9112, 9298 (if approved) April 03, 2025
	Intended status: Standards Track		Intended status: Standards Track
	Expires: September 18, 2025		Expires: October 5, 2025
	Security Considerations for Optimistic Protocol Transitions in HTTP/1.1		Security Considerations for Optimistic Protocol Transitions in HTTP/1.1
	draft-ietf-httpbis-optimistic-upgrade-02		draft-ietf-httpbis-optimistic-upgrade-latest
	Abstract		Abstract
	In HTTP/1.1, the client can request a change to a new protocol on the		In HTTP/1.1, the client can request a change to a new protocol on the
	existing connection. This document discusses the security		existing connection. This document discusses the security
	considerations that apply to data sent by the client before this		considerations that apply to data sent by the client before this
	request is confirmed, and updates RFC 9298 to avoid related security		request is confirmed, and updates RFC 9298 to avoid related security
	issues.		issues.
	About This Document		About This Document
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 18, 2025.		This Internet-Draft will expire on October 5, 2025.
	Copyright Notice		Copyright Notice
	Copyright (c) 2025 IETF Trust and the persons identified as the		Copyright (c) 2025 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 2, line 39 ¶		skipping to change at page 2, line 39 ¶
	5.1. "TLS" . . . . . . . . . . . . . . . . . . . . . . . . . . 6		5.1. "TLS" . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	5.2. "WebSocket"/"websocket" . . . . . . . . . . . . . . . . . 6		5.2. "WebSocket"/"websocket" . . . . . . . . . . . . . . . . . 6
	5.3. "connect-udp" . . . . . . . . . . . . . . . . . . . . . . 7		5.3. "connect-udp" . . . . . . . . . . . . . . . . . . . . . . 7
	5.4. "connect-ip" . . . . . . . . . . . . . . . . . . . . . . 8		5.4. "connect-ip" . . . . . . . . . . . . . . . . . . . . . . 8
	6. Guidance for Future Upgrade Tokens . . . . . . . . . . . . . 8		6. Guidance for Future Upgrade Tokens . . . . . . . . . . . . . 8
	6.1. Selection of Request Methods . . . . . . . . . . . . . . 8		6.1. Selection of Request Methods . . . . . . . . . . . . . . 8
	7. Guidance for HTTP CONNECT . . . . . . . . . . . . . . . . . . 8		7. Guidance for HTTP CONNECT . . . . . . . . . . . . . . . . . . 8
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	9.1. Normative References . . . . . . . . . . . . . . . . . . 9		9.1. Normative References . . . . . . . . . . . . . . . . . . 9
	9.2. Informative References . . . . . . . . . . . . . . . . . 9		9.2. Informative References . . . . . . . . . . . . . . . . . 10
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Conventions and Definitions		1. Conventions and Definitions
	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		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	skipping to change at page 8, line 49 ¶		skipping to change at page 8, line 49 ¶
	Future specifications for Upgrade Tokens should restrict their use to		Future specifications for Upgrade Tokens should restrict their use to
	"GET" requests if the HTTP method is otherwise irrelevant and a		"GET" requests if the HTTP method is otherwise irrelevant and a
	request body is not required. This improves consistency with other		request body is not required. This improves consistency with other
	Upgrade Tokens and reduces the likelihood that a faulty server		Upgrade Tokens and reduces the likelihood that a faulty server
	implementation might process the request body as the new protocol.		implementation might process the request body as the new protocol.
	7. Guidance for HTTP CONNECT		7. Guidance for HTTP CONNECT
	In HTTP/1.1, proxy clients that send CONNECT requests on behalf of		In HTTP/1.1, proxy clients that send CONNECT requests on behalf of
	untrusted TCP clients MUST wait for a 2xx (Successful) response		untrusted TCP clients MUST do one or both of the following:
	before forwarding any TCP payload data. Proxy clients that start
	forwarding before confirming the response status code are vulnerable
	to a trivial request smuggling attack (Section 3.1).
	To mitigate the impact of such vulnerable clients, proxy servers MAY		1. Wait for a 2xx (Successful) response before forwarding any TCP
	close the underlying connection when rejecting an HTTP/1.1 CONNECT		payload data.
	request, without processing any further data on that connection.
	Note that this behavior will frequently impair the performance of		2. Send a "Connection: close" request header.
	correctly implemented clients, especially when returning a "407
	(Proxy Authentication Required)" response. This performance loss can		Proxy clients that don't implement at least one of these two
	be be avoided by using HTTP/2 or HTTP/3, which are not vulnerable to		behaviors are vulnerable to a trivial request smuggling attack
	this attack.		(Section 3.1).
			At the time of writing, some proxy clients are believed to be
			vulnerable as described. When communicating with potentially
			vulnerable clients, proxy servers MUST close the underlying
			connection when rejecting an HTTP/1.1 CONNECT request, without
			processing any further data on that connection, whether or not the
			request headers include "Connection: close". Note that this
			mitigation will frequently impair the performance of correctly
			implemented clients, especially when returning a "407 (Proxy
			Authentication Required)" response. This performance loss can be
			avoided by using HTTP/2 or HTTP/3, which are not vulnerable to this
			attack.
	8. IANA Considerations		8. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
End of changes. 7 change blocks.
	17 lines changed or deleted		26 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/