Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls)

Cullen Jennings <> Wed, 28 September 2011 15:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66B4111E8086 for <>; Wed, 28 Sep 2011 08:00:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.066
X-Spam-Status: No, score=-103.066 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lf32i20PTHfZ for <>; Wed, 28 Sep 2011 08:00:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id ADF0721F8B22 for <>; Wed, 28 Sep 2011 08:00:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2576; q=dns/txt; s=iport; t=1317222179; x=1318431779; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=H2GkFQbbUQgc9tT0YupiCi1g8r1cN0cPV2dfz0HJRYw=; b=QvIytNn2G5xKFbO4x6XHrs/3wRi2tHYotgs09zZN/22tX+tvi8w+C4q+ RHIAldsugx7umDUZWTLUnI6JctUvSS5Qz7M9WvK53GdUXAbzaXtutoCIf WQRc2Z26p/BNU82+d+daiBH9zwN0DeqkRdAJYFXD1rVYyXxuMunZA48os I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EALk2g06rRDoH/2dsb2JhbABBqAl4gVMBAQEBAgEBAQEPASc0CwULCxguJzAGExsHh1YGmhgBnh4DhithBIdyi2OFIowy
X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="4784731"
Received: from ([]) by with ESMTP; 28 Sep 2011 15:02:59 +0000
Received: from [] ( []) by (8.14.3/8.14.3) with ESMTP id p8SF2wUZ002230; Wed, 28 Sep 2011 15:02:58 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Cullen Jennings <>
In-Reply-To: <>
Date: Wed, 28 Sep 2011 09:02:58 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <4E82A7A8.7060308@j>
To: Randell Jesup <>
X-Mailer: Apple Mail (2.1084)
Subject: Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls)
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: Wed, 28 Sep 2011 15:00:11 -0000

On Sep 27, 2011, at 10:50 PM, Randell Jesup wrote:

> I've been staying out of this one, but one comment:
> On 9/27/2011 7:30 PM, Eric Rescorla wrote:
>> I don't know what "trust agreements with specific web sites" means.
>> The basic situation here is that browser vendors do not want to ship browsers
>> which can be used as an attack platform. And since the victim is not the user
>> but rather the recipient of the traffic, that's why WebSockets and CORS
>> require that the server (i.e., the recipient of the traffic) confirm its willingness
>> to receive the traffic, as opposed to having the user agree to it. I don't see
>> how any trust mechanism that doesn't involve the recipient can have the
>> right security properties.
> Is there any way we could leverage something similar to CORS to allow
> destinations to specify they're willing to take traffic in some manner
> other than per-connection ICE?

Randell, I have thought about this awhile back and what I come up with is something that has very close to the same messages as ICE. In addition, this new thing would have to be deployed on all the end points - so it would be even hard to get deployed than ICE and I doubt it would end up being any easier - and that just to solve the security problem. You still have to solve the nat  traversal problem and things like transition to v6. So, I'd be happy to talk about ideas on this, but when I drew the "boxes and arrows" diagram for something like CORS for RTP, it did not come out looking any easier than ICE, and in fact it looked awfully close to the "boxes and arrows" for ICE. Give it a try on a napkin and see if you come to the roughly the same conclusion. 

> This could be a lot simpler for PBXes, gateways, and the like to
> implement than ICE/SRTP/etc.
> The general idea would be to try ICE, and if the other side doesn't
> do ICE, check a CORS-equivalent at the same same address on a port
> (the port could be specified in DNS SRV records perhaps, or even an
> alternate address to use to check).  If it says it's willing to
> accept webrtc traffic without verification, great.  (This could be
> additionally secured by requiring the server to mark the app/service
> as known to be acceptable in the CORS data.)
> -- 
> Randell Jesup
> _______________________________________________
> rtcweb mailing list