Re: Alt-Svc: alternatives assigned by alternatives

OK. The one thing that gave me pause was that if I alt-svc to another domain even briefly, I'm giving it "ownership" of that client, potentially in perpetuity.

OTOH, if it's on a different host, they'll also need to have a valid cert for my origin, and that has its own set of checks and balances.

Cheers,


 
On 19 Aug 2014, at 11:37 pm, Patrick McManus <mcmanus@ducksong.com> wrote:

> 
> 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
> 
> 
> 
> 

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

Received on Tuesday, 19 August 2014 23:44:16 UTC