Re: Alt-Svc: alternatives assigned by alternatives

On Tue, Aug 19, 2014 at 3:39 AM, Mark Nottingham <mnot@mnot.net> wrote:

> Thinking a bit more about Alt-Svc, I'd like to see more clarity around
> when and how it's OK to cache (and later use) an alternative service you
> discover.
>
> 1) You get an alt-svc (frame or header) from an origin
> 2) You get an alt-svc (frame or header) from an alternative service
> [..]
> If not, I think we need to limit #2 in some fashion. What I'd propose is
> that when you learn about an alternative from an origin, its freshness
> lifetime cannot exceed the original provided by the origin. That is, in the
> scenario above, other.example.net would only be valid for the original
> 60s period, regardless of what it tried to update; it could redirect
> traffic to another alternative during that 60s window, but not beyond it.
>

I don't think we need this. Both hosts are the same origin (I enjoyed the
term original origin), just hosted at different locations - alt-svc is a
novel way for directing and choosing the next-protocol to use when talking
to one of those. They're just CNAMEs with a alpn token, right? And if they
are both trusted then there isn't a logical difference in who can update
the ttl. Its even plausible that the set of hosts that make up the origin
are all configured exactly the same - i.e. unaware of which is the original
origin.

I think the strongest argument in favor of scoping who can update a alt-svc
is that a MITM attacker can attack you once and then capture your traffic
in perpetuity without having to perform another attack against the original
origin by updating the value.

But the proposed mitigation doesn't solve that - it just means the original
attack needs to insert a ma=1year header to set a max-age so large that
the effect is the same.

So I favor allowing any host authoritative for a transaction to also update
the corresponding alt-svc value.

-P