Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00]

[Hadriel Kaplan <[e-mail]>]

On Oct 29, 2011, at 12:06 PM, Harald Alvestrand wrote:

> I considered it when we discussed this last, but I'm not sure it works.
> If we support SDES, the offer also contains crypto keys. Reusing crypto keys for all created connections would be a huge security vulnerability.

The SDES key is used in the sending direction, not the receive.  That means everyone receiving the ROAP Offer will get the key and be able to decrypt the Offerer's transmitted media, but only the receivers of the ROAP Answer will be able to decrypt the Answerer's media.  So yes obviously if the ROAP Offer is generated by a Browser and sent to multiple parties, all of those parties would be able to render the media (and possibly spoof it to the others).  

But that vulnerability exists with SDES regardless of whether we support ROAP forking or not.  Even if the WebRTC browser only allows one ROAP Answer for any given Offer, if SDES is supported at all then we have to trust the JS and Web server, and trust them not to send the ROAP Offer to multiple parties, or we have to trust all those parties - assuming ROAP contains an SDES key and the Browser ends up using it.  For example, even if we don't support ROAP forking, a benign JS and Web-server might still send the ROAP Offer to multiple Browsers and only send back one ROAP Answer from the first answering Browser, not realizing that doing so introduced a vulnerability.

My point is that supporting SDES to begin with opens up vulnerabilities, regardless of whether we support forking.  If we want to support SDES for interop with SIP, which I think we do, then what we could do is mandate the Browsers support both SDES and DTLS-SRTP, and that if they receive a ROAP Offer or Answer with DTLS-SRTP in the SDP they use it for that peer, ignoring SDES.  And also that in the Browser's security-info display that would otherwise show the DTLS-SRTP fingerprint/SAS, if SDES is used it says so and gives some info about its vulnerabilities. {Note: I'm assuming Browsers will be required to provide the DTLS-SRTP fingerprint/SAS in some display box if the human wants to see them]

Fundamentally SDES relies on trusting the Web server(s) and the clients it's given to.  In the Web you already rely on that, for any JS-created/seen message.  For example Web-based mail or IM.  You have to trust the JS+Server, and trust them to not send your message to parties which shouldn't get to see them.  I'm not saying that makes using SDES ok, but just noting it, fwiw.


> Of course we could mandate DTLS-SRTP key negotiation…..

Assume we did that.  Then to interop with SIP, the Web-server or an interworking device would terminate DTLS-SRTP on one side, and use SDES or plaintext RTP on the other, including to multiple SIP-forked parties.  What have you gained?  The only benefit is that if the human checks the fingerprint/SAS in the Browser's display-box, and verifies that the other side did not have the same SAS or none at all, then the human would know the media is potentially not secure end-to-end.  But you can display "The media is potentially not secure end-to-end" even if SDES were used by the Browser itself, without even needing the human to verify an SAS with the other side.

-hadriel
p.s. draft-wing-srtp-keying-eval-00 discussed this forking issue and recommended re-keying in forking scenarios, for SIP.  No one does that as far as I know, though.