Re: [rtcweb] Let's define the purpose of WebRTC

[Justin Uberti <[e-mail]>]

On Sun, Nov 6, 2011 at 9:38 AM, Eric Rescorla <[e-mail]> wrote:

> On Sun, Nov 6, 2011 at 1:16 AM, José Luis Millán <[e-mail]>
> wrote:
> > Hello you all,
> >
> >
> > 2011/11/6 Hadriel Kaplan <[e-mail]>:
> >>
> >>
> >>
> >> On Nov 5, 2011, at 9:35 AM, Iñaki Baz Castillo wrote:
> >>
> >>> Hi, in theory WebRTC is about realtime communications for the Web, but
> >>> there is interest in making it interoperable with SIP networks. So:
> >>>
> >>> - Who is interested in interoperability with SIP? telcos (and me).
> >>
> >> I think that's an exaggeration, or perhaps a simplification, or
> generalization - well, some X-ation anyway. :)
> >>
> >> There is a ton of SIP in the Enterprise market, and they're not
> "Telcos".  Enterprises deploy a lot of web servers and web applications as
> well, obviously - some for the public Internet, and some for their intranet
> (which may happen to be through VPNs over the public Internet).
> >>
> >>
> >>> - What does require "interoperability with SIP"? does it mean that
> >>> WebRTC should allow plain RTP and no ICE? This has been discussed many
> >>> times in this WG: Security in the media plane MUST NOT be optional, it
> >>> MUST be a MUST. So sorry, but a legacy SIP device not implementing
> >>> SRTP+ICE cannot interoperate with a WebRTC endoint. Period.
> >>
> >> I don't think one can lump SRTP together with ICE as an all-or-nothing
> binary choice of "security".  The two solve very different problems.  The
> WG may end up deciding both have to be used in the end, but the decision
> should be made independently.
> >>
> >> I don't see a way to let WebRTC happen without ICE, for example, simply
> for the consent portion of it - we can't trust the Javascript well enough
> to do without it.  But supporting plaintext RTP isn't about
> trusting/not-trusting the Javascript - it's more akin to allowing
> web-applications to use HTTP vs. HTTPS.  Are we going to mandate HTTPS be
> used as well?
> >>
> >> There are web applications which don't care about securing their
> content.  A game app, for example, might not care about secure media and
> might not want to use SRTP because they have to use a central media server
> mixer or announcement server or whatever, and don't want to take the hit
> for SRTP on it.  Another example is a website for creating virtual greeting
> cards, which might use WebRTC to record a personal greeting to go with the
> virtual card, and might not want to take the hit to secure media to their
> recording servers. (I don't know if they're popular elsewhere, but in the
> US these virtual greeting e-card things are popular for sending
> birthday/anniversary/etc. greetings, and most of them are plaintext HTTP)
> >
> > draft-ietf-rtcweb-overview-02 downgraded the SRTP concerns from
> > mandatory-to-use to mandatory-to-implement. So if it does not
> > downgrade anymore, a WebRTC implementation (game app, greeting cards
> > website..) will have to implement SRTP.
>
> Hmm... I I don't see any
> reason to allow insecure calling from one WebRTC client to another.
> It's a different question whether one should allow insecure calling
> to legacy clients.
>
> > IMHO, if a web service doesn't want to take, or cannot take, the hit
> > for SRTP, WebRTC is not the appropriate solution for such a service.
>
> I'm exceedingly unsympathetic to the claim that SRTP is too slow. This
> is precisely the claim that was made about TLS for years, but measurements
> (see Langley and Modadugu's Overclocking SSL talk at Velocity) show
> that that's not really true.
>
>
Agreed. I am also unsympathetic to the claim that SRTP is too hard to
debug. Google+ Hangouts was built as SRTP-only, and this (as well as
performance) was never an issue in the construction and deployment of the
service.