Re: [rtcweb] Summary of ICE discussion

Hadriel Kaplan <HKaplan@acmepacket.com> Tue, 04 October 2011 16:21 UTC

Return-Path: <HKaplan@acmepacket.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 C35E321F8D8A for <rtcweb@ietfa.amsl.com>; Tue, 4 Oct 2011 09:21:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.215
X-Spam-Level:
X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, J_CHICKENPOX_47=0.6]
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 MSqGm-2z8EZg for <rtcweb@ietfa.amsl.com>; Tue, 4 Oct 2011 09:21:08 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 230E921F8D86 for <rtcweb@ietf.org>; Tue, 4 Oct 2011 09:21:08 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 4 Oct 2011 12:24:12 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Tue, 4 Oct 2011 12:24:13 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Randell Jesup <randell-ietf@jesup.org>
Thread-Topic: [rtcweb] Summary of ICE discussion
Thread-Index: AQHMgrIMhMqMbPzAz0WUIBBDdBYXVQ==
Date: Tue, 04 Oct 2011 16:24:11 +0000
Message-ID: <7EE6A3A6-D628-4EF5-A1E2-FB78C9F8A498@acmepacket.com>
References: <4E8B192E.80809@ericsson.com> <4E8B20BA.3080906@jesup.org>
In-Reply-To: <4E8B20BA.3080906@jesup.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <936360EE1085B144ACC78A5CA2D17C73@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Summary of ICE discussion
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: Tue, 04 Oct 2011 16:21:08 -0000

On Oct 4, 2011, at 11:05 AM, Randell Jesup wrote:

> One observation about the security/attack-vector side of this:  Any objection that includes "if an attacker is in a MITM position they could trick the rtcweb client into sending media" is an invalid objection.  A MITM attacker could inject or re-route any amount of traffic they wanted already if they're in the media path.  I'll also note that an attacker could be in MITM on the signalling side or DNS, but not MITM on the media/ICE routing; those are valid cases to consider.  And DNS poisoning doesn't require MITM.

Excellent - I was hoping someone else would feel that way about a MITM on the media/ICE path.  I'm not sure that's universally agreed on, though: it was the main reason for requiring the hash on the STUN connectivity checks, afaict.

The hard part about this all, frankly, is that we're not allowed to trust the JavaScript.  Since the JavaScript can learn so much, we're stuck with the Browser generating something that the JS can't learn but that the media peer will learn in the media plane only.  The transaction-id of the STUN connectivity check essentially provides that proof that the STUN answer comes from a real media peer willing to participate.  Unfortunately RTP has no such proof, and RTCP has one but I think people have said it's not strong enough? (I can't find where someone said that, but it could be)

Regardless, fundamentally it seems to me W3C and Browser manufacturers have a problem if they can't ever trust JavaScript: plugins and native apps will always be able to do things JS can't do if W3C can't agree on a way for the user+browser to safely say "yes, this really is JS I trust, with the same level of trust/policies I give to plugins/apps".  I don't mean this for all web-page JS downloads of RTCWeb, but rather for specific sites that I would have a long-term relationship with.  For example if I am a Facebook user and Facebook wants to run JS on my browser, I'd be willing to give them control similar to downloading a Facebook app, even if it requires me to follow the same process of consent that downloading an application does.  What about the Mozilla signed scripts model?

For general RTCWeb JS downloads I think requiring ICE and all is fine and good, and frankly I expect most RTCWeb applications to fall in that model and not care about legacy SIP or the PSTN.  But for some RTCWeb cases it will communicate with legacy SIP/PSTN and those are the types of applications that I think would have a longer-term relationship with the user, for which requiring a more stringent JS trust model seems worthwhile to me.

-hadriel