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

["Eric Vyncke (evyncke)" <[e-mail]>]

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 <[e-mail]>
Date: Wednesday, 16 June 2021 at 16:35
To: Eric Vyncke <[e-mail]>
Cc: The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Ohttp] Éric Vyncke's Block on charter-ietf-ohttp-00-00: (with 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.

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:

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

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.

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 ?


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.

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


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

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


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

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


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


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

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