Re: [rtcweb] URI schemes for TURN and STUN
Eric Rescorla <ekr@rtfm.com> Sun, 30 October 2011 14:29 UTC
Return-Path: <ekr@rtfm.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 81FB921F8497; Sun, 30 Oct 2011 07:29:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.96
X-Spam-Level:
X-Spam-Status: No, score=-102.96 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 0moZTEPPc0vH; Sun, 30 Oct 2011 07:29:38 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D6F7721F8495; Sun, 30 Oct 2011 07:29:37 -0700 (PDT)
Received: by ggnv1 with SMTP id v1so6040520ggn.31 for <multiple recipients>; Sun, 30 Oct 2011 07:29:37 -0700 (PDT)
Received: by 10.236.77.163 with SMTP id d23mr12446161yhe.34.1319984977447; Sun, 30 Oct 2011 07:29:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.147.124.3 with HTTP; Sun, 30 Oct 2011 07:28:56 -0700 (PDT)
In-Reply-To: <4EACD558.1050003@alvestrand.no>
References: <4EAC6BF4.2000604@alvestrand.no> <CALiegf=f4kFzyDLWK+Y5vbuCEJFXX590+VuZ4bbnHZnvX0CoBA@mail.gmail.com> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 30 Oct 2011 07:28:56 -0700
Message-ID: <CABcZeBM_4Bfiy_Nf2imAWHiry9W+=hWCOOBevXs-n5sv4DGc4A@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Keith Moore <moore@cs.utk.edu>, Ned Freed <ned.freed@mrochek.com>, Behave WG <behave@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] URI schemes for TURN and STUN
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: Sun, 30 Oct 2011 14:29:38 -0000
On Sat, Oct 29, 2011 at 9:40 PM, Harald Alvestrand <harald@alvestrand.no> wrote: > On 10/29/2011 04:23 PM, Marc Petit-Huguenin wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 10/29/2011 03:36 PM, Iñaki Baz Castillo wrote: >>> >>> 2011/10/29 Harald Alvestrand<harald@alvestrand.no>: >>>> >>>> - I do not think it's appropriate to use "turn" and "turns" for >>>> indicating >>>> transport. Polluting the URI namespace with more configuration >>>> parameters in >>>> the form of trailing "s" is a Bad Thing. >>> >>> But there should be some way to indicate that a TURN server listens in >>> TLS, right? >>> >> We should continue this discussion in BEHAVE, but I would like to ask the >> OP to >> send a pointer on the RFC or discussion that says that using a trailing >> "s" to >> indicate security is a bad thing. > > I'll have to forward this question to the apps ADs of a few years ago about > whether there's documentation for it. It does not seem to have been captured > in an RFC that I can find; discussion was in the ~2000-2005 timeframe. > > The short version, from memory: Doing "s" locks you into one and exactly one > security scheme, and prevents you from saying anything about the requisite > parameters for that scheme, while using AUTH parameters such as POP or > in-band negotiation such as IMAP are much more flexible approaches. I haven't formed an opinion on the value of turn[s] URIs one way or another, but... What you say above is absolutely true, but there is a tradeoff here. If you just provide a URI with no indication of the expected security mechanism, and rely on in-band negotiation, then an active attacker can force the client down to the weakest security mechanism (a downgrade attack). So, for instance, if the client supports both TURN and TURN over TLS, the attacker can impersonate a server which supports only TURN and force the client to accept that. By contrast, if the URI indicates a minimal security mechanism that is sufficiently strong, then this form of attack is not possible. Obviously, the user could configure his client to only support secure connections (via whatever mechanism) but this is less convenient. Another point in the design space is to require some specific security mechanism that is strong enough to authenticate the server and then use that mechanism to support secure negotiation of the real mechanism. Unfortunately, the only widely supported mechanism that meets that standard is TLS, so this isn't much of an improvement. -Ekr
- Re: [rtcweb] URI schemes for TURN and STUN Martin J. Dürst
- Re: [rtcweb] URI schemes for TURN and STUN Harald Alvestrand
- [rtcweb] URI schemes for TURN and STUN Harald Alvestrand
- Re: [rtcweb] URI schemes for TURN and STUN Iñaki Baz Castillo
- Re: [rtcweb] URI schemes for TURN and STUN Marc Petit-Huguenin
- Re: [rtcweb] URI schemes for TURN and STUN Iñaki Baz Castillo
- Re: [rtcweb] URI schemes for TURN and STUN Eric Rescorla
- Re: [rtcweb] URI schemes for TURN and STUN Martin J. Dürst
- Re: [rtcweb] URI schemes for TURN and STUN Cullen Jennings
- Re: [rtcweb] URI schemes for TURN and STUN Bernard Aboba
- Re: [rtcweb] URI schemes for TURN and STUN Marc Petit-Huguenin
- Re: [rtcweb] URI schemes for TURN and STUN Martin J. Dürst
- Re: [rtcweb] URI schemes for TURN and STUN Magnus Westerlund
- Re: [rtcweb] URI schemes for TURN and STUN Marc Petit-Huguenin
- Re: [rtcweb] URI schemes for TURN and STUN Harald Alvestrand
- Re: [rtcweb] URI schemes for TURN and STUN Keith Moore
- Re: [rtcweb] URI schemes for TURN and STUN Keith Moore
- Re: [rtcweb] URI schemes for TURN and STUN Keith Moore
- Re: [rtcweb] URI schemes for TURN and STUN Eric Rescorla
- Re: [rtcweb] URI schemes for TURN and STUN Eric Rescorla
- Re: [rtcweb] URI schemes for TURN and STUN Eric Rescorla
- Re: [rtcweb] URI schemes for TURN and STUN Keith Moore
- Re: [rtcweb] URI schemes for TURN and STUN Keith Moore
- Re: [rtcweb] URI schemes for TURN and STUN Ned Freed
- Re: [rtcweb] URI schemes for TURN and STUN Eric Rescorla
- Re: [rtcweb] URI schemes for TURN and STUN Dan Wing
- Re: [rtcweb] [BEHAVE] URI schemes for TURN and ST… Marc Petit-Huguenin
- Re: [rtcweb] [BEHAVE] URI schemes for TURN and ST… Dan Wing
- Re: [rtcweb] URI schemes for TURN and STUN Eric Rescorla
- Re: [rtcweb] [BEHAVE] URI schemes for TURN and ST… Marc Petit-Huguenin
- Re: [rtcweb] URI schemes for TURN and STUN Dan Wing
- Re: [rtcweb] URI schemes for TURN and STUN Harald Alvestrand
- Re: [rtcweb] URI schemes for TURN and STUN Eric Rescorla
- Re: [rtcweb] URI schemes for TURN and STUN Gonzalo Salgueiro
- Re: [rtcweb] [BEHAVE] URI schemes for TURN and ST… Marc Petit-Huguenin
- Re: [rtcweb] [BEHAVE] URI schemes for TURN and ST… Gonzalo Salgueiro
- Re: [rtcweb] [BEHAVE] URI schemes for TURN and ST… Marc Petit-Huguenin
- Re: [rtcweb] URI schemes for TURN and STUN Eric Rescorla
- Re: [rtcweb] URI schemes for TURN and STUN Bjoern Hoehrmann
- Re: [rtcweb] [BEHAVE] URI schemes for TURN and ST… Harald Alvestrand
- Re: [rtcweb] [BEHAVE] URI schemes for TURN and ST… Harald Alvestrand
- Re: [rtcweb] URI schemes for TURN and STUN Harald Alvestrand
- Re: [rtcweb] URI schemes for TURN and STUN Iñaki Baz Castillo
- Re: [rtcweb] URI schemes for TURN and STUN Harald Alvestrand
- Re: [rtcweb] [BEHAVE] URI schemes for TURN and ST… Marc Petit-Huguenin
- Re: [rtcweb] [BEHAVE] URI schemes for TURN and ST… Marc Petit-Huguenin
- Re: [rtcweb] [BEHAVE] URI schemes for TURN and ST… Gonzalo Salgueiro
- Re: [rtcweb] [BEHAVE] URI schemes for TURN and ST… Tina TSOU