A calling platform bridges WebRTC browsers to a SIP trunk that supports only SDES; how would you design SRTP keying across the two legs, and what does each leg trust?
answer
- two keying systems, no single key
- the gateway is a trusted party
- fingerprint integrity on the browser leg
- keys in signalling on the trunk leg
basics
~20 sTerminate each leg at a gateway: DTLS-SRTP toward browsers, SDES toward the trunk, decrypting and re-encrypting between them. The browser leg trusts signalling integrity for fingerprints; the trunk leg trusts every signalling hop with keys, so harden and shrink that path.
solid answer
~50 sThere is no end-to-end SRTP key here: browsers must use DTLS-SRTP and must not offer or accept SDES (RFC 8827), and the trunk only speaks SDES. So a gateway terminates both. Toward the browser it is the DTLS peer, its certificate's fingerprint sits in the SDP the platform sends, and that leg trusts the platform's signalling for integrity and gains forward secrecy from ephemeral Diffie-Hellman suites. Toward the trunk it sends and receives `a=crypto` keys, so that leg trusts every proxy and log that can read the SDP, and has no forward secrecy. Media is plaintext inside the gateway, which makes it the highest-value component. I would protect the trunk signalling on every hop, keep `a=crypto` out of traces, use fresh keys per call, refuse unencrypted answers and move the trunk to DTLS-SRTP when the carrier supports it.
go deeper
Recall that the browser side must use DTLS-SRTP while the trunk uses SDES, so a gateway in the middle has to decrypt and re-encrypt the media.
Explain what each leg puts in its SDP, a fingerprint versus the key itself, and why that changes what the signalling must protect.
Show how to operate the trunk leg safely: protected signalling on every hop, redacted traces, fresh per-call keys, refusing downgrades, and watching mismatch teardowns.
Own the trust boundary: the gateway sees all media, SDES widens key exposure to the signalling path, and migration to DTLS-SRTP, gateway isolation and handshake capacity are the levers.
## Why there is no single end-to-end key The two sides use different keying systems that cannot be joined: - **The browser leg** must use DTLS-SRTP. RFC 8827 requires DTLS-SRTP for every media channel, forbids offering or selecting SDES, forbids an MKI and forbids page script from reading exported keying material. - **The trunk leg** only speaks SDES (RFC 4568), where each sender writes its own transmit key into an `a=crypto` line. A DTLS-SRTP key is exported from a handshake and is not fully under either side's control, while the trunk chooses its own SDES transmit key. The browser can never be told to expect the trunk's key, and copying the browser leg's exported key into an `a=crypto` line would put it on the signalling path. So a **gateway** terminates both legs: it decrypts media from one, re-encrypts it for the other, and holds plaintext in between. RFC 5764 describes the same shape for a conference bridge: each flow has its own key, and the mixer decrypts and re-encrypts for every recipient. ## What each leg trusts | | Browser leg | Trunk leg | |---|---|---| | Keying | DTLS-SRTP | SDES | | What the SDP carries | the gateway's certificate fingerprint | each side's master key and salt | | What signalling must provide | integrity | confidentiality and integrity | | Who can decrypt with signalling access | nobody without also attacking media | every proxy, trace or log holding the SDP | | Forward secrecy | yes, with ephemeral Diffie-Hellman suites | none | | Typical failure | fingerprint mismatch, call goes silent | key in a leaked trace, call decryptable later | On the browser leg the platform's own signalling server is trusted for fingerprint integrity: RFC 8827 notes that the signalling service can interpose unless keys are verified independently. Here that is accepted by design, because the platform's gateway is already the browser's media peer. ## Decisions a lead owns 1. **Where the trust boundary sits.** The gateway sees every call in clear. Isolate it, restrict who can reach its memory and logs, and treat its keys and certificate as production secrets. 2. **How the trunk's SDES keys are protected.** RFC 4568 requires the SDP to be encrypted and authenticated, end to end with S/MIME where intermediaries process it. In practice, demand TLS on every SIP hop to the carrier, count every proxy on that path as a holder of the keys, and keep the path short. 3. **Logging hygiene.** Redact `inline:` values from SIP traces and diagnostics, and keep media recordings and signalling archives apart, since together they decrypt calls. 4. **Key freshness.** Generate a random master key per call and per direction, never reuse one, and re-key long legs before their packet limits. 5. **Downgrade policy.** Refuse answers that drop to plain RTP or add `UNENCRYPTED_SRTP`; an unauthenticated SDES exchange can be modified to do exactly that. 6. **Migration path.** RFC 5763 defines DTLS-SRTP for SIP. Where the carrier supports it, the trunk leg needs only signalling integrity, gains forward secrecy and keeps keys out of traces. ## Trade-offs to weigh - **Termination enables features.** Transcoding, recording and interconnect need plaintext anyway; RFC 5764 notes that modifying media breaks the authentication tag and forces a decrypt and re-encrypt. - **Cost sits in handshakes, not packets.** RFC 5764 observes that one public-key operation to set up a DTLS-SRTP association costs hundreds of times as much as decrypting an SRTP packet. With RTP and RTCP multiplexed and streams bundled, WebRTC usually needs one handshake per call, and session resumption amortises parallel handshakes. Size the gateway for call set-up rate as well as media throughput. - **Blast radius.** One compromised gateway exposes every call through it, while one leaked trunk trace exposes the calls in that trace. Both deserve monitoring: certificate-mismatch teardowns on one side, unencrypted-answer rejections on the other. ## What not to do - Do not offer SDES to browsers to make the legs match; WebRTC forbids it. - Do not treat TLS to the first proxy as protection for SDES keys across the whole path. - Do not fall back to plain RTP when the trunk rejects SRTP; fail the call and alert.
- Could the gateway pass the browser's DTLS-SRTP keys through to the SDES trunk and skip re-encryption?Not in general. The trunk picks its own SDES transmit key, and the gateway cannot make it equal the key the browser derived from the DTLS exporter for that direction. In the other direction, copying the browser leg's exported key into an a=crypto line would put it in signalling, giving it SDES's exposure. Both profiles and SSRC handling would also have to line up exactly.
- What changes if the carrier adds DTLS-SRTP support on the trunk?The trunk leg then signals only certificate fingerprints, so its SIP path needs integrity rather than confidentiality, traces stop holding usable keys, and ephemeral Diffie-Hellman suites give forward secrecy. The gateway still terminates both legs and still sees plaintext, but the largest exposure, keys readable by every proxy and log, disappears.
- Where does DTLS-SRTP cost a gateway the most capacity?In handshakes rather than per-packet protection. RFC 5764 notes that a single public-key operation to set up an association costs hundreds of times as much as decrypting an SRTP packet. A burst of call set-ups is the stress case, so size for set-up rate, multiplex RTP and RTCP, bundle streams, and use session resumption for parallel handshakes.
saying these in an interview costs you the question
- The browser and the SIP carrier can share one SRTP key end to end through the gateway.
- TLS on the first SIP hop makes the trunk's SDES keys as safe as DTLS-SRTP.
- Because both legs use SRTP, the gateway never handles plaintext media.
- Falling back to plain RTP when the trunk rejects SRTP is a harmless compatibility step.
- Offering SDES to the browsers would let both legs share one keying method.