Re: [tram] stun-origin status==? Is it dead?
Harald Alvestrand <hta@google.com> Thu, 19 January 2017 16:57 UTC
Return-Path: <hta@google.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3611A129471 for <tram@ietfa.amsl.com>; Thu, 19 Jan 2017 08:57:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.198
X-Spam-Level:
X-Spam-Status: No, score=-5.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwRglS4NR_WS for <tram@ietfa.amsl.com>; Thu, 19 Jan 2017 08:57:16 -0800 (PST)
Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAE7E129470 for <tram@ietf.org>; Thu, 19 Jan 2017 08:57:15 -0800 (PST)
Received: by mail-yb0-x231.google.com with SMTP id j82so26402694ybg.1 for <tram@ietf.org>; Thu, 19 Jan 2017 08:57:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tbAZaz1JPM0RhFISMl22loY/qgnIvw/dH0U6V1+JWXE=; b=Z8bKWUAn9wK4vIkCeqQWNtnmW2tAHs7LZCUYlqioPIXo3OEHE3P+LW2cAi92dSOJ+o mVsTqgDBH9PbNfWZZuTtq8AwNnMyMh7ccJ9Qc8u/TX597LFqUTta43meHBZimAqcfEGJ OvXnFCvnd9vX1UxEb5DVEaq0+lLNH2ieOFbge1AkeVqDWHnK+wZeKtQrJENM+5mDo/oF 6z4tMNzD4qL8xRNeynWMKjAEuQHT+cT5tROyX6Na5d0KvFrEBeh6pe1q4F63BE8bgYUP 3LXmZ655LEUsHkWZhQQc4bHO/3gXv/pSUdi9PTM31fJCZXO80fO7bMjozC/XdmJv8Tme 4njQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tbAZaz1JPM0RhFISMl22loY/qgnIvw/dH0U6V1+JWXE=; b=tsQM1ySlnPoNzYWLj1dYnvtJXV0JMjrZ38G6bUn6I2MZpl8v+Scichc0b0upyA7wR6 vFlivgSIxSmuUPAwpoHKVOoxhZ/5T4EJlFM7x7CBlzHcl+NDgDByVkUyNfGnatqlaKXo SHh8RS3u4rKK0vrq2kbAuVHoA4Xj5kIqlKFdCELnwGdgKifnMWaDVncBv8n2iPQWHW18 w/KXOkle+4C0wGoUTVNjLJsllv46XvP3eaqT35tL0ZT7hnyaxrcfNy5rM3wYywukSskX zGB4Ol4/8UGT/9YNdky2sjvbvXyjF5isP6EVJvLzl8HxIOn4OVLsjh+tW2h5T5VMb8m/ kU0w==
X-Gm-Message-State: AIkVDXJQ89d3/Xdvk0n0bCKHGza45272NfvSUERlp9gcB3xG2vOFq1qppWhigtIInbxbUF/dXrSFpk7pqoc7lTnC
X-Received: by 10.37.58.4 with SMTP id h4mr6907193yba.82.1484845034755; Thu, 19 Jan 2017 08:57:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.56.73 with HTTP; Thu, 19 Jan 2017 08:56:53 -0800 (PST)
In-Reply-To: <126902A7-D98E-42E6-AE49-69D39FD46EB9@vidyo.com>
References: <d11e7647-2c3b-f9bd-1228-ac5532835b8b@niif.hu> <CAKhHsXGBXHO0pmtt9M_y96_2LPvwD=ASm84C2pXQNmzdy6qf4A@mail.gmail.com> <9de5a4ca-95a2-7829-08ac-1610c9814c7b@niif.hu> <fb58cb1b-760d-2c83-9bec-2a4cba4ea0a0@jive.com> <f10b6a73-2864-19c9-aa69-d17eae02fb78@niif.hu> <126902A7-D98E-42E6-AE49-69D39FD46EB9@vidyo.com>
From: Harald Alvestrand <hta@google.com>
Date: Thu, 19 Jan 2017 17:56:53 +0100
Message-ID: <CAOqqYVEqBkJ-j96X8kBAf6Q2Znsxd85p6kvGohcw775Zdkcg6Q@mail.gmail.com>
To: Jonathan Lennox <jonathan@vidyo.com>
Content-Type: multipart/alternative; boundary="001a114c713cd8695c0546756c0d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/vEdi2Jq7oso1zqdPrnhl-8NbEag>
Cc: Oleg Moskalenko <mom040267@gmail.com>, "juberti@webrtc.org" <juberti@webrtc.org>, "tram@ietf.org" <tram@ietf.org>, Mészáros Mihály <misi@niif.hu>, Simon Perreault <sperreault@jive.com>, "deadbeef@webrtc.org" <deadbeef@webrtc.org>, Alan Johnston <alan.b.johnston@gmail.com>
Subject: Re: [tram] stun-origin status==? Is it dead?
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jan 2017 16:57:17 -0000
I think we need to have a writeup on: 1) What it's legitimate for the STUN service provider to learn about the user 2) What it's NOT legitimate for the STUN service provider to learn about the user Possibly scoped by scenario. Usually, if something dies because "it's a privacy violation", we can't get any further without some privacy analysis. On Thu, Jan 19, 2017 at 5:43 PM, Jonathan Lennox <jonathan@vidyo.com> wrote: > The other proposal that was made to replace the ORIGIN attribute was a > HOST attribute — this would be a way for a STUN / TURN client to send the > DNS name it used to lookup the server, and thus do virtual hosting more > directly. This would have similar security properties to SNI in TLS. It > would allow virtual hosting, without exposing nearly as much information as > ORIGIN would. > > However, I don’t know if anything ever came of this. > > Of course, if you’re using TURN over TLS or DTLS, the TLS SNI field itself > will also allow you to do virtual hosting. > > > On Jan 19, 2017, at 3:20 AM, Mészáros Mihály <misi@niif.hu> wrote: > > > > 2017-01-18 23:21 keltezéssel, Simon Perreault írta: > >> Le 2017-01-18 à 07:48, Mészáros Mihály a écrit : > >>> Do you know any alternatives/workaround to use TURN server with > multiple > >>> realms? > >> OAuth does the trick. > >> https://tools.ietf.org/html/rfc7635 > >> > > Hello Simon, > > > > Despite You are right multiple Auth Server could use with one TURN > > server, but on the wire even in OAuth case, STUN/TURN still use TURN > > server default realm with the mac_key. > > > > And may some TURN server client would like to have a fully customized > > realm according their own domain and hide the TURN service provider > "realm". > > So even in case of OAuth it could have benefit to find solution to > > mutlidomain TURN. > > > > But the main point that unfortunately OAuth is not implemented and used > > in real world actually AFAIK. > > Furthermore even in STUN-bis I could see that the LTC password auth is > > still exists. And this way if I understand it correctly the > > username+password auth will not fade out very soon. > > > > All in all, I still feel the need to find a solution for multidomain > TURN. > > I need your help: Would it be possible to work according my idea that > > (almost) address the concern that raised against ORIGIN. So stun client > > could send his preferred_realm and TURN server could decide if it > > handles such realm then replaces default realm with the one the user has > > preferred/requested? > > > > Do you see any weakens problem with this idea? > > > > Thx, > > Misi > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > > >
- [tram] stun-origin status==? Is it dead? Mészáros Mihály
- Re: [tram] stun-origin status==? Is it dead? Alan Johnston
- Re: [tram] stun-origin status==? Is it dead? Mészáros Mihály
- Re: [tram] stun-origin status==? Is it dead? Simon Perreault
- Re: [tram] stun-origin status==? Is it dead? Mészáros Mihály
- Re: [tram] stun-origin status==? Is it dead? Jonathan Lennox
- Re: [tram] stun-origin status==? Is it dead? Harald Alvestrand
- Re: [tram] stun-origin status==? Is it dead? Mészáros Mihály