Re: FYI: Oblivious HTTP

["Roy T. Fielding" <[e-mail]>]

> On Jan 27, 2021, at 5:27 PM, Martin Thomson <[e-mail]> wrote:
> 
> Just an announcement for a new draft that proposes a use of HTTP that this group might be interested in.  I've started a discussion on the SECDISPATCH list about it [1].  Please, if you are interested in this topic, join that conversation.
> 
> The draft:
> 
> https://www.ietf.org/archive/id/draft-thomson-http-oblivious-00.html
> 
> What this group might be more interested in is whether the ecosystem is well-served by a binary message format.  That work currently has a dependency on another proposal:
> 
> https://www.ietf.org/archive/id/draft-thomson-http-binary-message-00.html
> 
> It doesn't strictly need to take this dependency, as message/http is in some ways adequate.  However, I think that it might be beneficial to have a discussion about this idea here.
> 
> Cheers,
> Martin
> 
> [1] https://mailarchive.ietf.org/arch/msg/secdispatch/VmFQCZGKlukgfnmgPh8ufQt_5Fo/

Personally, I think we have passed the inflection point where anonymous use
of the Internet is an ideal, and we are quickly heading back to a world where
accountability for its misuse is just as important. But that's a digression.

Technically, I don't feel that wrapping base HTTP semantics as an encrypted
package containing a binary encoding of HTTP/1, and then using POST to fling
it around the world, is the right approach. I could understand that if the primary
motivation was to pass through client-selected proxies without using TLS,
or if the client engine was limited to javascript on a page, but not if we assume
the client is deliberately coding for this protocol and servers are deliberately
willing to accept such requests. POST is significantly harder to process than
it looks.

I suggest that it would be better to design a protocol that accomplishes exactly
what you want in the most efficient way possible and find ways to blend that
with the existing HTTPs. For example, using non-https link alternatives and
Alt-Svc to identify oblivious resources. Using QUIC datagrams for sending
opaque requests (I don't see a need to send these as HTTP/3) and receiving
opaque responses. Mapping to other protocols only as a way of supporting
backwards deployment over those old protocols.

OTOH, oblivious connections will mislead if there are no equivalent constraints
on what the client can do/enable with the content received. Almost all tracking
today is done based on client behavior after receipt of the primary resource,
including what is executed within the page, how the page components are
ordered, what needs to be refreshed, links to other pages, what servers
might share the same TLS certificate, etc. Relying on clients to restrain
themselves doesn't work in practice, even though it should work in theory.

As such, I think systems like TOR that are built on trust and actively mediate
and adapt to changing malpractice is a better solution. But don't let that stop you
from designing something better.

....Roy