Subject: [Ohttp] OHTTP applications I've seen

From: Watson Ladd <[email-masked]>
Date: Tue, 27 Jul 2021 23:17:12 -0700

Back in 2015 Matthew Green, Ian Miers, and I came up with a privacy
preserving advertising system that was completely impractical to
deploy. We solved the impression reporting issue thanks to application
of Groth-Kohlweiss and some implementation tricks, but we could not
serve the creative in a privacy preserving way.

Our paper cited PIR, private information retrieval.  The PIR lower
bound comes from an elementary observation that the response has to
depend on the entire database. It's a slow process, and completely
insuitable for deployment due to information theoretic lower bounds.
Tor would have melted down under the load.

If Oblivous HTTP had been available, this would have been solved.
Request the creative through Oblivious HTTP, and there is no way for
the server, the request resource, or the proxy resource to infer
client characteristics as no one sees the request and the client IP
together. Without Oblivious HTTP there isn't a way to make these sorts
of design work. And unlike MASQUE Oblivious HTTP is easy to use from
Javascript in the browser, which is nice for prototyping and other
reasons.

In another privacy enhancing technology I've been working on, which
you'll hear about in a few weeks, Oblivious HTTP is the natural
solution to an information gathering problem in edge cases where a
server needs some more information. The information could identify a
client if connected to other requests, but if separated from that is
innocuous. Applying Oblivous HTTP would simplify the issue massively.

I hope these two examples illuminate what use cases the protocol is
for and help advance the charter discussion.

Sincerely,
Watson Ladd

-- 
Astra mortemque praestare gradatim

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 28 Jul 2021 12:35:04 +0200 (CEST)

> Il 28/07/2021 08:17 Watson Ladd <[email-masked]> ha scritto:
> 

After our middle-of-the-night BoF, I also think I have a much clearer understanding of the intended use cases. What I finally understood is that - while being aimed at improving the end-user's privacy - this is not meant to be a service to the end-user, but a service to the server.

In other words, we have a service, and a server, that voluntarily wants to interpose an intermediate proxy to learn less information about the user, or, more precisely, not to learn their IP address. At the same time, this intermediate proxy needs to have an established trust relationship with the server operator, because the service needs to trust that all the requests it gets from the proxy are real and, for example, are already screened for bots and DoS attacks; it can't just accept requests from any proxy the user might want to use. I would call the concept "server-controlled HTTP indirection" (SCHI).

Perhaps this was clear to everybody else, but I confess it was not for me, and possibly for others given yesterday's comments, and I don't think it is clear from the charter. Some text around this is warranted (happy to work on it).

However, I think it should also be made clear to users (e.g. in the privacy considerations of the protocol) that the additional privacy they get is conceptually limited by the need for a relationship between the server and the proxy, which requires the user to trust that this relationship will not feature collusion on putting the two parts of the request back together for tracking purposes. 

Traditionally, privacy-enabling proxies are to be chosen by the user (the PII owner), not by the destinations, for this very reason; the trust relationship is user-proxy, not server-proxy. SCHI is a weaker form of privacy protection that can still be useful, but should not be confused with the other, especially by the end-users. SCHI requires the user to trust the service provider anyway, while traditional proxies do not (but require them to trust the proxy provider).

This difference is IMHO one of the reasons why the proposal is hard to grasp at first sight - when you want to increase the user's privacy in front of a server, it is natural to consider the server as the adversary, not as the owner of the mechanism. (It won't be easy to specify a coherent threat model...)

This also explains why discovery in this model may not be so relevant. It should however be recognized that if SCHI is used for DoH services, then discovery has to get into the picture - but it's discovery of the service, not of the intermediate proxy. Some DoH services may offer SCHI as an additional guarantee, and that could be communicated via future ADD protocols during the resolver discovery phase.

In terms of consolidation, there may still be issues if many significant service providers pick the same intermediate proxy provider. I'm not immediately sure of how to deal with this, as this is a consequence of service provider choices, not of user choices. There might be a recommendation that services let users pick a proxy of their choice among a set of proxy providers that they also trust; this could benefit from a discovery protocol, but could also be just a matter of configuration UI. In theory, the user's access provider could provide a proxy that the user could discover and use automatically, but I don't see servers trusting each possible ISP's proxy automatically as well, and in this model server preferences have priority. It's a discussion we can have in the group.

All in all, if this is the conceptual model, I think it finally provides a clear view of the difference between this project and MASQUE, and addresses many of the concerns. I would however revise the charter a bit to make sure that this is extra clear, because as written, the current charter still seems to describe a generic HTTP proxying protocol, and the model above, which is somewhat clearer in Martin's draft, is entirely lost; but the charter alone should be enough to understand it.

I would also definitely find another name. "Oblivious" indicates the generic action of routing your request through one or more proxies to hide your IP address to the server; "oblivious HTTP" includes a much broader set of use cases and architectures than this proposal (even Tor is a form of "oblivious HTTP"). I think that the server's leadership in this mechanism is its defining feature, so that's what I'd put in the name, but of course we can still bikeshed together for some time.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Jim Reid <[email-masked]>
Date: Wed, 28 Jul 2021 11:57:36 +0100

> On 28 Jul 2021, at 11:35, Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:
> 
> I would also definitely find another name. "Oblivious" indicates the generic action of routing your request through one or more proxies to hide your IP address to the server

How about obfuscated HTTP?

obfuscate /obˈfə-skāt or ob-fusˈkāt/
transitive verb
	• To darken
	• To obscure
	• To confuse or bewilder

---

From: Eliot Lear <[email-masked]>
Date: Wed, 28 Jul 2021 13:57:54 +0200

Hi Vittorio

> In other words, we have a service, and a server, that voluntarily wants to interpose an intermediate proxy to learn less information about the user, or, more precisely, not to learn their IP addres…

Yesterday we unfortunately focused so much time on discovery that I fear 
we largely lost track of other issues.  ohttp isn't much more than a 
packet format and media type and some crypto goo.  The issue is really 
in the applications above it.  How we handle those applications becomes, 
I think, a question.  I have no particular concern with telemetry and 
even safe browsing.  I remain concerned about DNS, in that it will 
become a nightmare to shutdown C&C networks and defend against other 
forms of attack.

I think this opens up a question, tho, and maybe an issue:

Should there be media subtypes to define the applications?  I see that 
as a good question for a WG to consider.

Eliot

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 30 Jul 2021 10:44:31 +1000

> How about obfuscated HTTP?

Obfuscation is not the goal at all though.  We are deliberately making use of the mechanism comprehensible.

Obfuscation is also weaker than what this provides, which is encryption.

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 30 Jul 2021 10:48:57 +1000

> as a good question for a WG to consider.

Please open an issue.  This is a reasonable discussion to start, in the spirit of RFC 8558.  I don't see any purpose for such a signal, but if someone can make a case, we could provide a signal.  Note that in many cases the purpose of the exchange is tied to the identity of the resources involved (at either proxy or server), so there is no secrecy requirement for this particular information in those cases.