Re: [rtcweb] Single-origin and consent

Harald Alvestrand <> Thu, 20 October 2011 18:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BBF1021F8BA6 for <>; Thu, 20 Oct 2011 11:14:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j+SX+K1TA5oT for <>; Thu, 20 Oct 2011 11:14:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E251621F8B89 for <>; Thu, 20 Oct 2011 11:14:20 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B0A839E16F for <>; Thu, 20 Oct 2011 20:14:20 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b4BRwUJ2JvuF for <>; Thu, 20 Oct 2011 20:14:19 +0200 (CEST)
Received: from [] ( []) by (Postfix) with ESMTPS id 61BA339E072 for <>; Thu, 20 Oct 2011 20:14:19 +0200 (CEST)
Message-ID: <>
Date: Thu, 20 Oct 2011 20:14:18 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
References: <> <BLU152-W43CB8DACCEA54AA5558B2493EA0@phx.gbl> <> <BLU152-W19B31DA6C6DB2FE60FC51C93EB0@phx.gbl> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Single-origin and consent
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Oct 2011 18:14:21 -0000

On 10/20/2011 07:40 PM, Randell Jesup wrote:
> On 10/20/2011 11:36 AM, Eric Rescorla wrote:
>> On Thu, Oct 20, 2011 at 7:32 AM, Bernard Aboba
>> <>  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.
> I'll add a third: Alice and Bob are on the same site, and are 
> participating in a (potentially) multi-person conference run through 
> the site, which is acting as a mixer or at least relay.  Media is sent 
> via normal PeerConnection channels, encrypted with DTLS-SRTP.  In this 
> limited case, each participant is sending media to the same site (*) 
> as the JS code is loaded from.
> So, the questions here would be
> a) can we relax ICE consent checks if the site/app so wishes and
> b) should we?
> I think we can (if the app tells us to, since it's "same-origin" and 
> the app should know), but I'm a little less certain of the "should".  
> Is there an attack wherein someone could 'host' some JS content (app) 
> on a site and use it to attack/DoS that site from multiple places?  It 
> seems at least plausible.

My paranoid self comes up with two, and warns me that there may be 

1) if the "site" is in fact a NAT box, AND the attacker is able to get a 
whole TCP port number on that box AND allow incoming connections....

THEN the attacker can "host" a web server at natbox-ip:hisportnumber, 
and freely use the "same site" criterion to get people to DOS other 
users of the same NAT box.

2) if the "site" is identified by domain name, and the attacker owns the 
domain name, and the attacker can dynamically switch between two 
short-TTL A records for the "site"....

THEN the attacker can let the "helper" load up the page and Javascript 
from the attacking site, switch the A record around to point at his 
victim, and have the attack go to the victim's IP address.

I'm sure people with larger experience in paranoia than I have can come 
up with other scenarios. Or possibly come up with a defense against 
these and other threats that is cheaper than ICE.

But until then ..... I don't think we should.