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

Justin Uberti <juberti@google.com> Sun, 06 November 2011 16:35 UTC

Return-Path: <juberti@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32E621F84ED for <rtcweb@ietfa.amsl.com>; Sun, 6 Nov 2011 08:35:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.526
X-Spam-Level:
X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCzQHUmNEGNl for <rtcweb@ietfa.amsl.com>; Sun, 6 Nov 2011 08:35:15 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E1EE621F84DC for <rtcweb@ietf.org>; Sun, 6 Nov 2011 08:35:14 -0800 (PST)
Received: by iaeo4 with SMTP id o4so6256085iae.31 for <rtcweb@ietf.org>; Sun, 06 Nov 2011 08:35:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=2v3wDaqxl8XBN3wTheF1nUiVLqKfLXTpJm7ToUC/v3k=; b=SxW+6cLoFeK5m+mjyvv56G3fgEqAnx1YXhySx2V0J4Xc3aXMQ7Y+v7rVsnymrIBco3 O/BYYF9wni3M7Vw/2/xA==
Received: by 10.231.41.69 with SMTP id n5mr8758061ibe.92.1320597313458; Sun, 06 Nov 2011 08:35:13 -0800 (PST)
Received: by 10.231.41.69 with SMTP id n5mr8758041ibe.92.1320597313165; Sun, 06 Nov 2011 08:35:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.34.4 with HTTP; Sun, 6 Nov 2011 08:34:52 -0800 (PST)
In-Reply-To: <CABcZeBNqdkh8u=gwOvKfDCQA7rXdAyQkfaM1r2Sx10787btP6A@mail.gmail.com>
References: <CALiegfkVNVAs_MyU_-4koA4zRwSn1-FwLjY9g_oZVkhi9rSK5Q@mail.gmail.com> <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <CABw3bnPE=OY_h5bM7GA6wgrXiOBL8P4J0kw1jLv-GSpHAbg=Cg@mail.gmail.com> <CABcZeBNqdkh8u=gwOvKfDCQA7rXdAyQkfaM1r2Sx10787btP6A@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Sun, 6 Nov 2011 11:34:52 -0500
Message-ID: <CAOJ7v-3pqFNyXsd7WYiL_7+pYZ9JxDrXnaMiSVYDzUfUGDAZJA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary=0015177407d4be1a0d04b1138587
X-System-Of-Record: true
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Let's define the purpose of WebRTC
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Nov 2011 16:35:15 -0000

On Sun, Nov 6, 2011 at 9:38 AM, Eric Rescorla <ekr@rtfm.com> wrote:

> On Sun, Nov 6, 2011 at 1:16 AM, José Luis Millán <jmillan@aliax.net>
> wrote:
> > Hello you all,
> >
> >
> > 2011/11/6 Hadriel Kaplan <HKaplan@acmepacket.com>om>:
> >>
> >>
> >>
> >> 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.