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

[Eric Rescorla <[e-mail]>]

> 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.

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.


> My concerns are not all technical ones but include:
>
> 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.


> 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.

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


> 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.

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.


> 4/ Related to 3/ (and perhaps less important), Law Enforcement Agencies in
> 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 <
[e-mail]> wrote:

> É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.
>
>
>
>
>
> --
> Ohttp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ohttp
>