Return-Path: 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 ; 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 ; 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 ; Thu, 19 Jan 2017 08:57:15 -0800 (PST) Received: by mail-yb0-x231.google.com with SMTP id j82so26402694ybg.1 for ; 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: <9de5a4ca-95a2-7829-08ac-1610c9814c7b@niif.hu> <126902A7-D98E-42E6-AE49-69D39FD46EB9@vidyo.com> From: Harald Alvestrand Date: Thu, 19 Jan 2017 17:56:53 +0100 Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=001a114c713cd8695c0546756c0d Archived-At: Cc: Oleg Moskalenko , "juberti@webrtc.org" , "tram@ietf.org" , =?UTF-8?B?TcOpc3rDoXJvcyBNaWjDoWx5?= , Simon Perreault , "deadbeef@webrtc.org" , Alan Johnston 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 16:57:17 -0000 --001a114c713cd8695c0546756c0d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 wrote= : > The other proposal that was made to replace the ORIGIN attribute was a > HOST attribute =E2=80=94 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=E2=80=99t know if anything ever came of this. > > Of course, if you=E2=80=99re using TURN over TLS or DTLS, the TLS SNI fie= ld itself > will also allow you to do virtual hosting. > > > On Jan 19, 2017, at 3:20 AM, M=C3=A9sz=C3=A1ros Mih=C3=A1ly wrote: > > > > 2017-01-18 23:21 keltez=C3=A9ssel, Simon Perreault =C3=ADrta: > >> Le 2017-01-18 =C3=A0 07:48, M=C3=A9sz=C3=A1ros Mih=C3=A1ly a =C3=A9cri= t : > >>> 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 ha= s > > 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 > > > > --001a114c713cd8695c0546756c0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 provid= er to learn about the user

Possibly scoped by scen= ario.
Usually, if something dies because "it's a privacy= violation", we can't get any further without some privacy analysi= s.


On Thu, Jan 19, 2017 at 5:43 PM, Jonathan Lennox <jonathan@vi= dyo.com> wrote:
The other p= roposal that was made to replace the ORIGIN attribute was a HOST attribute = =E2=80=94 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.= =C2=A0 This would have similar security properties to SNI in TLS.=C2=A0 It = would allow virtual hosting, without exposing nearly as much information as= ORIGIN would.

However, I don=E2=80=99t know if anything ever came of this.

Of course, if you=E2=80=99re 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=C3=A9sz=C3=A1ros Mih=C3=A1ly <misi@niif.hu> wrote:
>
> 2017-01-18 23:21 keltez=C3=A9ssel, Simon Perreault =C3=ADrta:
>> Le 2017-01-18 =C3=A0 07:48, M=C3=A9sz=C3=A1ros Mih=C3=A1ly a =C3= =A9crit :
>>> Do you know any alternatives/workaround to use TURN server wit= h 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<= br> > realm according their own domain and hide the TURN service provider &q= uot;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 use= d
> 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 T= URN.
> I need your help: Would it be possible to work according my idea that<= br> > (almost) address the concern that raised against ORIGIN. So stun clien= t
> could send his preferred_realm and TURN server could decide if it
> handles such realm then replaces default realm with the one the user h= as
> 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 >


--001a114c713cd8695c0546756c0d--