[Ohttp] A few responses

[Martin Thomson <[e-mail]>]

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.