martinthomson/alt-svcb

HTTP Alternative Services, Plan B

HTTP Alternative Services, Plan B

This is the working area for the individual Internet-Draft, "HTTP Alternative Services, Plan B".

• Editor's Copy
• Datatracker Page
• Individual Draft
• Compare Editor's Copy to Individual Draft

Contributing

See the guidelines for contributions.

Contributions can be made by creating pull requests. The GitHub interface supports creating pull requests using the Edit (✏) button.

Command Line Usage

Formatted text and HTML versions of the draft can be built using make.

$ make

Command line usage requires that you have the necessary software installed. See the instructions.

alt-svcb's Issues

Tracking

This should be easy to address. We don't need anything like as fancy as RFC 7838. We just need to nod toward resumption and other state that might be used in making new connections. This only applies to the reuse case as well.

SvcB-Used Signal

For use-cases where this is trying to do load balancing (a major use-case), cluster load balancers are going to need to know which SVCB record was used for a given TLS connection. Today many load balancers do this by looking at SNI, but since this doesn't change the SNI that won't be available.

The gross solution (not requiring protocol changes) would be to embed information in the ECH Key-ID (eg, having a different ECH per SVCB record), but this defeats a bunch of the benefit of ECH and leaks information to the network. Embedding information in IPv6 addresses would also work, but again leaks information to the network.

An alternative would be to have a new SvcParam for a SVCB identifier (eg, id=$token) and then to have a TLS ClientHello extension for SvcB-Used that passes along $token from the SVCB record used to make the connection. I'd propose that this SvcB-Used extension only be sent in an Inner ClientHello and only when ECH is in-use. That would both encourage ECH usage and also avoid leaking this information to the network.

A question would be what size to make $token. Given that more abusive hacks could easily already smuggle 64+ bits (through IPv6 as an example) that might be a reasonable starting point.

This does create linkability between the DNS lookup and the TLS connection, but there are other ways to do that for a malicious actor who controls both endpoints. A goal would be to make it so that the network / a third-party adversary can't do this linkability.

Clearing client state explicitly

How does a server explicitly clear client state?

1. Send a name that doesn't resolve. This will fail and state will be cleared. "invalid" is a TLD that never resolves...
2. Send the origin name.

Option 1?

Header and frame offer different multiplicity

The header allows an arbitrary number of alternativess per request. The frame only allows one alternative per origin (and only the last one). I don't see much technical reason for this asymmetry. It could be easily resolved by changing one of them (e.g. allowing the frame to carry a comma-separated list of values). Failing that, we could explain why they are different a bit more.

Naming consistency

From Ryan Hamilton:

There are potentially 3 different "hostnames" (servers) involved in
this protocol: The origin (from the URL), the alternative name (from
the Alt-SvcB header), and the service (from the HTTPS RR). I think it
would be a good idea to use these terms more broadly instead of
"server" seems more ambiguous.

Overall, we could be more consistent in our use of names. We might need to define terms for these, perhaps:

• origin name: the name of the logical server from the URL
• alternative name: the name from Alt-SvcB/ALTSVCB
• service name: the TargetName from a HTTPS ServiceMode record

Then also check that we correctly use "server" and "server instance" throughout.

Both a priority override and alt-only?

Right now, we have two interrelated mechanisms that can be used to ensure that an alternative service is used:

1. If the service name is present in an RRset, then it is chosen, no matter its priority. This allows low priority entries to jump to the top.
2. If an RR is marked alt-only, it can be pushed right to the top with SvcPriority higher than unmarked RRs. This allows alternative services to be put at the top in terms of priority, without them being used under ordinary conditions.

It's possible that either approach would work. Are there deployment scenarios that push specifically toward one or other approach such that we might need both? Or, can we remove one of these?

Obviously the alt-only thing has more "stuff" associated with it, which might make it more attractive to remove, but it might also be the more powerful of the two. For this, my guess is that we need to collect input from people who are looking to deploy this.

Security requires True Alternatives

From last week's meeting: Security Considerations needs to call out that all endpoints must actually return the same content; different content per endpoint will break many things.

Endless alternatives

This design can result in clients following an indefinite chain of alternatives. Talk about how to manage this.

Proxy requirements

From @LPardue:

The proxy constraints seem a bit too strict. It doesn't seem that much harder to extend or emulate Tommy's dns-proxy-status to return the HTTPS information that would be needed for a client to perform the same verification that the non-proxied flow needs. This proposal actually offers the possibility to make HTTP/3 over MASQUE client behaviour a little more standard. This might work well in coordination with a preflight as suggested above.

HTTPS only

Using HTTPS records means we're leaving cleartext HTTP in the lurch. Be explicit about that.

Enumerating all server instances

The current design more or less requires that the DNS contain a complete enumeration of all possible server instances. This is not great:

1. Because it is hard to get a good picture of all services in this fashion.
2. Because a server operator might not want to publish a complete map of its servers.
3. Because DNS responses might get unwieldy.

Path and Object based Alt-SvcB

(This is speculative and may be more complexity than is worth it...)

One use-case that lacks good solutions today is to be able to have objects of different popularity on different clusters of servers. For example, serve popular objects from near end-users but serve the long-tail centrally. If Alt-SvcB could solve this problem, it might make it much more compelling to implement. This is especially becoming important in the world where everything is HTTPS and where there's a trend to consolidate onto a smaller number of Web Origin hostnames. Another goal is to minimize leakage of information to observers on the network about which objects are being requested.

In "the old world" a common way to solve this would be to have a bunch of hostnames, perhaps a hostname per object, under the same domain. 302 redirects would then be used to direct particular objects to a particular hostname. Cookies (eg, for auth tokens) might be set on wildcard domain. This requires a wildcard cert (or cert per hostname) and leaks information to the network via SNI about what objects are being requested. It also results in application-level visibility into traffic routing since the 302 redirects are changing the Origin of objects, so it can't happen transparently.

Being able to use Alt-SvcB for this would solve a bunch of issues. What this might look like might be:

1. Alt-SvcB can be path (or even object) scoped. For example, a path= attribute on the response header.
2. A way to indicate a synchronous behavior is desired (eg, a 3xx response code that means "go use Alt-SvcB now"). This would need a way for client to know that they support this (eg, a request header or setting) as well as some logic to prevent loops.
3. A way to indicate which SvcB is being used (eg, a SvcB-Used TLS extension such as in #27 ?) or a request header? This would need to coordinate with the above point. Using a TLS extension in an ECH Client Hello would leak the least to the network and would also enable in-cluster load balancers to do the right thing.

This would allow selecting different servers (whether different clusters or different servers in a cluster) for selected objects/paths without changing the Origin and also while potentially reducing how much is leaked to the network.

Abstract

Write one.

HTTP/3 example

From Ryan Hamilton:

It would be great to see an example of using Alt-SvcB to switch to
H3 since that's currently the main use of Alt-Svc in the wild.

It should be possible to have the alternatives in the existing example list "h3".

DNS vulnerabilities

We're more exposed to DNS problems with this design, but that is also deliberate. Be sure to acknowledge this, maybe even point to DNSSEC. Then, be sure to say that this doesn't really change things from ordinary HTTP, where the DNS is able to deny service or route clients to a server instance of their choosing. The defenses here are relying on TLS for authority, which also includes protocol choice. The choice of port remains something that an attacker can choose, without protection, but that is still a problem even without this design.

SVCB-reliant

The draft currently says that looking up an alternative is done as SVCB-reliant (HTTPS is otherwise defined to be SVCB-optional). Double-check that this is what we want. It probably is, but let's be sure.

IP Addresses

What if a server wants to direct to an IP? How do we accommodate that?

Oversimplified ideas

This draft serves a few different use cases, including load shedding but also latency optimization, etc. If we just focus on load shedding, it seems like there may be some very simple possibilities. For example, I could imagine an HTTP response header (or frame...) that says "please don't use this IP address for the next N minutes". For the next request, the client would rerun its usual connection setup flow (including resolving fresh copies of any DNS records that have expired), but avoiding that IP address (if possible). Another flag value could tell the client to avoid an entire TargetName, instead of just a single IP address.

This isn't very flexible, but it seems relatively simple for clients and servers to implement.

@ericorth

Fixups for Alt-Svc

@davidben says:

If we're looking to make a separate system here, with Alt-Svc still existing for a while, should we make a separate draft to patch up some of the more glaring mistakes in Alt-Svc? Or perhaps a paragraph in this one. I'm specifically thinking about how Alt-Svc tries to circumvent the TLS-level ALPN negotiation. For HTTPS/SVCB, we picked a more nuanced interpretation. Otherwise implementers may not know that Alt-Svc misunderstood ALPN and that they need to ignore the spec on this point.

This seems like something we could do with this draft, provided that it is limited in scope. (The ALPN thing is pretty simple.)