Subject: [Ohttp] Éric Vyncke's Block on charter-ietf-ohttp-00-00: (with BLOCK)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Wed, 16 Jun 2021 02:42:15 -0700

Éric Vyncke has entered the following ballot position for
charter-ietf-ohttp-00-00: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-ohttp/

----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

I have many concerns about OHTTP (see below), which may be shared by the
community. Therefore, a BoF is required before creating the WG hence my BLOCK.
We may also wonder why creating a working group for a single document and
whether ART is the right area but those points are details.

My concerns are not all technical ones but include:

1/ What is the incentive for the proxy/request intermediaries ?

2/ Depending on 1/, we may expect that just a couple of intermediaries will
exist, this leads to centralization to a couple of parties but also introduces
a single point of failure, scalability issues, and easier censorship.

3/ While OHTTP would be able to 'hide' the good guys from  bad
networks/servers, it would also protect the bad guys who can then easily attack
servers; leaving servers defenseless as they cannot protect against an attack
by blocking a couple of IP addresses without also impacting the normal users.
Section 8.2.1 of the I-D is a little light on the topic. Tor currently does not
have the bandwidth to be a DoS vector.

4/ Related to 3/ (and perhaps less important), Law Enforcement Agencies in
democratic countries will become less and less able to achieve their tasks.

All in all, the points above should be discussed by the community before
creating a WG.

There should also be an operational consideration part.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 Jun 2021 07:34:28 -0700

> whether ART is the right area but those points are details.

Perhaps, as Mark Nottingham suggests, it would simply be easier to
have this work done in HTTP, thus addressing the "why create a new
WG question", and making this proposed charter moot.

With that said, I think perhaps you misunderstand the setting in which
O-HTTP is intended to be deployed. I.e., it is not a generic proxying
system like Tor but rather one which is designed to allow the client,
server, and proxy to work together to conceal the client's IP address
from the server. Indeed, the most natural deployment scenarios are
ones in which the client, origin server, and proxy are all coordinated
by a single entity. For instance:

1. A browser who wants to send telemetry back to the manufacturer
while concealing the IP address. In this case, the browser and
manufacturer are controlled by the same entity, who also arranges
for the proxy, which is preconfigured into the browser.

2. Oblivious DoH (in a TRR configuration). In this case, the client
and proxy might be operated by the same entity who then has an
arrangement with the DoH server.

Note that these cases are largely maintaining existing topologies,
but merely inserting a proxy. Moreover, as noted above, these
relationships are largely static.

> 1/ What is the incentive for the proxy/request intermediaries ?

I don't really think this question is in scope for WG review.  We
don't typically ask why organizations want to do things, but merely
whether there is interest. I think it's clear from the discussion
leading to this that there is interest and I can tell you that Mozilla
is looking at running such a proxy, as are others who may want to
speak for themselves.

> a single point of failure, scalability issues, and easier censorship.

This is irrelevant for the use cases of interest, as described above.

> have the bandwidth to be a DoS vector.

This is an issue to some extent, but because the relationships are to
some extent static (i.e., the server does not expect to receive large
traffic volumes from arbitrary proxies), it is less than with a
generic proxying protocol. In general, servers are going to expect
that proxies do anti-DoS. With that said, because the O-HTTP requests
are wrapped, it is possible for the proxy to provide anti-DoS
meta-information (e.g., IP reputation) that is more difficult with a
generic proxying protocol.  Moroever, unlike a generic proxying
protocol, we don't expect ordinary HTTP servers to run this, so the
risk is easier to control.

> democratic countries will become less and less able to achieve their
tasks.

I don't think this is an appopriate consideration either, for the
reasons indicated in RFC 2804.

These detailed points aside, these objections seem particularly out of
place in light of the fact that the IETF is presently designing a
generic proxying protocol that is designed to work with any server,
without modification (MASQUE). All of the considerations you list
above apply a fortiori there (and, for that matter, to RFC 2817 HTTP
CONNECT, TURN over TLS, and any VPN protocol we've designed).  Given
that O-HTTP is a more limited system than all of those (differing
primarily in that it is optimized for single request/response pairs)
it's hard to understand what the problem is.

-Ekr

On Wed, Jun 16, 2021 at 2:42 AM Éric Vyncke via Datatracker <
[email-masked]> wrote:

> --
> Ohttp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ohttp
>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 17 Jun 2021 12:28:55 +0000

Hello Eric

Thank you for your detailed reply and the explanations. I still consider that the topic should be presented to the community during a BoF where a longer explanation and Q&A could be done rather than a 30-minute session at secdispatch.

If you do not mind, then some more from me below, look for EV>

Regards

-éric

From: Eric Rescorla <[email-masked]>
Date: Wednesday, 16 June 2021 at 16:35
To: Eric Vyncke <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Ohttp] Éric Vyncke's Block on charter-ietf-ohttp-00-00: (with BLOCK)

EV> Indeed: I misunderstood it; it is clear neither from the draft charter nor from the I-D

EV> I understand the requirements and the use cases (thank you BTW), but, if all the pieces are from the same entity, then I wonder what is the purpose of the machinery ? I could understand OHTTP if the 2 proxies are operated by different entities but with one ?

EV> see my point above, what is the use of it if all function elements are controlled by a single entity ?

EV> agreed if this is limited to those use cases but it can obviously be extended to any HTTP session.

EV> understood, but, far from being clear from the I-D and proposed charter

EV> hence my ‘and perhaps less important’
EV> and in the described use cases above, this is not even relevant at all

-Ekr

On Wed, Jun 16, 2021 at 2:42 AM Éric Vyncke via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
Éric Vyncke has entered the following ballot position for
charter-ietf-ohttp-00-00: Block

--
Ohttp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ohttp

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 17 Jun 2021 05:42:28 -0700

(Top-posting, since there are several comments that seem to stem from a misunderstanding.)

I'm not Ekr, but I believe by "coordinated by a single entity" he meant that the _choice_ of proxy and target is made by a single entity. One example given was that a browser might choose the proxy to use for sending telemetry to a manufacturer, which may also be controlled by the same entity which controls the browser. This does _not_ mean that the proxy is also controlled by this same entity. (Indeed, as you observe, this would obviate the benefits of the protocol.) It simply means that the in the deployment envisioned the selection or and relationships between non-colluding entities is pre-arranged by some entity.

Does that help clarify?

Best,
Chris

On Thu, Jun 17, 2021, at 5:28 AM, Eric Vyncke (evyncke) wrote:
>  
> Hello Eric
> 
>  
> 
> Thank you for your detailed reply and the explanations. I still 
> consider that the topic should be presented to the community during a 
> BoF where a longer explanation and Q&A could be done rather than a 
> 30-minute session at secdispatch.
> 
>  
> 
> *From: *Eric Rescorla <[email-masked]>
> *Date: *Wednesday, 16 June 2021 at 16:35
> *To: *Eric Vyncke <[email-masked]>
> *Cc: *The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, 
> "[email-masked]" <[email-masked]>
> *Subject: *Re: [Ohttp] Éric Vyncke's Block on charter-ietf-ohttp-00-00: 
> (with BLOCK)
> 
>  
> 
> EV> I understand the requirements and the use cases (thank you BTW), 
> but, if all the pieces are from the same entity, then I wonder what is 
> the purpose of the machinery ? I could understand OHTTP if the 2 
> proxies are operated by different entities but with one ?
> 
>  
> 
> 
> On Wed, Jun 16, 2021 at 2:42 AM Éric Vyncke via Datatracker 
> <[email-masked]> wrote:
> 
> [email-masked] <mailto:Ohttp%40ietf.org>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Jun 2021 05:42:53 -0700

On Thu, Jun 17, 2021 at 5:29 AM Eric Vyncke (evyncke) <[email-masked]>
wrote:

> Hello Eric
>
>
>
> Thank you for your detailed reply and the explanations. I still consider
> that the topic should be presented to the community during a BoF where a
> longer explanation and Q&A could be done rather than a 30-minute session at
> secdispatch.
>

Given the delay that this introduces, ISTM that this needs a bit more than
"I still consider". This is effectively just an optimization of existing
mechanisms. What's the issue?

> EV> I understand the requirements and the use cases (thank you BTW), but,
> if all the pieces are from the same entity, then I wonder what is the
> purpose of the machinery ? I could understand OHTTP if the 2 proxies are
> operated by different entities but with one ?
>

First, there's likely only one proxy. Second, they're not operated by the
same entity One of them is a third party, potentially with an arrangement
with the other party.

> extended to any HTTP session.

Not easily, no. It requires changing the origin server and then some
unspecified and difficult to specify discovery mechanism.

As I said, I'm really struggling to see the objections here, given that
we're already standardizing a generic proxying
system (MASQUE). Can you explain your reasoning?>

-Ekr

[email-masked]