What Strong Binding Requires
The WebRTC and DTLS-SRTP ecosystem answers the opening question only when it keeps several different facts attached to the same session. An application names or admits a participant; signaling commits to a certificate fingerprint; DTLS checks the certificate, signatures, and protocol state; and the media server decides whether the resulting connection may receive or release media. This final synthesis turns those relationships into an engineering judgment. It also keeps the USENIX study’s evidence in proportion: the results reveal a serious server-side gap, but they do not establish a universal prevalence rate or erase the boundaries of the tested paths.
The governing principle is therefore more precise than “use encryption.” Ask three questions at every transition: What is bound to what? How is the binding checked? What does a successful check authorize? If the answer changes as the connection moves from signaling to DTLS to application media, the system may still be encrypting the wrong relationship.
The security argument is a chain of bindings
The first binding connects the application’s call claim to signaling. A service may describe a participant through an account, invitation, role, or meeting record. Its signaling message carries media parameters, ICE candidates, and a certificate fingerprint. The signaling channel does not carry the eventual audio or video, but it establishes the claims that later protocol stages are expected to honor. HTTPS protects the connection to a signaling service, but the service’s message is not automatically independent proof of the remote peer’s identity. If the signaling service can replace the fingerprint, the later DTLS handshake can be made to authenticate an attacker’s key without breaking SRTP.
The second binding connects the fingerprint to a certificate. WebRTC can use a self-signed certificate because the peer is not asking a public certificate authority to vouch for the certificate. It is checking whether the certificate presented during DTLS matches the fingerprint committed in the session description. A public-PKI certificate, a familiar issuer, or a matching subject name does not substitute for this comparison. The relevant authority is the call-specific fingerprint, provided it arrived through a signaling path the endpoint is willing to trust.
The third binding connects the certificate to private-key possession and to the DTLS state machine. The certificate contains a public key, but the endpoint must prove control of the corresponding private key through the signatures required by the handshake. It must also ensure that the key whose proof was checked is the key used to compute the shared secret. Datagram retransmissions and out-of-order delivery require tolerance, not permission to accept a new key in an unauthenticated state. A Finished message proves something about the handshake transcript; it does not repair a certificate comparison that never occurred or a state transition that used the wrong key.
The fourth binding connects the authenticated DTLS session to application authorization. DTLS-SRTP exports keys for SRTP and SRTCP, and SCTP data channels can be protected over DTLS. Those transports provide confidentiality and integrity for the session they establish. They do not independently know whether the media server has mapped that session to the correct participant, synchronization source, meeting, or application state. The service must make that mapping and decide what the connection is allowed to receive or send.
This last point is decisive in a media-server architecture. A relaying or mixing server is a legitimate DTLS endpoint, not merely a transparent pipe. It may need to see media to record, transcode, or combine a conference. That design can be useful without being end-to-end encrypted between participants, but it makes the server’s admission decision part of the confidentiality boundary. If the server accepts an attacker-controlled client key, the attacker may receive an encrypted stream whose cryptography is sound and whose authorization is wrong.
The study’s nine confirmed media or metadata outcomes demonstrate this chain crossing all the way to an application consequence. The eleven cases where media was not demonstrated show the opposite boundary: a DTLS-layer failure can be delayed, contained, or hidden behind an application-specific check. Neither result makes the other disappear. A handshake bypass is evidence that one authentication invariant failed. A media leak is evidence that the failure also crossed the application’s release decision.