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

[Mark Nottingham <[e-mail]>]

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/