- From: Tomoyuki Shimizu via GitHub <sysbot+gh@w3.org>
- Date: Tue, 14 Nov 2017 02:15:19 +0000
- To: public-webscreens@w3.org
@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](http://www.etsi.org/deliver/etsi_ts/102700_102799/102796/01.04.01_60/ts_102796v010401p.pdf), 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.) -- GitHub Notification of comment by tomoyukilabs Please view or discuss this issue at https://github.com/webscreens/openscreenprotocol/issues/62#issuecomment-344123776 using your GitHub account
Received on Tuesday, 14 November 2017 02:15:23 UTC