Re: [rtcweb] A compromise for SDES

Peter Thatcher <pthatcher@google.com> Mon, 15 July 2013 12:47 UTC

Return-Path: <pthatcher@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 AAA3821F9FE2 for <rtcweb@ietfa.amsl.com>; Mon, 15 Jul 2013 05:47:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.929
X-Spam-Level:
X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 Iay3-hb0INCF for <rtcweb@ietfa.amsl.com>; Mon, 15 Jul 2013 05:47:16 -0700 (PDT)
Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 887DD21F9EAF for <rtcweb@ietf.org>; Mon, 15 Jul 2013 05:47:16 -0700 (PDT)
Received: by mail-pa0-f49.google.com with SMTP id ld11so11075238pab.8 for <rtcweb@ietf.org>; Mon, 15 Jul 2013 05:47:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1FbEERiIF2zJwO2bvXmiGBGFnp0yWUmHdx8wMfmS1S8=; b=C/boSMt3mKFhvfpDJSpwHd7lUe+uPybpMos6oeecrtxdb1gnLzDu5jnSd1xfHPrLGl /+IkmcKRJ4VmmXEXzp6M2iXRgWbVw8aG4E4WD3FFwnqA4ZeOhihN6+aaXcEClhlflE+c bkU9zHcgvq+DmzyNpdo6NWmwk487gmVfEQokAX+P/vV3xAJG3ALLq4OZFJkKFr1KNT5j EpZr3e4bgTTohyqmIZP9M/EVSSNlTCmAUZ6ecmoLT36PgBK3Xw48k1rCgGMmfAV8K/gO oHj8jHST/VR/4v0gplfU5QjgkFiduzlL/NxML92+wQfHsqEMGOh6kotHl+pjGvJY4e6u u5yw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=1FbEERiIF2zJwO2bvXmiGBGFnp0yWUmHdx8wMfmS1S8=; b=L6P1Z78uN+JyBrRZhNULFE7WtNTDJJFUOoGdcec4gBMGKRs87Ax+sOSVahk/vS6Jlp JLKDm9SM8K9Dt8RRH8gi/99/cbqj5SFptWIMsCX+XmgE4EoMUvOT9QqEIicYfbdeEEnF ZH5UoEU8PeoQ1jAeVQtKh9bLuphYUhuBwqDNCJDwhK6z3A5wYVFwm4IogTZpgGx970Wd dOfYjMrSet5c+uFSKg15ZlC/pMWpy0MciWPp//mdaH91D37Jwo8sn3V6AvxMplZUKAei L+xNInX7BSG+N+miP3x8mYYIQ437vHoqA+fTenXOeW2hP0lNnw5fAghwUyVPgo8tC9ao FXJg==
X-Received: by 10.66.228.72 with SMTP id sg8mr55085092pac.45.1373892434364; Mon, 15 Jul 2013 05:47:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.78.169 with HTTP; Mon, 15 Jul 2013 05:46:34 -0700 (PDT)
In-Reply-To: <BLU169-W1221AE43EFBADA8B862E43993650@phx.gbl>
References: <CA+9kkMBuCTdFsUMtmuBz6BnrSJMpHywEZU+x+m8ARnGprvzDzA@mail.gmail.com> <CABkgnnXOa44ZkZj-g6r7Qdk8dwm6m81yT4U=Q23-hE1Q7Hn22w@mail.gmail.com> <F9556428-B6B8-407D-9D62-9A1CC04D4253@oracle.com> <B2DF729D-B313-4D3E-9C06-DA00AF7A14FF@oracle.com> <BLU169-W1221AE43EFBADA8B862E43993650@phx.gbl>
From: Peter Thatcher <pthatcher@google.com>
Date: Mon, 15 Jul 2013 05:46:34 -0700
Message-ID: <CAJrXDUHiroZg8rNeTTjz6J2a6__hDW7+3a5NDr3A88PSjfdo_Q@mail.gmail.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>
Content-Type: multipart/alternative; boundary=047d7b111cff82ace904e18c427f
X-Gm-Message-State: ALoCoQmSBi++x2T5M2XBEboCr94mcS5r5h108T4HwEn5QqjymgA7YxTliLtnwpMxT12IU/nbOr3mYNgD/pN1tSuTr5JNCHz2UREp2StDPUVycFKZtdJXtG+KsGvIo/kB27SDOaK1zArPZC47NQnQ09N4TqG8Iy4ZuwGM7J7UXKWlIIHBoVLGzkWFRT+TanoXrGDrJWaslAR+
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] A compromise for SDES
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: Mon, 15 Jul 2013 12:47:17 -0000

On Sat, Jul 13, 2013 at 2:02 PM, Bernard Aboba <bernard_aboba@hotmail.com>wrote;wrote:

> Hadriel --
>
> I think you've brought up a critical point, which is very worth keeping in
> mind throughout the discussions in IETF RTCWEB.  That is that WebRTC is
> really two distinct innovations -- one, a profile of "RAI 2.0"
> functionality, defining a core set of RTP functionality developed over the
> last decade (e.g. end-to-end security, adaptive HD codecs, AVPF, etc.), and
> the other, a set of Javascript APIs for Web browsers defined by the W3C.   IMHO,
>  the "RAI 2.0" aspect is likely to prove more important (and long-lived)
> than the W3C WEBRTC API aspect.
>
> Since the "RAI 2.0" profile developed by the IETF RTCWEB WG is likely to
> live on way beyond the useful life of the W3C WEBRTC APIs, it is critical
> that the protocol profiles not be distorted so as to cater to API concerns
> that will be difficult to justify, let alone remember, a decade from now.
> If the damage brought about by an SDP-based API could be restricted
> solely to Web browsers without reflecting itself in expected "on the wire"
> behavior, I would care a lot less about it.  After all, the Internet
> knows how to deal with bad designs -  it just "treats them as damage and
> routes around them".    So to the extent that IETF RTCWEB can contain the
> SDP API swamp we'll all be better off -- and the swamp will be that much
> easier to drain down the road once it becomes clear to all that nobody
> really wants to live in that part of town anyway.
>
>



> As you state, the vast majority of customers I talk to are interested
> primarily in the "RAI 2.0" aspects of WebRTC, and only secondarily, if at
> all, in the W3C JS APIs.  Given the displacement of feature phones by
> smartphones, the growth in availability of wireless data as well as the
> increasing availability of connectivity that can support interactive video
> (all areas of very rapid growth over the next few years), the focus of
> realtime communications app developers I talk to is not on browser, but on
> the development of native applications.  And unless HTML5-based approaches
> such as Firefox OS gain traction, that focus is likely to remain.
>
> Given this, the most frequent request I hear is for a usable mobile SDK
> that can offer protocol compatibility with WebRTC implementations on
> browsers.  To succeed, that mobile SDK had better not look anything like
> the W3C WEBRTC API, and it also better support extensibility.
>

Chrome's implementation of WebRTC, which can be found at webrtc.org, has a
mobile SDK that can be used to build mobile apps (Android and iOS, at
least).  Some well-known and popular RTC mobile apps are in large part
built on that code and can interop to a degree with browsers.  So in some
sense, you already have what you want.

The big problem is that the high-level API offered by that SDK exactly
matches the one in the browser, which means it's the gross SDP-based one.
 And none of the mobile apps I know, beyond an example app, use that API,
or have plans to, precisely because it's gross.  Instead, as far as I know,
they dig deeper into the code and avoid that part. (why jam everything
through SDP if you don't have to?).

I think the optimal scenario for us to target is to define a good API that
is the same between mobile and web browsers.  I think that would help
developers the most.  Making such a "web and mobile" API is probably out of
scope for any WG, but I think that if we defined a good (non SDP-based) API
for the browser, it could easily be exposed as a native SDK (just like it
is now), but be much less gross and more usable.

I don't know if such a thing (a good API for both mobile and web) can
realistically ever happen, but in the meantime, you can at least pick up
the code at webrtc.org and make a mobile app.  It's open source, too, so if
you want to make a better API than what's there, go ahead and write one :).





In reality, all that the IETF RTCWEB profile defines is the core set of
> functionality -- that set of features that MUST be supported to enable
> interoperability.  However, there is a lot more that a developer might want
> to have available for their particular application.  That might include a
> codec (such as AMR-NB) or a security variant such as SDES/SRTP.   Since as
> you note many developers aren't going to be using the W3C WEBRTC APIs
> anyway, whether those additional functions are supported in the W3C APIs is
> largely irrelevant - and so are discussions about whether this or that
> additional feature needs to be a "SHOULD" or a "MAY".
>

FYI, the code at webrtc.org supports SDES/SRTP, and while it doesn't have
support for AMR-NB (as far as I know), it does have a system for adding new
codecs, so you could theoretically take an implementation of AMR-NB and
compile it in yourself to make a mobile app.  It may not be very easy, but
it is possible.


>
>
> > So given that background, I was planning to propose that the security
> doc keep DTLS-SRTP as the only MTI mechanism for browsers, BUT to add a
> statement that web-based application frameworks SHOULD also support SDES.
> (with text about why and how, etc.)
> >
> > I don't think this is too controversial, because web-based frameworks
> are never beholden to following browser behavior anyway - they're used to
> build a native application, and native applications have a very different
> security/threat model in practice. They're written for a specific purpose,
> and installed by users from known sources for that known purpose.
> Technically, afaik, nothing we do in RTCWEB WG or W3C's WEBRTC group have
> any requirements/mandates for native applications anyway - an app maker
> would just ignore something they don't think applies to them - but I think
> web-based frameworks do generally try to follow W3C models for Javascript
> APIs, and will likely read the IETF RFCs for the media-layer stuff too. So
> I think having this SHOULD statement would be beneficial.
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>