Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for?

Eric Rescorla <ekr@rtfm.com> Thu, 20 October 2011 15:37 UTC

Return-Path: <ekr@rtfm.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 4A27021F8C8C for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 08:37:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.958
X-Spam-Level:
X-Spam-Status: No, score=-102.958 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 YRAkl5aABARt for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 08:37:34 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B4A9C21F8C8A for <rtcweb@ietf.org>; Thu, 20 Oct 2011 08:37:34 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so3093296vcb.31 for <rtcweb@ietf.org>; Thu, 20 Oct 2011 08:37:34 -0700 (PDT)
Received: by 10.52.182.39 with SMTP id eb7mr10053697vdc.12.1319125054091; Thu, 20 Oct 2011 08:37:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.161.20 with HTTP; Thu, 20 Oct 2011 08:36:54 -0700 (PDT)
In-Reply-To: <BLU152-W19B31DA6C6DB2FE60FC51C93EB0@phx.gbl>
References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> <BLU152-W43CB8DACCEA54AA5558B2493EA0@phx.gbl> <E857C96A-0E73-486F-BF23-36BA897B449C@cisco.com> <BLU152-W19B31DA6C6DB2FE60FC51C93EB0@phx.gbl>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 20 Oct 2011 08:36:54 -0700
Message-ID: <CABcZeBNbSk-4kfzNtXUSnFMhkcockTXudAYzEET30a0v+-kxBA@mail.gmail.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for?
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: Thu, 20 Oct 2011 15:37:35 -0000

On Thu, Oct 20, 2011 at 7:32 AM, Bernard Aboba
<bernard_aboba@hotmail.com> wrote:
> No, I'm saying that *if* a developer remains within the "single origin"
> model, that a number of requirements for peer-to-peer operation do not
> apply.
>
> Also that the APIs should also enable media to be sent over a websocket to
> the "single origin" as well as a PeerConnection.
>

I don't think I'm following you're argument. ISTM that there are two
conditions that one
might term "single origin":

1. Alice and Bob are on the same site (e.g., PokerStars) and are
calling each other via P2P media,
2. Alice and Bob are on the same site and are calling each other
via media over WS.

In the first case, I don't see why this would allow us to relax any of
the security
requirements. As long as Alice and Bob are sending media to each other, we still
cannot trust the site to adequately verify consent, so we clearly need
ICE. As for
the need for E2E security, this seems equally important regardless of whether
Alice and Bob share the same site.

In the second case, I agree that you don't need to verify consent because it's
implicit in the WS protocol. (I'm leaving aside the question of whether using WS
this way is advisable), but the need for E2E security seems equal if
not greater,
since in this case the site would have direct access to the media.

-Ekr