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

["Jim Barnett" <[e-mail]>]

On the matter of the call center/travel site recording your call:  can't
the far-end user agent always record your call, no matter what security
you use?  So in the case of SDES, the call center can record at their
SBC/switch/media server (their in-house MITM), which is easier for them,
but even with DTLS/SRTP couldn't they always record it at the agent
desktop, if they wanted to?

- Jim

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Hadriel Kaplan
Sent: Monday, March 19, 2012 6:24 PM
To: Roman Shpount
Cc: [e-mail]
Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris


While I sympathize with the concern that requiring SRTP (regardless of
how the key is learned) is a burden for those use-cases that literally
don't care about SRTP and for which it does not matter, such as a
weather announcement service or an IETF meeting broadcast, I really
think you're 'throwing out the baby with the bath-water' to propose we
either get everything or nothing.  People won't have the identity-stuff
for some time, and it won't be painless to make it work and deployed.
So what you're basically saying is "you only get RTP because you can't
prove end-to-end security".  But such "proof" rarely exists even today.

Today, when you do Email or IM over HTTPS or SMTPS, that email or IM
only goes secure to the server you're doing SMTPS or HTTPS with.  You
have no assurance whatsoever that it stays secure from that point on,
nor that the server doesn't log the email/IM in its entirety.  But that
doesn't mean there's no value in using HTTPS/SMTPS to reach that first
server.  Quite the contrary, there's significant value in it.  Just like
there's value in using HTTPS to reach a web store-front when purchasing
using a credit-card, even though you have no idea what the security is
between the web-store and your actual credit-card company.

In the WebRTC context, for example, I would expect a quite-popular
use-case for WebRTC to be Business websites, such as web-storefronts, or
customer-support sites, or airline/hotel ticket/reservations/upgrades
sites, etc.  When connecting to the web-page of those sites, I would
expect them to be HTTPS once I got to some point of the click-flow
process, if not from the beginning.  If I click a "talk to us for help"
button, I would expect that to be secure as well, as much as the HTTPS
portion was anyway.  In this context, only allowing them to use RTP is
silly.  SDES is reasonably secure in this context, because there is no
other domain the call is going to.  Yes, they have my SRTP key - doesn't
matter; yes they can log my call - doesn't matter.  But at least my
media is secure from my laptop to their server's domain - and that does
matter, and it's all I ever got from using HTTPS.

-hadriel


On Mar 19, 2012, at 2:15 PM, Roman Shpount wrote:

> 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
> 
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtcweb