Subject: [Ohttp] A few responses

From: "Martin Thomson" <[email-masked]>
Date: Tue, 15 Jun 2021 12:02:31 +1000

For some reason, I missed the creation of this list, so I can't reply directly.  I do think it worthwhile to respond to a few comments.

Eliot asks:

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

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.

Michael says:

> You have two proxies here.
> I didn't think that the oblivious HTTP mandated two.

There are logically two intermediaries here: one to forward encrypted messages, one to unwrap and wrap plaintext messages.  So yes, two proxies.

Deployments we are considering will likely collapse the decryption piece with the thing that serves the response.  That keeps the crypto on endpoints with just a single intermediary.  That is, the following are equivalent in that deployment model.

client -> add encryption -> proxy -> remove encryption -> server
===
client (adds encryption) -> proxy -> server (removes encryption)

Noting that the end-to-end argument supports the view that encryption is an endpoint responsibility, the protocol distinguishes between the two functions at the server because we want to protect the complete request.  That includes the URI.  The thing that removes the encryption on the server side can - at least in theory - send the unprotected request somewhere else.

Vittorio asks:

> If the same entity controls the proxy and the target, what's the actual gain in privacy?

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.

Though I want to caveat that.  End-to-end encryption is not considered as theatre, but when you get right down to it, at least in most systems I've seen, the same entity controls the software on endpoints and the servers.  There is value to the operational and organizational controls that are used to ensure that cleartext data doesn't cross into places it should not be.  That's a digression, but I'm happy to talk (maybe in a more appropriate forum) about the ways in which an organization's internal procedures are more relevant to security than some perceived independence.

Vittorio also speculates:

> ... we end up with very few global providers managing the proxy layer ...

I think that sort of speculation falls firmly in the FUD category.  Yes, it is fair to consider the implications of what we build, but even those of us building this don't have enough information about how this might turn out.  If you want to lay out a more detailed argument where you more carefully identify your assumptions, that might be a valuable contribution.

Broadly speaking, the sort of work we do here has the sorts of risks you identify.  These are the constant responsibility of all of us.  However, when speaking of generalities, those are the subject of the mission of the organization, not the charter of individual groups.  Insisting that we consider the complete suite of possible apocalyptic scenarios only leads to nothing happening.

I'm not opposed to saying good things about important issues.  If you have specific text changes to provide, that would be helpful.

> there are sources that need to be recognized (e.g. bots) and destinations to be blocked permanently (e.g. illegal content) or depending on who the user is (e.g. parental controls)

You might need to say more about who you believe is acting in each of these cases.  

I get the bot example, but that can be accommodated by not using ohttp if necessary.  Or by using something other than IP (which might be better anyway).  Why would someone deploy a protocol that prevents them from accessing information they believe to be critical?

Lars says:
> IP address

The friendly amendments there are good.  I was using the QUIC understand of "address", which includes the source IP and port.  The port could be important here for a range of reasons, but I don't see any need to encode that in charter text.

[1] Using DNS here deliberately.  Not DoH/DoT.  The encrypted versions tend to attract the heat for this, but it is the DNS protocol that enabled it, encryption only hid it.  ODNS showed us how to hide it without DoH/DoT.

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 15 Jun 2021 14:35:14 +0200 (CEST)

Hello Martin,

Thanks for responding - I'm also separating my part of the thread.

> Il 15/06/2021 04:02 Martin Thomson <[email-masked]> ha scritto:
> 
> Vittorio asks:
> 
> I don't think that anyone is considering these two resources being operated by the same entity.

I was actually responding to someone else who had just made that assumption :-)

> I think that sort of speculation falls firmly in the FUD category.  Yes, it is fair to consider the implications of what we build, but even those of us building this don't have enough information about how this might turn out.  

I don't think this is FUD. Indeed, it is speculation - if this work succeeds and gets broadly implemented, it may or may not happen. However, I think that we have all seen sufficient cases of centralization in sibling situations (DNS resolution, CDNs, whatever) to think that such an outcome is at least possible, perhaps likely. So I think that we should consider the possible implications on Internet centralization from the start, exactly like we need to consider security and privacy impacts.

> I'm not opposed to saying good things about important issues.  If you have specific text changes to provide, that would be helpful.

Understood. Let me give a thought at this.

> I get the bot example, but that can be accommodated by not using ohttp if necessary.  Or by using something other than IP (which might be better anyway).  Why would someone deploy a protocol that p…

Again, this depends on deployment models. Would OHTTP proxies be anonymously available to the general public, or would they require user authentication before use, or be restricted to traffic from specific networks, or specific devices, etc? If I get it well, some of these models, as Eliot also pointed out, would allow any botnet author, spammer or whatever to use open OHTTP proxies to hide the origin of their abusive traffic, and even the proxy operator would have a hard time distinguishing that traffic from the legitimate one, as they don't have a way to know what is being requested. As a minimum, I'd think that a new standard should include deployment recommendations to prevent the worst scenarios from happening, or explanations of why those scenarios are unlikely or unattractive for abusers.

More generally, I'm not against this idea but I think it could have significant unintended consequences. I think it's fair to ask that, differently from what happened with DoH, all the foreseeable consequences are collectively discussed and understood before finalizing the standards, so that no parts of the Internet community are taken by surprise.

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

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 16 Jun 2021 09:44:41 +1000

On Tue, Jun 15, 2021, at 22:35, Vittorio Bertola wrote:
> I think that we should consider the possible implications on Internet 
> centralization from the start, exactly like we need to consider 
> security and privacy impacts.

This I agree with.  We are collectively still grappling with just what it means to consider these issues, so maybe a little more deliberate effort is needed in new efforts to engage with the topic.  I just don't know how to turn that into something actionable.

It's not through lack of trying either.  The IAB spent a lot of time on the subject in the 4 years I was there and have done since.  We have no shared understanding of the subject and so no concrete advice to give.  We just have a general sense that consolidation is bad.  Maybe that is limited to when centralization leads to single points of failure or control.

We don't know what leads to centralization and - in particular - what protocol designs might to do influence it.  I've heard it said that DoH has worsened centralization, but I don't think that question is settled either.  What is natural forces of market pressure and what the protocol enabled are hard to disentangle.

For DoH, I don't know if we could have done anything different then, even with this foreknowledge, except to the extent that we would have tried harder to engage with those who might be affected.

And just to make it clear, I don't think that the parallels with DoH and this work that are being drawn are quite right either.  Part of the reason I am engaging with this work is that it helps a major privacy problem with DNS centralization problem: the aggregation of profiles at DNS resolvers.

All that said, I'm no richer in terms of knowing what to write in a charter on the subject.

> Again, this depends on deployment models. Would OHTTP proxies be 
> anonymously available to the general public, or would they require user 
> authentication before use, or be restricted to traffic from specific 
> networks, or specific devices, etc? 

No deployment model that has been suggested to me involves any anonymous, general purpose, and open proxy.  Indeed, as I mentioned to Eliot, the protocol as proposed cannot be used for general purpose use cases.  You might define some sort of extension for that purpose, of course.

> [...] a new standard should include deployment recommendations to 
> prevent the worst scenarios from happening, or explanations of why 
> those scenarios are unlikely or unattractive for abusers.

This is a reasonable request; FWIW, I've opened an issue on this.  We have some of this text already, but maybe not as comprehensive as you might like.