Re: [Masque] HTTP Upgrade Request Smuggling Draft

Thanks for reviewing this draft, David.

Re: change #2, I agree that this change is not necessary, and I'm open to removing it.  However, I do think it is more than a performance optimization: it also helps to make the HTTP client state machine more comprehensible and could simplify implementation.  For example, prior to RFC 9298, an HTTP client could offer an "Upgrade" API that grabs a socket from the pool, attempts the upgrade, and returns the socket to the pool if the upgrade fails.  This seems to be consistent with how Upgrade was originally envisioned in HTTP/1.1.  However, CONNECT-UDP cannot be supported in such an arrangement without change #2.

--Ben Schwartz

________________________________
From: David Schinazi <dschinazi.ietf@gmail.com>
Sent: Thursday, September 7, 2023 3:07 PM
To: Ben Schwartz <bemasc@meta.com>
Cc: ietf-http-wg@w3.org <ietf-http-wg@w3.org>; masque@ietf.org <masque@ietf.org>
Subject: Re: [Masque] HTTP Upgrade Request Smuggling Draft

Hi Ben, and thanks for writing this up. Your draft contains three normative statements: 1) Clients MUST NOT send connect-udp data optimistically in HTTP versions < 2. -- This solves the security issue that this document describes and is
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd
Hi Ben, and thanks for writing this up.

Your draft contains three normative statements:

1) Clients MUST NOT send connect-udp data optimistically in HTTP versions < 2.

-- This solves the security issue that this document describes and is a good improvement to RFC 9298.

2) HTTP/1.1 clients MAY reuse connections if the Upgrade header is missing from a failure response.

-- This is a premature performance optimization that is specific to HTTP/1.1 so I would remove it. It could lead to security issues down the road and I'm not aware of any need for such an optimization. Deployments that care about performance use HTTP/2 or 3.

3) Future specs MUST think about this.

-- This is fine. Requirements on future specifications are always weak because such specifications can always update this document to work around them, but telling authors to think about this is useful.

David


On Mon, Aug 21, 2023 at 12:53 PM Ben Schwartz <bemasc=40meta.com@dmarc.ietf.org<mailto:40meta.com@dmarc.ietf.org>> wrote:
Hi HTTPBIS + MASQUE,

In HTTPBIS at IETF 117, I mentioned some issues related to "optimistic" use of HTTP Upgrade and a theoretical Request Smuggling issue with connect-udp in HTTP/1.1.  Several commenters suggested that I write a separate draft on that topic, which I've now done:

Security Considerations for Optimistic Use of HTTP Upgrade
https://datatracker.ietf.org/doc/html/draft-schwartz-httpbis-optimistic-upgrade-00<https://datatracker.ietf.org/doc/html/draft-schwartz-httpbis-optimistic-upgrade-00>

Abstract: "The HTTP/1.1 Upgrade mechanism allows the client to request a change to a new protocol. This document discusses the security considerations that apply to data sent by the client before this request is confirmed, and updates RFC 9298 to avoid related security issues."

Please review.

--Ben Schwartz
--
Masque mailing list
Masque@ietf.org<mailto:Masque@ietf.org>
https://www.ietf.org/mailman/listinfo/masque<https://www.ietf.org/mailman/listinfo/masque>