Re: [rtcweb] Final plea about SRTP

[Roman Shpount <[e-mail]>]

Cullen,

I do not think bid down is an issue. It should be clearly specified when
the peer connection is created that it is SRTP or RTP and never should one
become another. And if key exchange mechanism selection is not enforced, I
would consider bid down from DTLS to SDES SRTP just as much of an issue.

Numerous reasons for RTP support have been mentioned on this list (legacy
interop, easier to implement, easier to debug, quicker to setup, can be
used from a location from which encrypted communications are not allowed)
but as far as I know none of them have been considered compelling by the
people on this list. As everyone have mentioned before, requiring SRTP does
not really break anything, but, from my point of view, it just makes
implementation of some services more difficult for no apparent reason. I
simply see this as a general design flaw introduced based on FUD.
_____________
Roman Shpount


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
>
>