Re: [rtcweb] Final plea about SRTP

[Bernard Aboba <[e-mail]>]

At IETF 83,  Dan showed some slides relating to SRTP/RTP gateways that
seemed to cover the "extreme legacy" case quite well. 

In those slides, the "RTCWEB" components were still talking SRTP, so they
could be said to be compliant with a "mandatory to implement, mandatory to
use" posture.   Yet, the circa 2005 IP phone still got to receive and send
RTP.  

Since the "extreme legacy" cases are solvable via gateways, and the
performance impact and cost on virtually any new hardware (PC/tablet/mobile)
is minimal, it seems to me that making SRTP mandatory to implement and use
has little downside.

A few years ago, the thought of turning on SRTP by default was a bit scary
(mostly because of potential interop issues, not cost).  However, today
turning it on by default "just works" with minimal performance impact or
other hassles (other than occasional interop gremlins).  By the time RTCWEB
is widely deployed any argument against SRTP will probably be vestigial.

Given this, it seems to me that the "right thing" is for SRTP to be
mandatory to implement and use, especially if SDES is available, so the
likelihood of interoperability will be high.   

On Wed, May 2, 2012 at 5:32 PM, Cullen Jennings <[e-mail]> wrote:


Roman,

One comment on this - I think people understand there could be services with
no security requirements that could run over RTP, and HTTP, with no
identity. But we need to have a secure solution for some other services. The
questions is once you have a secure solution, what is the incentive to also
support an insecure solution - so far no one has come up with a super
compelling story about dealing with the bid down and I suspect that lots of
people did not view the overhead of running the secure version as all that
high. I suspect that is part of why the decisions went the way it did -
basically people agreed we needed a secure solution, and when they
considered also having an insecure solution, they saw lots of complications
of doing both and not much gain in the insecure solution over the secure
solution.

Cullen




On May 2, 2012, at 10:03 AM, Roman Shpount wrote:

> I know there was a consensus call on this list that SRTP shall be used for
all the calls in WebRTC, but I still do not understand the justification for
this requirement for WebRTC applications delivered over HTTP with no
identity. For such scenarios SRTP (even DTLS-SRTP) serves almost no purpose.
If application is delivered over HTTP attacker can spoof the entire web
site. It is trivial if the attacker is on the communications path. If
attacker is seating in the airport using the same network, it can put itself
on the communications path using arp cache poisoning. Once the web site is
spoofed, any type of man in the middle attack can be implemented. If
DTLS-SRTP is used user can detect the attack by checking the key signature,
but in reality very few people will do this.
>
> The main argument to require SRTP everywhere was that it does not break
anything. But neither would naming all the API methods in High Elfish.
Either requirement does not break things, but make working with WebRTC
harder then it should. At the same time both of those requirements are
completely unjustified.
>
> Furthermore, assumption on this list that most of the WebRTC use would be
peer-to-peer communications between browsers with all the rest of the
communication modes, such as calling automated services or PSTN being
insignificant. I simply do not agree to this point of view. I expect that
communication with automated services, such as video greeting cards or voice
blogging, would be a significant portion of WebRTC user base. If such
automated service is deployed as a plain HTTP web site, it should be able to
communicate with web browsers using RTP. SRTP in such case would serve no
purpose.
>
> Finally, requiring secure communications for everything is going against
the way most of the web works. Most of it is not secured and only requires
secure communications when secure (HTTPS) web site is accessed. I think it
should be the same for WebRTC, with DTLS-SRTP required when connected to
HTTPS web site and plain RTP allowed when connected to plan HTTP.
> _____________
> Roman Shpount

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