- From: Martin Thomson via GitHub <sysbot+gh@w3.org>
- Date: Fri, 11 Dec 2020 08:52:03 +0000
- To: public-webrtc-logs@w3.org
I think that it makes sense to share name resolution and even socket establishment (if that is even large enough to bother factoring out into common code). If you go beyond socket establishment to connection establishment and pooling, then that doesn't apply to WebRTC. Even when it comes to TURN, the connection management is fundamentally different to what goes on with an HTTP proxy. A big question here is what, if anything, we do for policy enforcement (I can't find the original issue here, but I do remember discussing this on several occasions). Any solution we come up with for managing connections to hosts that are identified using certificate fingerprints will want to be shared with WebRTC and WebTransport. My initial thought is a `connect-src` special label that covers all identifiers of that type, but it needs work to be sure. No matter what solution we end up with, it makes sense to share that piece of infrastructure. I don't think that we can avoid policy enforcement for ever; people use `connect-src` to prevent data exfiltration and having common hooks would be good. I don't believe that the blocked ports are necessary for WebRTC or WebTransport as both protocols have fairly good consent/address validation arrangements. I say that only cautiously as QUIC has some exposure to request forgery attacks and it might turn out that we need something. I don't know whether anyone has done a proper analysis for DTLS and STUN to know if WebRTC is vulnerable, so that might be worth checking too. -- GitHub Notification of comment by martinthomson Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2613#issuecomment-743062024 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 11 December 2020 08:52:04 UTC