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

[Roman Shpount <[e-mail]>]

I guess my question is, when are we going to tell the user that connection
is "secure"? What I really do not want is making the distinction between
secured and unsecured connection so muddy, that a normal user will never be
able to understand the difference and will agree to anything. Because of
this, I would like to see that if connection is over DTLS-SRTP with a
remove party verified by an identity provider, user would be asked if they
would like to communicate with remote party XYZ. If this is anything else,
(DTLS-SRTP with no identity, SDES-SRTP, or even plain RTP), user should be
asked either to allow unsecure communication with an unknown party, or,
completely prohibited to do so.

I do not see the difference, as far as security is concerned, between
SDES-SRTP and plain RTP. If we allow SDES-SRTP for compatibility reasons,
we might as well allow plain RTP. It would be compatible with more devices
and as insecure as SDES-SRTP. There is no requirement that WebRTC
application must use HTTPS for signaling. If the application is using HTTP,
all the "sitting in the airport" examples are as unsecured with SDES-SRTP
as they are with plain RTP.

I do not think we would be able to force WebRTC application developers to
create a secure application unless they would decide to create care and
effort to develop it as such. Our goal should be to provide application
developers with tools that would allow them to create secure applications
and with mechanisms that would allow users to identify when their
communications are actually secure. Everything else is just adding random
requirements to the standard.
_____________
Roman Shpount