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

Randell Jesup <randell-ietf@jesup.org> Wed, 28 September 2011 04:51 UTC

Return-Path: <randell-ietf@jesup.org>
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 9660D21F8CB4 for <rtcweb@ietfa.amsl.com>; Tue, 27 Sep 2011 21:51:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.567
X-Spam-Level:
X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599]
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 qq7DqWb33Srh for <rtcweb@ietfa.amsl.com>; Tue, 27 Sep 2011 21:51:45 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 0A19821F8CAD for <rtcweb@ietf.org>; Tue, 27 Sep 2011 21:51:44 -0700 (PDT)
Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1R8mAB-0005if-TU for rtcweb@ietf.org; Tue, 27 Sep 2011 23:54:31 -0500
Message-ID: <4E82A7A8.7060308@jesup.org>
Date: Wed, 28 Sep 2011 00:50:48 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CAD5OKxtNjmWBz92bRuxka7e-BUpTPgVUvr3ahJGpmZ-U5nuPbQ@mail.gmail.com> <CAD5OKxsKTHCuBQdUnGQtGfF7NmZZExLe9Q9B9cNR=483neuHPQ@mail.gmail.com> <CAOJ7v-1rzdmviAnGknVZmrU_TDNoC3NmWd1g6iyx0WzZ4xB3Pw@mail.gmail.com> <4E820825.9090101@skype.net> <CAD5OKxvmKi3Py0gNcTdREdfS07hA-=f6L+u8KKVgSWztMft9kQ@mail.gmail.com> <CALiegfmL4VSRE+kgs5kXzQc3mCHnKpU-EAbVPKO4QNEYLKje=A@mail.gmail.com> <4E821E47.4080205@alvestrand.no> <CALiegfndBhod6Hoq6h63795x8f=ew28rDys=Fx8ScwVpVJwp1Q@mail.gmail.com> <CABcZeBOoF6MNSpATG2+_e99iRq7Jf9OoWWNCa=qRGW_v+maoHA@mail.gmail.com> <CAD5OKxubnxLAqybCgnBXpKR9S0rBEsoDg9enCaverjVWYad7Ew@mail.gmail.com> <CABcZeBPoQSM=L0-Er3j-ak2M6YfCbJkThbYuR_+=xUmcsxQz9Q@mail.gmail.com> <CAD5OKxsVE+LwKEcpe+hf+=i87Ucga0_VpkUGJkH5=HixV5Xkmw@mail.gmail.com> <CABcZeBM+FD5y7WenD=d_7jM1Fu+OrFyFgtsd1iGMpGfMe_gOKQ@mail.gmail.com> <CAD5OKxte2DYbgtFpF2jQGq_thYCyb1Li2ih5J6gpzamhJvRyTA@mail.gmail.com> <CABcZeBPeFCdVvrgLh_-kcBwbM=knemo_rjKg-gEz9s35CqzPGQ@mail.gmail.com>
In-Reply-To: <CABcZeBPeFCdVvrgLh_-kcBwbM=knemo_rjKg-gEz9s35CqzPGQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls)
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: Wed, 28 Sep 2011 04:51:45 -0000

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?

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
randell-ietf@jesup.org