Subject: Alt-Svc: alternatives assigned by alternatives

From: Mark Nottingham <[email-masked]>
Date: Tue, 19 Aug 2014 17:39:56 +1000

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.

Right now, there are two scenarios:

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

#1 is pretty straightforward.

#2 is implicitly allowed by the spec in one or two places, for very reasonable purposes; if you're doing load balancing (one of the primary use cases), you need to be able to shift traffic around more than once. Likewise, if you're using Alt-Svc for Opp-Sec, you might need to do some load balancing after that.

However, that implies that an alternative service can refresh itself, indefinitely. 

E.g., imagine an origin request to <https://example.com/> that bounces the client to (h2, other.example.net, 443) with a lifetime of 60s. 

After 50s, if the other.example.net sends an ALTSVC frame updating the alt-svc cache to point to itself for another 60s (or hour, or day, or year), is it OK with folks for the client to continue using other.example.net for the (https, example.com, 443) origin for that period of time, without contacting the original origin?

If so, no worries.

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 think that would work reasonably well with the use cases we have in mind;

a) for Opp-Sec, you'd use a fairly (to very) long lifetime for the initial upgrade, giving plenty of leeway for future load shifting, etc.

b) for load balancing, you'd probably have a fairly short lifetime, but you'd just be checking back with the origin each time load balancing happened, and you could always assign a longer initial lifetime if this was a concern.

What do people think?

Regardless, I'd like to see #2 more clearly stated in the spec.

Cheers,

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

---

From: Patrick McManus <[email-masked]>
Date: Tue, 19 Aug 2014 09:37:26 -0400

On Tue, Aug 19, 2014 at 3:39 AM, Mark Nottingham <[email-masked]> 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.
>
> [..]
> 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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 19 Aug 2014 10:32:52 -0700

On 19 August 2014 06:37, Patrick McManus <[email-masked]> wrote:
> 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

I think that we have a good way out on that.
http://http2.github.io/http2-spec/alt-svc.html#caching says to
re-examine alternative services when you change network attachment.
That avoids the most egregious attacks.

I'll note that in general, once an origin is poisoned, that isn't
something that can be recovered easily anyway.  Caching lifetimes are
quite long, and other persistent storage is basically never removed.
So if you are concerned about a one time breach causing long-term
damage, that's already a state that we have to deal with.  Not that
that is a particularly gratifying argument, but it might put the
problem into perspective.

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

I think that this is the right answer.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 20 Aug 2014 09:43:49 +1000

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 <[email-masked]> wrote:

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