Subject: [Ohttp] Is the use of this work likely to help miscreants more than those in need of privacy?

From: Eliot Lear <[email-masked]>
Date: Tue, 15 Jun 2021 08:43:21 +0200

Hi Martin,

I've broken out your response to me so that it doesn't get lost in other 
discussion.

>     2. Is the use of this work likely to help miscreants more than those in need of privacy?
>
> No more so than building any other sort of infrastructure helps other miscreants.  I don't ordinarily engage with this sort of comment.  Better tools exist for miscreants.

Let's not be quite so dismissive. I did go on to elaborate my concerns 
in more detail – it wasn't a throw-away comment.  A particular risk here 
is that a participating web site gets pounded without much recourse to 
know which BOTs are doing the pounding. This is of particular concern 
when you say:

> I don't think that anyone is considering these two resources being operated by the same entity.  There is definitely value in having independent operation of these services.

If the operator of the proxy is VERY large, there may be very little 
recourse.  Let's take an example: if Apple were to offer OHTTP to 
iPhone/iPad/Safari customers, it would mean that a web site would have 
to cut off all of those billions of devices, disable the service 
entirely, or otherwise signal back to Apple alone, “for today your 
customers should go back to the old fashioned way.”  And Apple could 
choose to, or simply produce an error.  In other words, OHTTP could 
further the effects of concentration.  (FWIW I have no idea if Apple 
would implement OHTTP, I am just using them as a hypothetical to advance 
the discussion.)

> I do want to point to one thing here that is inherent in the design.  The two main resources that are involved in the exchange - the one at the proxy and the one that does decryption - all have a fixed relationship to each other.  This is deliberate because it avoids having any sort of open encrypted relay.  That doesn't mean that those resources couldn't use URI parameters, but it does mean that without knowledge of the deployment, you won't naturally get the sort of flexibility that might be exploited in the same way that DNS[1] has been.

When you say “the one that does the decryption” I am presuming you mean 
the origin server or something close to it, as opposed to the client, 
who is presumably also decrypting.

To me this ties to discovery and agency:

  * If the proxy is acting as an agent of the HTTP client, then why
    would it fix its relationship to the server?  It is merely a matter
    of understanding (a) whether the origin supports OHTTP and (b)
    whether the proxy will accept traffic for a particular origin/URL,
    depending on what granularity you would like.
  * If the proxy is acting as an agent of the server, then why should
    the client trust it to obfuscate its source?
  * And if the proxy is operating independently, then why should either
    end trust it at all, and why would the service be offered?

I had other questions in my original email.  If you'd like I could 
resend them.  Really, I would like to understand that standardizing this 
work won't cause more harm than good, and I do mean the question not to 
be rhetorical, though it may sound so.

Eliot

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 15 Jun 2021 17:26:24 +1000

Thanks for your response Eliot.

On Tue, Jun 15, 2021, at 16:43, Eliot Lear wrote:
> in more detail – it wasn't a throw-away comment.  A particular risk 
> here is that a participating web site gets pounded without much 
> recourse to know which BOTs are doing the pounding.  

Ah, that issue.  You listed a whole bunch of things, which make me interpret your mail as the usual "oh, encryption" arguments.

This is addressed in the draft:

> If a server accepts a larger volume of requests from a proxy, it needs to trust that the proxy does not allow abusive levels of request volumes from clients. That is, if a server allows requests from the proxy to be exempt from rate limits, the server might want to ensure that the proxy applies a rate limiting policy that is acceptable to the server.

-- https://unicorn-wg.github.io/oblivious-http/draft-thomson-http-oblivious.html#section-8.2.1-2

> would implement OHTTP, I am just using them as a hypothetical to 
> advance the discussion.)

I think that you need to say what OHTTP is used for in this case.  As has been stated a few times, this is totally unsuitable for general purpose browsing.

> who is presumably also decrypting.

There are two origin servers, one that serves the (encrypted) request and one that merely decrypts the request and forwards it.

> To me this ties to discovery and agency:

Let's get the basics sorted out first.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 15 Jun 2021 22:21:28 +0200

Hi Martin,

> Ah, that issue.  You listed a whole bunch of things, which make me interpret your mail as the usual "oh, encryption" arguments.

Not in this case.  In this case, I'm struggling with security 
considerations.

>> If a server accepts a larger volume of requests from a proxy, it needs to trust that the proxy does not allow abusive levels of request volumes from clients. That is, if a server allows requests f…

Yes.  What is that form of assurance?  Because that goes to what the 
intended positive value is expected from the design.

> I think that you need to say what OHTTP is used for in this case. As 
> has been stated a few times, this is totally unsuitable for general 
> purpose browsing.

This is independent of the intended use case.  This is about 
accountability, and what happens when things go wrong, and how one 
manages a service.

> Let's get the basics sorted out first.

Harumph.  I think who the proxy is supposed to be working for is pretty 
fundamental.

Eliot

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 16 Jun 2021 10:00:55 +1000

> Harumph.  I think who the proxy is supposed to be working for is pretty 

OK, let's talk about that some more.  The draft goes into a bit of detail on this point, but it is probably worth rehashing.

The proxy is mutually chosen by client and server.  Both trust the proxy a tiny bit.  The client trusts that the proxy won't reveal links between its requests.  The server trusts that that proxy will not overload it.  That's just about it.  There's a little more to the client trust in that the proxy might need to do something more about traffic analysis, but that's somewhat less concrete as that remains an open-ended problem.

Relying on trust is a point of difference from systems like Tor, which assume very little mutual trust.

Take a concrete deployment example.  Mozilla has identified several classes of telemetry that we would like to collect.  We split that into stuff that is safe to attribute to users, stuff that might be a privacy risk but only if it is aggregated, and more sensitive stuff (and of course there might be stuff we decide is too dangerous to gather under any circumstances).  We use direct submission for the first, ohttp for the second, and MPC-based designs like Prio for the last category.  To deploy ohttp for this, we contract with an independent third party who we hope our users find trustworthy.  For the server, they agree not to allow spamming; for the client, they agree not to pass on IP addresses and the like.  Yes, in this, the proxy would formally be deriving support from Mozilla, but as vendor of both client and server, that's the only option.  As far as it goes, that is what our Prio deployments look like as well, to my knowledge.