W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

Re: draft-nottingham-httpbis-origin-frame

From: Patrick McManus <pmcmanus@mozilla.com>
Date: Wed, 16 Mar 2016 14:35:56 -0400
Message-ID: <CAOdDvNoSUd4TNjfJOUSrREQvdBG1rxufTpE0gawwmE5aT_8V_w@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Patrick McManus <pmcmanus@mozilla.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Mar 14, 2016 at 6:59 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

>
> It's a small concern, because I think that the risk is small in
> comparison to the potential gain, but I don't think that this is
> something that we can reasonably ignore.



[until we adopt a draft this is all just kick-the-ball-around stuff]

fwiw, there is a spectrum of ways to interpret the 7540 rules that a
declarative origin frame could help with. in 7540 coalescing Firefox goes a
little towards the aggressive side in order to enable coalescing on a
couple of content providers that want coalescing but don't always advertise
consistent DNS views. This has caught a couple other providers by surprise
who saw coalescing but did not expect it in an edge case (I get to explain
421 to them :)) - an origin extension that opts in arbitrary origins
provides a more deterministic implementation.

I would want to address the change with strong text to make this clear
(something I think, only in retrospect, that 7540 could have done stronger
around coalescing rules there.) but as a practical matter the internet is
moving away from addressing defining content and this just rides that wave.
and sure, content-centric or named-data networking lies somewhere on that
road. But its too far away to see clearly :)

Names are what identify content and signatures are what makes you believe
it. The notion of DNS resolution and IP routes being directly tied to this
is already long gone and folks depending on that are probably in grave
peril already (i.e. http://). Which is why we already don't rely on it in
https://. And if you are faced with a certificate compromise, relying on
routing to save you is pretty weak solace.

When I click on my search provider button maybe I am routed to
searchProvider's data center.. but maybe I'm routed to a CDN, or maybe
dynamically load shifted to a fail over CDN the way CDNI talks about..
perhaps it changes every 300 seconds. maybe I'm served out of a cache
(perhaps local, perhaps remote) or directed to an alternate service.. maybe
my route is hijacked L4 style by a transparent device that lies about the
addressing. Perhaps I'm behind a nat. Or two. Or three. Or have had my DNS
spoofed via race condition. Or routed via an onion network or plain old
vpn. In all of those cases the decision on whether or not to use the
content is independent of addressing and routing - a declarative origin
frame isn't moving into uncharted territory.

Those addresses and routes are just the ephemeral glue we use to get you to
the content you want - the content doesn't inherently possess addresses or
routes.. if another set of addresses and routes delivers the same
verifiable content in a better way thats a good thing and loosening the
implicit dependence on DNS and IP is also good thing.

-Patrick
Received on Wednesday, 16 March 2016 18:36:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:11 UTC