Re: [pntaw] TURN over websockets

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sat, 31 August 2013 18:53 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: pntaw@ietfa.amsl.com
Delivered-To: pntaw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F0321E80E4 for <pntaw@ietfa.amsl.com>; Sat, 31 Aug 2013 11:53:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 GUsfHzMCFprh for <pntaw@ietfa.amsl.com>; Sat, 31 Aug 2013 11:53:12 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B61FF21E80DF for <pntaw@ietf.org>; Sat, 31 Aug 2013 11:53:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BA66ABEBE; Sat, 31 Aug 2013 19:53:09 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaBnlJl1a5Wd; Sat, 31 Aug 2013 19:53:08 +0100 (IST)
Received: from [10.87.48.15] (unknown [86.46.20.4]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 381F3BEB3; Sat, 31 Aug 2013 19:53:08 +0100 (IST)
Message-ID: <52223B93.5030401@cs.tcd.ie>
Date: Sat, 31 Aug 2013 19:53:07 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Martin Thomson <martin.thomson@gmail.com>
References: <52205AE1.9010807@gmail.com> <F81CEE99482EFE438DAE2A652361EE12179BF94B@MCHP04MSX.global-ad.net> <5220968E.2050708@gmail.com> <004e01cea666$98e9b090$cabd11b0$@co.in> <CABkgnnVt-VscwN4r_FovqCYqARxz2YmnBihwvzf6FXPcKcTz1Q@mail.gmail.com>
In-Reply-To: <CABkgnnVt-VscwN4r_FovqCYqARxz2YmnBihwvzf6FXPcKcTz1Q@mail.gmail.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, pntaw@ietf.org, Parthasarathi R <partha@parthasarathi.co.in>, "Stach, Thomas" <thomas.stach@siemens-enterprise.com>
Subject: Re: [pntaw] TURN over websockets
X-BeenThere: pntaw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <pntaw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pntaw>, <mailto:pntaw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pntaw>
List-Post: <mailto:pntaw@ietf.org>
List-Help: <mailto:pntaw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pntaw>, <mailto:pntaw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 Aug 2013 18:53:19 -0000

On 08/31/2013 06:33 PM, Martin Thomson wrote:
> On 31 August 2013 09:24, Parthasarathi R <partha@parthasarathi.co.in> wrote:
>> In case of (firewall) Policy vs protocol, the policy is the final decision
>> maker and not the protocol. In case TURN over WebSocket is chosen, it is a
>> matter of time for firewall policy enhancement to block these rat holes in
>> the network.
> 
> I'm glad someone raised this point.  It's core to the discussion.
> What, if any, visibility will a firewall or proxy be given into the
> purpose of this exchange?   HTTP CONNECT followed by TLS doesn't give
> the intermediary much of a chance to enforce policy.

Just a note on this: Proposed solutions that require a man in the
middle attack on TLS are not likely to fare well. The security ADs
(incl me:-) are *very* strongly against messing about with TLS like
that. So I hope this design team effort (or whatever it is) don't
go down that road. And of course there's no need to go there either,
if you want to know what WebRTC stuff is going on, then there should
be fine WebRTC ways to do that that don't involve a TLS MITM attack.

Cheers,
S.

> _______________________________________________
> pntaw mailing list
> pntaw@ietf.org
> https://www.ietf.org/mailman/listinfo/pntaw
>