Resent-Date: Sat, 27 Jul 2024 14:45:09 +0000
Resent-Message-Id: <E1sXifV-00BYTQ-1U@mab.w3.org>
Received-SPF: pass (pan.w3.org: domain of gmail.com designates 2a00:1450:4864:20::135 as permitted sender) client-ip=2a00:1450:4864:20::135; envelope-from=patmeenan@gmail.com; helo=mail-lf1-x135.google.com;
MIME-Version: 1.0
References: <CAF3KT4QZzx+FXOUHZoy+gPqJjQ+4KdOC+_29vbUANNtZQS4c+A@mail.gmail.com>
 <ba56fad8-e121-4c06-9a2d-783ef82471e0@gmx.de>
In-Reply-To: <ba56fad8-e121-4c06-9a2d-783ef82471e0@gmx.de>
From: Patrick Meenan <patmeenan@gmail.com>
Date: Sat, 27 Jul 2024 10:44:50 -0400
Message-ID: <CAJV+MGz8hUTqar51V9wV=WPnWETDK+ECjWCTXYS92xXM5HEF_w@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: ietf-http-wg@w3.org
Content-Type: multipart/alternative; boundary="0000000000003f5650061e3bac5c"
Subject: Re: Method Mania
Archived-At: <https://www.w3.org/mid/CAJV+MGz8hUTqar51V9wV=WPnWETDK+ECjWCTXYS92xXM5HEF_w@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

--0000000000003f5650061e3bac5c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 27, 2024 at 4:23=E2=80=AFAM Julian Reschke <julian.reschke@gmx.=
de>
wrote:

> On 26.07.2024 00:27, Josh Cohen wrote:
> > On the httpwg agenda at IETF 120 were a proposal for a new QUERY method
> > and Braid, which has subscription functionality that overloads the GET
> > method.
> >
> > What I am curious about is if, at this point in the evolution of the
> > web, it is now safe to add new methods for new functionality. I've been
> > reading up on HTTP/2/3 and it seems that nowadays, connections are
> > end-to-end secure and are essentially tunneled through middle boxes,
> > including HTTP/1.1 proxies. I'm still just wrapping my head around
> > MASQUE, but it looks like it can handle arbitrary methods.  Similarly
> > origin servers have evolved to support arbitrary methods.
>
> It always has been "safe", when https was used.


https is not "safe" in practical terms because of middleboxes that
intercept the connections. It is very common in enterprise deployments
where they install local trust anchors on the client devices and use mitm
software to inspect the traffic.

Even HTTP/2 is not necessarily "safe" as we are seeing with the deployment
of compression dictionaries as there are enterprise mitm devices that
inspect HTTP/2 traffic as well (and in our case, reset connections when
they see a content-encoding they don't understand).

The better question is under what circumstances do we want to allow those
devices to "break" and force them to fix the implementations? HTTP/S (or
just H/2/3 if you want to be less intrusive) could be considered reasonable
because the proxies are under the control of the site (CDN) or environment
where they are being run (enterprise) and there's not random gear spread
elsewhere in the Internet that needs to be tracked down.  The site-level is
generally easy (don't use the new features on a given site if the serving
path doesn't support it) but cleaning up the enterprise ecosystem can be a
nightmare and a much bigger case of whack-a-mole.

The alternative (that Chrome uses for HTTP/3) is to only use the new
feature when the connection is TLS-anchored to a well-known trust root (no
middleboxes on the client end) but that is allowing some portion of the
Internet to continue to operate "broken" infrastructure.

--0000000000003f5650061e3bac5c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jul 27, 2024 at 4:23=E2=80=AF=
AM Julian Reschke &lt;<a href=3D"mailto:julian.reschke@gmx.de">julian.resch=
ke@gmx.de</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">On 26.07.2024 00:27, Josh Cohen wrote:<br>
&gt; On the httpwg agenda at IETF 120 were a proposal for a new QUERY metho=
d<br>
&gt; and Braid, which has subscription functionality that overloads the GET=
<br>
&gt; method.<br>
&gt;<br>
&gt; What I am curious about is if, at this point in the evolution of the<b=
r>
&gt; web, it is now safe to add new methods for new functionality. I&#39;ve=
 been<br>
&gt; reading up on HTTP/2/3 and it seems that nowadays, connections are<br>
&gt; end-to-end secure and are essentially tunneled through middle boxes,<b=
r>
&gt; including HTTP/1.1 proxies. I&#39;m still just wrapping my head around=
<br>
&gt; MASQUE, but it looks like it can handle arbitrary methods.=C2=A0 Simil=
arly<br>
&gt; origin servers have evolved to support arbitrary methods.<br>
<br>
It always has been &quot;safe&quot;, when https was used.</blockquote><div>=
<br></div><div>https is not &quot;safe&quot; in practical terms because of =
middleboxes that intercept the connections. It is very common in enterprise=
 deployments where they install local trust anchors on the client devices a=
nd use mitm software to inspect the traffic.</div><div><br></div><div>Even =
HTTP/2 is not necessarily &quot;safe&quot; as we are seeing with the deploy=
ment of compression dictionaries as there are enterprise mitm devices that =
inspect HTTP/2 traffic as well (and in our case, reset connections when the=
y see a content-encoding they don&#39;t understand).</div><div><br></div><d=
iv>The better question is under what circumstances do we want to allow thos=
e devices to &quot;break&quot; and force them to fix the implementations? H=
TTP/S (or just H/2/3 if you want to be less intrusive) could be considered =
reasonable because the proxies are under the control of the site (CDN) or e=
nvironment where they are being run (enterprise) and there&#39;s not random=
 gear spread elsewhere in the Internet that needs to be tracked down.=C2=A0=
 The site-level is generally easy (don&#39;t use the new features on a give=
n site if the serving path doesn&#39;t support it) but cleaning up the ente=
rprise ecosystem can be a nightmare and a much bigger case of whack-a-mole.=
</div><div><br></div><div>The alternative (that Chrome uses for HTTP/3) is =
to only use the new feature when the connection is TLS-anchored to a well-k=
nown trust root (no middleboxes on the client end) but that is allowing som=
e portion of the Internet to continue to operate &quot;broken&quot; infrast=
ructure.</div></div></div>

--0000000000003f5650061e3bac5c--