Alt-Svc Feedback

I recently got our dev team together for a fresh read-through of the Alt-Svc draft, so we could get our feedback in before WGLC....  There's minor stuff that I suspect is semi-editorial - I'll directly open either issues or pull requests for those - but these are the items that seem to have a little more meat for list discussion.


*         Persistence of alternates across network changes.  Alternates provided because of location (seattle.edge.net vs. sfc.edge.net) will need to be cleared on network changes.  (They're probably direct pointers to individual nodes/datacenters.)  Alternates provided because of capabilities (sni.edge.net as alternate of legacy.edge.net) shouldn't be cleared on network changes, because they're not location-dependent.  (The names probably resolve to different IPs based on location at the DNS level.)  Should there be a hint to the client that a particular alternate does/doesn't need to be flushed on changes?  Might impact the issues described in 9.2, but TLS should still mitigate.

*         Conflicts between Alt-Svc and ALPN.  Alt-Svc tells me to use h2, so I open a TLS connection, and the server either doesn't support ALPN or doesn't select h2.  What now?  Weird corner cases ensue where I'm connected to something that may or may not be the alternate I was intending to reach.  Simpler to just say TLS is the protocol and require ALPN support in 2.3 as well.

*         Elevation of privilege.  Someone who controls any resource on an origin can issue directives that affect all resources on that origin.  (Thinking of the server the CS/CE students could work with in college, where we all had pages at server.example.edu/~username.)  Sure, I can't change the host because I don't have the server cert, but I can change ports without that requirement.  The guidance in 9.1 just says "don't let people do that," which is easier said than done on systems that already exist.  If we implement, we'll probably apply the strong-auth requirement to changes of port as well, and we encourage the spec to require likewise.

*         Servers with in-memory state.  We've seen real-world bugs where simultaneously routing connections to two different back-end servers breaks the site because some of the client's state is in-memory only and depending on the load balancer to bring all client requests to that server.  While it's a bad service design, it makes us hesitant to switch to an Alt-Svc during an ongoing session.

*         Alternates of alternates.  When the origin delegates to an alternate for 30 seconds, and the alternate delegates somewhere else (or to itself) for 7 days, how long does the client keep it?  30 seconds because that's what the origin said, or 7 days because the alternate is supposed to be equivalent in authority to the origin?

*         Endlessly repeating headers.  The ALTSVC frame can be sent once and the client either parses it or doesn't.  Servers shouldn't blindly throw the header on every response either, though - it's just a waste of bandwidth.  After the first response on a connection (or 2, or 5) the client has clearly either chosen to ignore it or doesn't understand it.  Should we have guidance to stop sending it?

*         Alt-Svc on 421.  Spec explicitly allows this, but why?  The alternate is allowed to issue Alt-Svc because it's authoritative for the origin, but 421 declares that it is not authoritative for the origin (or at least the resource).  These can't both be true.

*         Insufficiency of name matches for strong auth.  If http://www.example.com sends Alt-Svc pointing to evil.haxor.bg showing a cert from a hacked CA for the right origin, we don't want to trust it.  This led to a discussion of cert pinning, what cert pinning means for a resource that started as http://, and a general lamentation of how broken PKI is.  If nothing else, we would probably require alternates of https:// origins to present exactly the same certificate (or perhaps one from the same issuer) before we trust them.  Name matches aren't always enough.  However, that scenario looks a lot like 9.2 again for http:// origins - if you're MITM'd once, you can be MITM'd for as long as you trust the fishy cert.