Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt

Philipp Hancke <> Tue, 20 August 2013 06:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 359F911E819D for <>; Mon, 19 Aug 2013 23:48:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rWTGGnqTZ3Ay for <>; Mon, 19 Aug 2013 23:48:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 101EA11E81B8 for <>; Mon, 19 Aug 2013 23:48:43 -0700 (PDT)
Received: from (localhost []) by (8.14.3/8.14.3/Debian-9.4) with ESMTP id r7K6mV39008825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Aug 2013 08:48:31 +0200
Received: from localhost (fippo@localhost) by (8.14.3/8.14.3/Submit) with ESMTP id r7K6mVsW008821; Tue, 20 Aug 2013 08:48:31 +0200
X-Authentication-Warning: fippo owned process doing -bs
Date: Tue, 20 Aug 2013 08:48:31 +0200
From: Philipp Hancke <>
To: Bernard Aboba <>
In-Reply-To: <BLU169-W11E1423497EE1A503309E793430@phx.gbl>
Message-ID: <>
References: <>, <>, <> <BLU169-W11E1423497EE1A503309E793430@phx.gbl>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="683466026-614398362-1376981311=:8568"
Cc: "" <>
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt
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: Tue, 20 Aug 2013 06:48:56 -0000

> > Most -- but not all -- of the security obtained with TURN over TLS is achieved with TURN REST (draft-uberti-behave-turn-rest and draft-uberti-rtcweb-turn-rest). I think the working group should consider if TURN REST satisfies the requirements, or if TURN over TLS
> is really, really necessary.
> [BA] Not sure I follow this.   TURN over TLS provides confidentiality for the relay addresses and also some firewall traversal benefits.  TURN REST is trying to solve a different problem entirely (e.g. misuse of TURN credentials).  Personally, I don't think TURN REST
> really minimizes the risk to the extent necessary, since time limiting the credentials alone won't necessarily stop an ingenious (and greedy) thief.  As an example, when hackers gain control of a PBX they can run up shocking bills in a very short period of time, and
> even if TURN charges are minimal, you'd be surprised at what Internet miscreants can do with stolen credentials within a 24 hour period.  So to my mind, TURN REST needs some additional bolstering to limit the potential financial liability, such as bandwidth limits. 

Note that the 24 hours are something that is currently necessary because 
browsers don't implement updateIce yet (which would be used to add the 
TURN server and the time limited credentials). Once that is solved it is 
possible to to reduce the attackers window to a couple of seconds.