Subject: [quicwg/base-drafts] Introduce a bit to indicate the server doesn't do IP-based authentication (#1993)

From: Anne van Kesteren <[email-masked]>
Date: Mon, 12 Nov 2018 01:53:29 -0800

Web browsers have needed to invent a variety of schemes to talk to servers, such as the [CORS protocol](https://fetch.spec.whatwg.org/#http-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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1993

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Nov 2018 02:06:51 -0800

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1993#issuecomment-437824022

---

From: Anne van Kesteren <[email-masked]>
Date: Mon, 12 Nov 2018 04:21:45 -0800

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1993#issuecomment-437859443

---

From: Patrick McManus <[email-masked]>
Date: Mon, 12 Nov 2018 20:56:41 +0000 (UTC)

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1993#issuecomment-438025695

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Nov 2018 03:23:31 +0000 (UTC)

FYI, in accordance with the spirit of [RFC 5704](https://tools.ietf.org/html/rfc5704), w3c/webrtc-quic#73 just had this added: https://github.com/w3c/webrtc-quic/commit/a4b1bee

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1993#issuecomment-438118661