Re: FYI: Oblivious HTTP

Thanks Toerless,

Brief responses only.

On Fri, Jan 29, 2021, at 04:54, Toerless Eckert wrote:
> a) "oblivious" (non-technical comment)

The choice of naming is a nod of acknowledgment to the original work <https://dl.acm.org/doi/abs/10.1145/3340301.3341128>.  It's not perfect, but it is also fairly well understood what it means in context even if that doesn't correspond very well with the English definition.

> The real value proposition seems to be performance of what i would describe
> as HTTP transaction routing in this solution vs. single-transaction
> connection setup through proxies. Correct ?

Yes.  The key observation here is that achieving these privacy properties can be made faster than making a fresh, proxied  connection for every request.  If you are looking for an idea of the performance, Cloudflare did some research on a very similar mechanism: <https://blog.cloudflare.com/oblivious-dns/>

> Also of course and i think quite importantly: How big would the difference
> still be if HTTPs (with TLS) was replaced by QUIC - which i think values itself
> for minimizing rtts/messages.

QUIC is better than TCP (which is why it exists), but the crypto costs are the same and it can't do this without adding round trips.
 
> Is it possible to have two or more proxy resources ? 

Yes, this can be applied iteratively.  If you like, you could re-build something akin to Tor based on the underlying mechanisms, but that requires a whole lot more stuff than this.  It would also throw up a whole bunch of new problems.  I'll leave that to others to contemplate.

> It seems to me as if the mechanism at its core is really a new brand
> of transaction routing based on URL for rquest and HPKE context for reply
> if i understand right. I wonder why this is being defined only for HTTP.

Nothing wrong with using this template to build a similar mechanism for another protocol, but I don't believe that there is value in taking generalization that far.  It shouldn't be hard to write an adaptation to Diameter or whatever protocol you had in mind if that is your inclination.  But that would require use cases that depended on those protocols and I am not in a position to know whether those use cases exist.  I can only say that I have a use case that would benefit from carrying HTTP exchanges.

Received on Thursday, 28 January 2021 22:38:53 UTC