- From: Philipp Hancke via GitHub <noreply@w3.org>
- Date: Thu, 19 Jun 2025 12:23:53 +0000
- To: public-webrtc-logs@w3.org
[this CL](https://chromium-review.googlesource.com/c/chromium/src/+/6655441) works nicely but only after the connection is established since the source is the actual certificates. Nice but does not solve the problem. https://jsfiddle.net/fippo/ps5owk2g/1/ shows a couple of problems: * looking at the API shape i'd probably prefer getParameters * the DTLS transport typically doesn't have a pointer to its peerconnection. How does it get the peerconnection? How does it know which m= line in the remote description it is associated with? * after SRD the DTLS transport is still null, this only changes after SLD. You *do not want* to call setLocalDescription for a contact you do not trust since that starts gathering candidates and connecting to remote candidates. * You might want to be conservative whom you call setRemoteDescription for anyway. In particular the last bullet suggests this should be in the signal protocol which can then rely on the guarantee that a connection is rejected if the fingerprint does not match the SDP. At best this could live on RTCSessionDescription but then nobody wants to tackle the problem of "so how does an object for this SDP look" -- GitHub Notification of comment by fippo Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/3055#issuecomment-2987912280 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 19 June 2025 12:23:54 UTC