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

[Christopher Wood <[e-mail]>]

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