Re: [rtcweb] Resolving RTP/SDES question in Paris

+1

I'll add more usecase to strengthen RTP usage in WebRTC.

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount
Sent: Monday, March 19, 2012 9:51 AM
To: Ejzak, Richard P (Richard)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris

+1
_____________
Roman Shpount

On Mon, Mar 19, 2012 at 12:10 AM, Ejzak, Richard P (Richard) <richard.ejzak@alcatel-lucent.com<mailto:richard.ejzak@alcatel-lucent.com>> wrote:
I would like to argue two points: 1) DTLS-SRTP with IdP is the only media security scheme that rtcweb should support; and 2) rtcweb should also support RTP (no media security) with a clear requirement on the browser UI to warn the user of the complete lack of media security.

DTLS-SRTP

Some of the arguments made against DTLS-SRTP in recent emails are valid unless it is integrated with trusted IdP that is sufficient to verify the identity of the remote party.  With this one caveat, DTLS-SRTP is equal to or (mostly) better than SDES-SRTP in almost all respects (not to be repeated here).  Even if the identity is suspect, the IdP can at least provide some degree of assurance and accountability when an issue arises.  Without that, a user has no recourse when a problem develops.

The key is that the browser UI must make clear to the user the identity of the remote party with whom media security has been established (even when it is a network gateway, in which case the identify of the gateway operator).  It should also be possible for the end user to mandate that a remote party identity is always verified before communication is allowed (perhaps even make this a requirement when media security is selected).  This is not too burdensome a requirement if established up front to help manage SPIT.

When end-to-end security is possible, then Alice knows that she's talking to Bob and vice versa.

Even when Alice is talking to someone reached via the PSTN, she can know that she has a secure media connection to a gateway owned by a particular (the identified) operator, thus establishing a significant part of the chain of accountability.  We can't improve on the security available through the PSTN, but we can improve on the security available to the point of interconnection with the identified operator (which may be different from the owner of the rtcweb application).  With DTLS-SRTP the user can have some basis for deciding whether to trust the identified operator; else (even with SDES-SRTP) you must completely trust the owner of the rtcweb application and there is no way to identify or verify any security attributes associated with the media.

Finally, there are multiple reasons to avoid supporting multiple media security schemes.  It is difficult enough to expect the end user to make sure they are comfortable with the identity of the remote party of a secure media connection, but to ask if they are comfortable with an alternative media security scheme is simply too much to expect.  Bid-down attacks are just too easy and it is impossible to verify any remote party identity with SDES-SRTP.

RTP

There are too many reasonable use cases for unsecured media for us to ignore them.  The browser should be very clear when media security is unavailable and make it easy to prevent communication without media security (perhaps as a default setting), but there are legitimate use cases in various private environments (e.g., enterprise, jail) where media security may not be allowed (or must somehow be compromised), or is just not available, that we should just support straight RTP.  As long as the user can control the conditions under which media security is disabled, I do not see a problem.

Richard Ejzak

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org<mailto:rtcweb@ietf.org>
https://www.ietf.org/mailman/listinfo/rtcweb