Return-Path: <bernard_aboba@hotmail.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 F034621F8C96 for <rtcweb@ietfa.amsl.com>;
 Thu, 20 Oct 2011 09:18:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.196
X-Spam-Level: 
X-Spam-Status: No, score=-102.196 tagged_above=-999 required=5 tests=[AWL=0.402,
 BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 gfiTJWIei6Q8 for
 <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 09:18:51 -0700 (PDT)
Received: from blu0-omc2-s33.blu0.hotmail.com (blu0-omc2-s33.blu0.hotmail.com
 [65.55.111.108]) by ietfa.amsl.com (Postfix) with ESMTP id 84FDA21F8C69 for
 <rtcweb@ietf.org>; Thu, 20 Oct 2011 09:18:51 -0700 (PDT)
Received: from BLU152-W19 ([65.55.111.73]) by blu0-omc2-s33.blu0.hotmail.com
 with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Oct 2011 09:18:51 -0700
Message-ID: <BLU152-W193B71A526BF586301C55B93EB0@phx.gbl>
Content-Type: multipart/alternative;
 boundary="_7db1a15e-2022-4fd7-bd42-308b78186637_"
X-Originating-IP: [24.17.217.162]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <ekr@rtfm.com>
Date: Thu, 20 Oct 2011 09:18:50 -0700
Importance: Normal
In-Reply-To: <CABcZeBNbSk-4kfzNtXUSnFMhkcockTXudAYzEET30a0v+-kxBA@mail.gmail.com>
References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org>,
 <BLU152-W43CB8DACCEA54AA5558B2493EA0@phx.gbl>
 <E857C96A-0E73-486F-BF23-36BA897B449C@cisco.com>,
 <BLU152-W19B31DA6C6DB2FE60FC51C93EB0@phx.gbl>,
 <CABcZeBNbSk-4kfzNtXUSnFMhkcockTXudAYzEET30a0v+-kxBA@mail.gmail.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 20 Oct 2011 16:18:51.0215 (UTC)
 FILETIME=[F45BF5F0:01CC8F43]
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 16:18:53 -0000

--_7db1a15e-2022-4fd7-bd42-308b78186637_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



> 1. Alice and Bob are on the same site (e.g.=2C PokerStars) and are
> calling each other via P2P media=2C
> 2. Alice and Bob are on the same site and are calling each other
> via media over WS.
>=20
> In the first case=2C 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=2C we still
> cannot trust the site to adequately verify consent=2C so we clearly need
> ICE. As for the need for E2E security=2C this seems equally important reg=
ardless of whether
> Alice and Bob share the same site.

[BA] I agree.  Where there is P2P media=2C  ICE is required.
=20
> In the second case=2C I agree that you don't need to verify consent becau=
se it's
> implicit in the WS protocol. (I'm leaving aside the question of whether u=
sing WS
> this way is advisable)=2C but the need for E2E security seems equal if
> not greater=2C since in this case the site would have direct access to th=
e media.

[BA] Yes=2C that was my point.=20
 		 	   		  =

--_7db1a15e-2022-4fd7-bd42-308b78186637_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Tahoma
}
--></style>
</head>
<body class=3D'hmmessage'><div dir=3D'ltr'>
<br><div>&gt=3B 1. Alice and Bob are on the same site (e.g.=2C PokerStars) =
and are<br>&gt=3B calling each other via P2P media=2C<br>&gt=3B 2. Alice an=
d Bob are on the same site and are calling each other<br>&gt=3B via media o=
ver WS.<br>&gt=3B <br>&gt=3B In the first case=2C I don't see why this woul=
d allow us to relax any of<br>&gt=3B the security requirements. As long as =
Alice and Bob are sending media to each other=2C we still<br>&gt=3B cannot =
trust the site to adequately verify consent=2C so we clearly need<br>&gt=3B=
 ICE. As for the need for E2E security=2C this seems equally important rega=
rdless of whether<br>&gt=3B Alice and Bob share the same site.<br><br>[BA] =
I agree.&nbsp=3B Where there is P2P media=2C&nbsp=3B ICE is required.<br>&n=
bsp=3B<br>&gt=3B In the second case=2C I agree that you don't need to verif=
y consent because it's<br>&gt=3B implicit in the WS protocol. (I'm leaving =
aside the question of whether using WS<br>&gt=3B this way is advisable)=2C =
but the need for E2E security seems equal if<br>&gt=3B not greater=2C since=
 in this case the site would have direct access to the media.<br><br>[BA] Y=
es=2C that was my point. <br></div> 		 	   		  </div></body>
</html>=

--_7db1a15e-2022-4fd7-bd42-308b78186637_--
