Re: [rtcweb] SRTP not mandatory-to-use

[Justin Uberti <[e-mail]>]

On Wed, Jan 11, 2012 at 4:46 PM, Bernard Aboba <[e-mail]>wrote:

>  Randall said:
>
> > The reason (as I've mentioned at times) is that SDES means we expose the
> > media to the JS app and to the website, neither of which we've agreed to
> > trust. All the discussion of blocking access to decrypted media from
> > the JS app is moot if it has the keys.
> >
> > If we use SDES, we're effectively trusting the JS app (and website) to a
> > very large extent. (Not to turn on the camera/mic, but with the
> > contents of all conversations.) It also means bid-down to SDES is
> > trivial. I'm not sure what this would mean to identity validation via
> > BrowserID or others (ekr?); that might survive this, but it means media
> > could be decrypted in realtime or later if anyone has copies of the
> > packets and can get the key from the app/website.
>
> [BA] While I agree with your assessment of the security implications of not
> supporting end-to-end key management, I'm concerned about the practicality
> of mandating use of an RTCWEB DTLS/SRTP variant in RTCWEB v1.0.
> The SIPIt reports note progress on SDES implementation, but DTLS/SRTP
> not so much, and integrating DTLS/SRTP within RTCWEB would require more
> work beyond what is available in SIP DTLS/SRTP implementations today.
> As a result, I am more inclined toward Justin's proposal for RTCWEB v1.0
> (assuming that the questions are answered).
>
> My view is that Justin's approach will maximize the potential for initial
> RTCWEB implementations to interoperate, whereas a mandate for DTLS/SRTP
> with no SDES support is very likely to result in initial interoperability
> problems
> which could fester for a long time.  IMHO, an interoperable RTCWEB v1.0
> should be our highest priority, even if it doesn't have all the features we
> would want for v2.0 and beyond.  This also goes for some of the more
> advanced features described in the RTP draft, by the way.  Perfect is
> the enemy of the good.
>

This is exactly my thinking. We are working very hard at getting DTLS/SRTP
up and running, but I am all too familiar with betting the farm on
something that is all-new.


>
> From the description in the Security draft, it is not clear to me whether
> the
> RTCWEB DTLS/SRTP proposal will necessarily interoperate with SIP
> implementations of DTLS/SRTP.   While the proposals have elements
> in common (e.g. DTLS/SRTP itself, fingerprinting, etc.) SIP DTLS/SRTP
> implementations cannot be expected to implement BrowserId, and
> RTCWEB DTLS/SRTP implementations may not support RFC 4474.
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>