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

From: Mark Nottingham <[email-masked]>
Date: Wed, 16 Jun 2021 11:10:33 +1000

Hello, 

Overall, I think this is an important area for the IETF to be working in, and this document is a potentially good starting point for that work. 

However, I think there are a few things that need to be discussed before it commences. 

## Scope

The biggest question I have around this work is the proposed scope of applicability. Section 3.1 claims a very modest one, and yet the protocol is named 'Oblivious HTTP', which implies a very wide scope; roughly, 'HTTP + the "oblivious" property'. 

This modesty shows in statements like 'Oblivious HTTP seeks to prevent this sort of linkage, which requires that applications not carry state between requests.' 

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. 

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:

1) The current proposal doesn't allow non-final messages. This effectively profiles the use of HTTP, and fixing it wouldn't add a tremendous amount of complexity.

2) AIUI the protocol does not allow streaming, thanks to the single call to Seal(). This severely limits its applicability (If I'm incorrect I'd love to hear it; Chris and Martin are far more crypto-capable than I), and should be relatively easy to fix.

3) The crypto may be too heavyweight for high-volume uses (such as Web browsing). Fixing that might take a fair amount of work.

I understand the authors might want to constrain the scope of work to make the group's task more achievable. Arguably, however, the few extra steps needed would create a more capable, widely usable protocol. Also, it would be unfortunate if this protocol got wider use and effectively profiled the use of HTTP (e.g., by disallowing 1xx responses), thereby causing interoperability issues for the whole HTTP ecosystem.

To put it another way - anything calling itself "* HTTP" needs to maintain fidelity to the *complete* contents of draft-ietf-httpbis-semantics and common uses of HTTP. If it makes sense to do something more limited, that's great -- but we should come to that decision consciously, and the result shouldn't be called "HTTP."

## Use of HTTP

This draft models an intermediary as a resource that clients POST messages to. That's a significant break from HTTP's intermediation model, and should be discussed in the HTTP WG. It may be that a method would be more appropriate, or an adjustment to terminology might be sufficient.

Again, this doesn't need to be decided before chartering, but it needs to be agreed that this is an issue that requires discussion.

## Venue

AIUI this work was discussed in SECDISPATCH, and the ADs have started to form a WG based upon a successful discussion there. However, it has not been discussed in either HTTP or DISPATCH, and I think it needs to be. Once again, I ask the ADs to *actively* coordinate when work has cross-area implications -- especially when meetings are happening at 4am for some people. Not everyone goes to all of the various DISPATCH meetings, and I become more convinced that having multiple DISPATCHes is counter-productive.

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). I think that this work *could* succeed in the HTTP WG, but if the crypto gets involved (e.g., addressing my issue #3 above), it probably should be separate. If that's what happens, it would be good if the charter were more fulsome in its description of the relationship to HTTP; it's not just a 'tool[] that OHTTP depends on', it's the existing, widely deployed protocol being extended with a new transport and a new intermediation mechanism. As such, I'd expect a very close relationship with the HTTP community.

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.

Taking all of the above into account, I think this work needs a BoF -- primarily to discuss scoping issues. Again, I think it's an important and relevant are for us to work in, but we need to get the details right before we start.

Cheers,

P.S. The text 'oblivious HTTP is more expensive than a direct request [because] Each oblivious request requires at least two regular HTTP requests, which adds latency' is odd - what is this extra request? 

--
Mark Nottingham   https://www.mnot.net/

---

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

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.