Re: FYI: Oblivious HTTP

On Fri, Jan 29, 2021 at 09:38:19AM +1100, Martin Thomson wrote:
> 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.

Sure. write that into the intro of your doc to motivate the choice of name.

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

Add as reference.

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

Some summary of example performance comparison of the proposed mechanism
vs. those alternatives in the document itself will be appreciated. I for
once can probably figure  out myself the difference in packet/rtt overhead
but i am less knowledgabe about the crypto difference.

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

Hmm. Are there fundamental additional complexities doing multiple
proxy hops in your mechanism vs. those in Thor ? Would be good
to understand/document in the draft anything novel, even if its not positive...

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

Definitely required to show use-cases before thinking about codying anything
more generic. I was just trying to understand better what is and what is
not HTTP specific in the proposal. Somewhat hard to figure out from the
text now.

Thanks for explaining!

Cheers
    Toerless

Received on Friday, 29 January 2021 12:58:02 UTC