Introduce a bit to indicate the server doesn't do IP-based authentication

[annevk]

Web browsers have needed to invent a variety of schemes to talk to servers, such as the CORS protocol for HTTP and WebSocket as some kind of TCP, to avoid allowing attacker.example access to IP-authenticated data (e.g., intranets without the best security setup).

It'd be nice if this kind of thing could be done at the base protocol level. This would also allow browsers to expose a QUIC^W??? API to communicate with arbitrary servers that have the relevant bit set. (If such an API saw adoption that might also be a further incentive for middleware to get their act together.)

This would not obviate the need for something like CORS entirely, as requests containing cookies or HTTP authentication data would still require explicit consent, but it would allow browser-based applications to more usefully take part in the ecosystem.

cc @jakearchibald

[martinthomson]

Since this idea probably traces back to me, I can't really say this is bad. But I think that we can probably do something in an extension. This is a somewhat specialized use case. Happy to work with you, @annevk or @jakearchibald, to make that happen.

A generic TLS extension might be better here. QUIC could pick that up, but it might also be nice to have that signal in other contexts than just QUIC.

I have significant reservations about how this sort of extension might be deployed safely. We'll have to be very careful to explain the risks of a mistake. Turning on a server-level config like this requires confidence that there are no resources on that server that are restricted. Worse, if servers can be used for connection coalescing (in HTTP/2 or QUIC), then that risk extends to all resources across all origins that might be coalesced onto the same connection.

I suspect that server-level CORS is a common-enough implementation technique. So we likely already have servers taking that risk. So on balance this is probably worth doing.

[annevk]

For CORS there might be origin-wide configurations going forward, as per https://github.com/WICG/origin-policy, but that wouldn't really help with any kind of low-level networking API.

And CORS is quite granular today when it comes to what kind of requests can be made. A low-level bit would bypass all those restrictions more easily allowing for dictionary-based attacks and such, including on cookies, which would no longer have the same restrictions as they do today in the Fetch/HTTP stack exposed by browsers. This also applies to other things in the Fetch/HTTP stack which would have to be re-examined. (This is assuming a low-level API on which an attacker could build their own HTTP client.)

Sigh, perhaps Origin Policy/Manifest is our best bet and low-level APIs are too dangerous.

[mcmanus]

interesting.

one of the nice things here is that it addresses the binding vulnerability by pushing cors down the stack (at least as far as the assertion goes). I would be concerned that variable binding is a normal part of the web platform (DNS, but also l4 lb, and alt-svc, and origin frame, ..) and its not hard to imagine mismatches here which lead to unexpected hard failure even for non web services.

[martinthomson]

FYI, in accordance with the spirit of RFC 5704, w3c/p2p-webtransport#73 just had this added: w3c/p2p-webtransport@a4b1bee

[martinthomson]

Tokyo conclusion: this is a candidate for an extension.