Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Ambiguity in CORS-like mechanism in the handshake #60
https://wicg.github.io/web-transport/#protocol-security says: “All transports must allow the server to filter connections based on the origin of the resource originating the transport session.” but this doesn’t seem to be quite what is specified in https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 which says "QuicTransport uses a QUIC transport parameter to provide the user agent with an origin whitelist. The origin is not sent explicitly, as TLS ClientHello messages are sent in cleartext; instead, the server provides the user agent with a whitelist of origins that are allowed to connect to it."
The QuicTransport spec thus imposes two serious limits:
This is true.
Here's an alternative we discussed that would solve these issues:
This avoid any extra RTT before sending data and gives the server all the flexibility that it needs.
Also, we should leave open the flexibility to add extra data to the stream, such as for #26
Ah, so the idea is that the "unidirectional stream ID" here could be a hard-to-guess nonce and thus knowledge of it could serve as proof to the stream server that the client was spawned either by an expected origin page or a page that collaborated with the expected origin page to learn the nonce?
That sounds reasonable.