Re: [Ohttp] Feedback on draft-thomson-http-oblivious-01 (and proposed charter)

[Martin Thomson <[e-mail]>]

Thanks for the feedback Mark.

The scope question is an interesting one to contemplate.  I have modest ambitions for this work, but that doesn't mean I'm opposed to accommodating reasonable and achievable goals that do not require major surgery.

On Wed, Jun 16, 2021, at 11:10, Mark Nottingham wrote:
> Some applications might reasonably require that controlled forms of 
> statefulness be allowed, while removing IP addresses and TLS session 
> state as a means of linkage. For example, both Apple (with their newly 
> introduced 'Private Relay') and Google (with their 'Gnatcatcher' item 
> in the Privacy Sandbox) seem to be working in areas that might 
> eventually have these requirements. 

I don't think that this is aiming for similar outcomes.  This is where my main reservations about this come from (and likely those of other concerned citizens).  The use case that Apple's Private Relay is aimed at does lend itself more to the sort of proxying they currently do.  Gnatcatcher is aiming for a much cheaper solution, but with similarly low ambitions about what guarantees it can provide for privacy.

The main advantage of this sort of design is in the low initial latency, but that comes at a significant cost.  There is added crypto, yes, but the main concern is the anti-replay machinery.  Tunneling might pay a round trip for setup, but it means that you don't have to carefully analyze every request for safety.

That isn't to say that there isn't some value in looking to tightly control how information transfers between requests.  If we could be sure that the only linkage between requests is stuff that was deliberately added (if it must be cookies, so be it), that might make privacy analysis much easier.

As an aside, one of my colleagues is currently attempting to build out a formal model for browser privacy.  This is a serious undertaking where having tight bounds could helped a lot.  But that's not really how the web works :)
 
> So, I think we should have a discussion of scope and requirements, to 
> make sure this is not too narrowly defined. What's preventing broader 
> use is, AIUI:

Generality is a reasonable goal.  It seems like your concern is the ability to split requests and responses into units that can be incrementally processed.  We didn't have a need for that, so we didn't put it in, but it should be fairly simple to build something.

That might involve multiple invocations of Seal() on the request end and something with nonces and counters on the response end.  Then we need to add a way to indicate where chunks start and end, plus a way to know when the sequence is complete.  Nothing I haven't done before and not necessarily that much of a burden on implementations.
 
> 3) The crypto may be too heavyweight for high-volume uses (such as Web 
> browsing). Fixing that might take a fair amount of work.

This is a different problem; but yes, this is not something that is likely to get easier, except by making computers faster.  The need for PQ crypto will set that back further, of course.
 
> ## Use of HTTP

Yep, let's at least get the HTTP WG input on this.

> ## Venue
> Some people have asked whether this work could take place in the HTTP 
> WG (and some were surprised it hasn't been brought up substantially 
> there, although Martin did forward the draft at one point). 

This was discussed in the HTTP WG, but I know that some people noted surprise at the outcome.  Of course, the SECDISPATCH session was well publicized, so it's not like the opportunity was not there, even if it was dreadfully inconvenient.

The thinking at the time was that this was worth doing separately for the security implications.  But then HTTP are doing the signatures thing, so precedent goes the other way.  And it ended up in ART (for reasons not clear to me).  

Ultimately, I just want the work done.  Whether this is a new group or an existing one is one I will leave to our area directors.  I will take this work to HTTP if that is the best place to go.

> Also, the document references draft-ietf-http-binary-message (I think 
> this should be draft-thomson-http-binary-message). I won't give 
> feedback here, but it should go before the HTTP WG, and ideally be 
> adopted there. I *think* that's the intent based upon the contents of 
> the draft, but it isn't clear.

My bad on the name (don't know how that happened; fixed in source).  My original intent was that this all go to HTTP (hence the names), but I was convinced that it needed to be DISPATCHed and that process is how we got here.
 
> Taking all of the above into account, I think this work needs a BoF -- 
> primarily to discuss scoping issues. 

I'm going to disagree here.  That's asking for a reset.  I have no problem trying to get more clarity on use cases, but most of the discussion so far has been about addressing concerns that are clearly out of scope.  I don't want to see a BoF wasted on discussing whether some hypothetical protocol might be used to centralize some undefined thing.  I've sat through enough of that already to know that there is no satisfactory answer to any of that.

Your request for HTTP-specific generality is a good one, but well within the remit of a working group to answer.