[QUIC] Investigate WebSocket layering onto QUIC

[mfoltzgoogle]

As HbbTV 2.0 [1] and ATSC 3.0 [2] leverage WebSockets as part of their core presentation framwework, we should investigate to what extent the WebSocket protocol can be implemented with QUIC. This would provide part of a path to interop or backwards compatibility between a QUIC-based Open Screen protocol and these standards.

[1] https://www.hbbtv.org/
[2] https://www.atsc.org/atsc-30-standard/a3382017-companion-device/

Relevant issue from Second Screen WG: w3c/presentation-api#67

[schien]

In order to run WebSocket over QUIC, integrating WebSocket with HTTP2 is essential from this discussion.
An early proposal has been posted to httpwg but no further discussion.

[tomoyukilabs]

Now IETF HTTP WG is discussing WebSockets with HTTP/2 again:
https://lists.w3.org/Archives/Public/ietf-http-wg/2017OctDec/0076.html
https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-websockets-01

[schien]

Looks like there is more progress on the IETF side. The approach of WebSocket over HTTP/2 is likely to embed WebSocket frame inside a HTTP2 frame, instead of steal the entire TCP connection. Non-secured WebSocket will not be allowed.

This is will become the major road blocker for HbbTV and ASTC since they both depend on non-secured local web server. @tomoyukilabs probably has more insight than me on how to support HTTPS in local network.

[mfoltzgoogle]

I didn't think that QUIC was feasible on HbbTV or ATSC terminals. If they are willing to deploy QUIC in a future iteration, the more promising framing is the QUARTC (DataChannel over QUIC) approach.

[tomoyukilabs]

@mfoltzgoogle One question: Does QUARTC require a bootstrapping signaling channel as current RTCDataChannel does?

[schien]

According to this proposal, additional signaling channel is still required to establish QUARTC.

[tomoyukilabs]

Thanks, @schien!

[tomoyukilabs]

This is will become the major road blocker for HbbTV and ASTC since they both depend on non-secured local web server.

The problem with secure connection between devices in local network is that such a self-signed certificate is not trustworthy, because the certificate cannot be validated with root CA's certificate.

To solve this problem, we need to find another mechanism to validate whether the local server would be trustworthy or not without relying on root-CA-based PKI (e.g. J-PAKE, as we have discussed so far). I guess that such a trust model looks like overall problem with securing connections on open screen protocol, not limited to HbbTV or ATSC.

Anyway, some sort of addition or modification to TLS authentication mechanism or certificate management would be necessary for HbbTV and ATSC (and possibly Hybridcast in Japan), unless the user would be asked to install private CA to validate local server's certificate on their browser or OS.

Note that Hybridcast is facing the same problem, and eventually they are now using native apps instead of web browsers as a companion screen for Hybridcast.

[mfoltzgoogle]

Since QUIC/QUARTC don't seem compatible, the route forward for platforms built on insecure WebSockets is to enable a security model that can be layered on top. I propose we finish defining the authentication model for QUIC/QUARTC and then see what is necessary to map it onto the existing WebSocket protocol.

[tomoyukilabs]

@mfoltzgoogle Do you mean that we should consider an additional securing mechanism on the top of existing WebSocket protocol, without adopting TLS?

I can agree that QUIC/QUARTC would be incompatible currently due to the TLS problem. I'd like to explain the reasons for further clarification:

QUIC

According to the current spec of HbbTV, HbbTV currently gives up using TLS due to the following reason:

The secure mode of WebSockets cannot be used because certificate authorities will not issue certificates for a server having a dynamic or private IP address. Such a server could not present a suitable certificate chain. For more information, see clause 7.1.4.2.1 of the CA/Browser Forum Baseline Requirements [i.17]. See also clause A.3.13 "Mixed Content".

This implies that QUIC with TLS 1.3 could not be deployed by HbbTV.

QUARTC

If HbbTV or ATSC would be willing to deploy WebRTC with QUARTC, they could use the WebSocket connection for WebRTC signalling channel and establish QUARTC connection. However, if the web application is in a secure context to use WebRTC, the non-secure WebSocket connection for signalling becomes unavailable due to mixed content restriction. (I still wonder whether there could be any kind of compromise, though.)

[louaybassbouss]

I agree with @mfoltzgoogle I am not sure whether there could be any kind of compromise. HbbTV 2 Companion Screen is designed with main focus on native applications. In case of web applications, the only option to use the insecure WS is to load the web application via http otherwise the mixed-content issue will occur.

[pthatcherg]

I'm not sure what is meant here by QUARTC. As the person who came up with the word (which I spell "Quartc"), I'm interested to know what you think it means.

I'm guessing you mean something like one of these two:

http://draft.ortc.org/#dom-rtcquictransport
https://github.com/w3c/webrtc-quic/blob/master/index.html

They are roughly the same.

Currently they are defined for QUIC with ICE where the client does ICE then QUIC. ICE does need some signaling (although it's basically just that you need ip + port + ufrag + pwd instead of just ip + port), and QUIC needs a remote certificate.

You don't need a CA for the certificate. You just need to pass the fingerprint over the certificate into the QuicTransport. So perhaps there is no TLS problem?

[tomoyukilabs]

@pthatcherg Initially, we discussed how to incorporate QUIC (not QUARTC) into WebSocket on HbbTV or ATSC terminals, but we found that need for a certificate is a major blocker.

We can still discuss how to deploy QUARTC with bootstrapping signaling channel on WebSocket, for example, and one of the possible problems is that we still need to consider how to secure the bootstrapping signaling to avoid the risk of man-in-the-middle attack.

[mfoltzgoogle]

Current spec requires QUIC; verification of the TLS certificates is done through a authentication step via SPAKE2 in the current spec:

https://w3c.github.io/openscreenprotocol/#authentication-with-spake2

I don't think WebSockets are going to be a viable solution, but I do believe that WebTransport with custom certificates is worth investigating.