Re: [rtcweb] Final plea about SRTP

[jesse <[e-mail]>]

On May 2, 2012 5:41 PM, "Bernard Aboba" <[e-mail]> wrote:
>
> 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,

First of all, solvable via gateway is a clumsy solution. For most small end
users, support and maintain gateway for srtp takes extra certain effort.
Very few VoIP systems make srtp default unless the whole system is provided
by big vendors.

Second, those are not extreme legacy. There are tons of traditional VoIP
systems there.

rtcweb is proposing a high standard, but "no legacy system should be left
behind" if the objective is to make rtcweb accessible everywhere and
everydevice.

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