From nobody Thu Dec 10 18:06:40 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696A61A038A for ; Thu, 10 Dec 2015 18:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.387 X-Spam-Level: X-Spam-Status: No, score=-1.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URI_TRY_3LD=0.001] autolearn=no 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 LUdVlwhDLe6D for ; Thu, 10 Dec 2015 18:06:37 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (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 82EC71A037F for ; Thu, 10 Dec 2015 18:06:37 -0800 (PST) Received: by vkay187 with SMTP id y187so107076312vka.3 for ; Thu, 10 Dec 2015 18:06:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=9/z/UXKH3iQ9kq9lX21p98/IKMklCeVocJbt1OZzWeM=; b=Cv9rn4BtoFHVvDBqB7YlrUoQAZaNOwZzpnjU/Yl4fBpf8SrHh08mUKxSMq02K3FFXE 3V4MEkPkADWOZ3xB9yJ3NVix/WKtw3rkljwYyovINQFNtm4tdSIGtP/v/umTFz5Vfr61 m1XGQzy6JgvIjWzWYkxCqrxRFHQ2grZZ+U+xAXGDMEdYZ4E+2bbN3sfkeV3KLO9TDMRe 8R+m7ibs8NkeNJ0voW874bu5ei1gtGOuo6NsZvBKwbJVwVC8tzGVOagmYhqp3GRQ3fHK bO7gxw9mXZ4Sgd4tjzFvjFQiwfabotpxQKs5Fzfep2Sw5755uZtLtiYFTbxSP+vvPTBB RoQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=9/z/UXKH3iQ9kq9lX21p98/IKMklCeVocJbt1OZzWeM=; b=btEKC8YIByaPqiozqCtBunvuW2IOrBrd+hWBDZTyFJGFm7kVpU14VApkUO2h451rwQ HtnX6gaFq5NhHs03f0hHb+FmDvQlxLbTOeE6W0/HKuaa5KLzBjHaJxsDKuYkcczsFsvx YFfs9ViDcmunP69VI+0QQpHW5Bg5B+8aSlsxUGGq/nGDgyO4Jk1as1RgNNAfCsz1qxf6 PZZAKQUMOFXDOzfzE8Gc/pd0CkAI6H9yXRnocFimu9uCaT7W2iMoqduMwW5kO8g25Aeb t8/H7XUA/j/LCyfs64HThB/uxnjDMgGMrYuSEFH369AIjosmu6GUdOg+38/l4n4pwh9I wn5g== X-Gm-Message-State: ALoCoQltUM5Eu1cYW/Q6yPm19OJoKeBB8geBMHgT6ycUteqLN+wAx1WNzrB3ceSjZKFrroAyhOd37x4NSVR43BJPWVwozLkW9LxXYwvLJxc9HwJFi+3WapE= X-Received: by 10.31.8.200 with SMTP id 191mr11673114vki.60.1449799596614; Thu, 10 Dec 2015 18:06:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.219.129 with HTTP; Thu, 10 Dec 2015 18:06:17 -0800 (PST) From: Justin Uberti Date: Thu, 10 Dec 2015 18:06:17 -0800 Message-ID: To: "tram@ietf.org" , Brandon Williams , Alan Johnston Content-Type: multipart/alternative; boundary=001a1142e1e4f3fcd8052695c569 Archived-At: Subject: [tram] Recasting STUN ORIGIN as a 'Host' header X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 11 Dec 2015 02:06:39 -0000 --001a1142e1e4f3fcd8052695c569 Content-Type: text/plain; charset=UTF-8 There was some discussion on this in Yokohama, but I haven't seen it make its way onto the list yet. I think making ORIGIN into something more like HTTP's Host header is a pretty good idea, so here's a quick summary from my perspective. Basically, I propose we get rid of ORIGIN and add a new HOST attribute which carries the DNS name of the TURN server the application wants to connect to (not the application origin). When the server is multi-tenant, the provider can use CNAMEs to set up different DNS names for different customers (e.g. app1.turnprovider.com, app2.turnprovider.com), all pointing to the same multi-tenant TURN server - and use the HOST attribute to identify the application and/or determine which REALM to return. Browsers don't need to do anything special other than adding a single attribute, which comes directly from the supplied TURN URI. No name matching, no multiple origins, no SRV records. This approach also deals effectively with the concerns around the browser disclosing the user's ORIGIN to the TURN provider. Since the app is in charge of what TURN URI it uses, it has control over what is disclosed to the TURN provider - which is just the name in the TURN URI, not the app's origin. For example: consider an app at www.myapp.com, which uses a TURN server at myapp.turnprovider.com (a CNAME for turnserver.turnprovider.com that was provisioned for myapp.com by turnprovider.com). In this case, the HOST attribute would contain "myapp.turnprovider.com", but not "www.myapp.com". Overall, I think this approach solves the core problem ORIGIN was meant to solve (e.g. REALM for multi-tenant servers), avoids the privacy gotchas that have recently come up, and as a bonus, is simpler. --001a1142e1e4f3fcd8052695c569 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There was some discussion on this in Yokohama, but I haven= 't seen it make its way onto the list yet.=C2=A0

I t= hink making ORIGIN into something more like HTTP's Host header is a pre= tty good idea, so here's a quick summary from my perspective.

Basically, I propose we get rid of ORIGIN and add a new HOS= T attribute which carries the DNS name of the TURN server the application w= ants to connect to (not the application origin). When the server is multi-t= enant, the provider can use CNAMEs to set up different DNS names for differ= ent customers (e.g. app1.turnprovi= der.com, app2.turnprovider.com= ), all pointing to the same multi-tenant TURN server - and use the HOST= attribute to identify the application and/or determine which REALM to retu= rn.

Browsers don't need to do anything sp= ecial other than adding a single attribute, which comes directly from the s= upplied TURN URI. No name matching, no multiple origins, no SRV records.

This approach also deals effectively with the = concerns around the browser disclosing the user's ORIGIN to the TURN pr= ovider. Since the app is in charge of what TURN URI it uses, it has control= over what is disclosed to the TURN provider - which is just the name in th= e TURN URI, not the app's origin.

For example:= =C2=A0consider an app at www.myapp.com= , which uses a TURN server at mya= pp.turnprovider.com (a CNAME for turnserver.turnprovider.com that was provisioned for myapp.com by = turnprovider.com). In this case, the HOST attribute would contain "= ;myapp.turnprovider.com"= , but not "www.myapp.com".= =C2=A0

Overall, I think this approach solves the c= ore problem ORIGIN was meant to solve (e.g. REALM for multi-tenant servers)= , avoids the privacy gotchas that have recently come up, and as a bonus, is= simpler.
--001a1142e1e4f3fcd8052695c569-- From nobody Fri Dec 11 05:45:04 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 558EE1A6FC2 for ; Fri, 11 Dec 2015 05:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, URI_TRY_3LD=0.001] autolearn=ham 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 WvZw1VQ3QNdI for ; Fri, 11 Dec 2015 05:44:59 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 0E6161A219C for ; Fri, 11 Dec 2015 05:44:59 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id n186so30139065wmn.1 for ; Fri, 11 Dec 2015 05:44:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tZ5U2cGNTBdGB8lug20gtDb/hd3HYDpxP6o1P3TScFg=; b=kOWlZ3o7DB1DLoGXU0BRjjRb/6kuLe1IbRUHgz/Tm6yXgJUu2Rd70hSfXIRdSPiQsL CWEmlM5cXiGfTheQtpZZwUuBjkgiFTAXK1/7Uzkq9DVySH0+gRIvANYrobfPuDYT+84o Facq9T9aTkRh8skA7bYnr9691Is8PGcoZ8IFdASYVGE696KKq71TQS3IAhOeb29aHS1p mZGSJudxlPRD2W7HmOFXky+DjLPbhHOJAmrkAOaKg1wc9/JMUGrPfuvea2FnOSJzTjs5 /ttdOrgM5gM9sv3AI/p4+jvdCzagvlFGQQvRpoaglAG+e6unI1MTySLTxMZVjZmWS5MH 4HkQ== X-Received: by 10.28.189.5 with SMTP id n5mr6202250wmf.76.1449841497597; Fri, 11 Dec 2015 05:44:57 -0800 (PST) Received: from [10.0.0.9] (bzq-82-80-137-6.red.bezeqint.net. [82.80.137.6]) by smtp.gmail.com with ESMTPSA id az6sm16999824wjc.25.2015.12.11.05.44.55 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Dec 2015 05:44:56 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-C30EC95E-5E3F-4444-BCBB-32FF1A610EAC Mime-Version: 1.0 (1.0) From: Alan Johnston X-Mailer: iPhone Mail (13C75) In-Reply-To: Date: Fri, 11 Dec 2015 15:44:53 +0200 Content-Transfer-Encoding: 7bit Message-Id: <9A0DD478-0392-4A53-B53C-86F0035E7385@gmail.com> References: To: Justin Uberti Archived-At: Cc: "tram@ietf.org" , Brandon Williams Subject: Re: [tram] Recasting STUN ORIGIN as a 'Host' header X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 11 Dec 2015 13:45:02 -0000 --Apple-Mail-C30EC95E-5E3F-4444-BCBB-32FF1A610EAC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Justin, Thanks for posting this.=20 I've been thinking about using HOST as well, but I think this approach gener= ates new meta-data. Essentially, new WebRTC usage information is generated a= t the STUN/TURN server where none was generated before. This is true for bot= h cases: where the URI is the domain of the TURN provider and also where the= domain is the WebRTC provider.=20 Unless a comparison between the HOST and the ORIGIN is made, along the lines= of what I proposed in Yokohama. In this case, all we have done is changed t= he name of the attribute from ORIGIN to HOST. The same info will be sent ov= er the wire.=20 So, regardless if we call it ORIGIN or HOST, the same matching rules will be= needed.=20 - Alan - > On Dec 11, 2015, at 4:06 AM, Justin Uberti wrote: >=20 > There was some discussion on this in Yokohama, but I haven't seen it make i= ts way onto the list yet.=20 >=20 > I think making ORIGIN into something more like HTTP's Host header is a pre= tty good idea, so here's a quick summary from my perspective. >=20 > Basically, I propose we get rid of ORIGIN and add a new HOST attribute whi= ch carries the DNS name of the TURN server the application wants to connect t= o (not the application origin). When the server is multi-tenant, the provide= r can use CNAMEs to set up different DNS names for different customers (e.g.= app1.turnprovider.com, app2.turnprovider.com), all pointing to the same mul= ti-tenant TURN server - and use the HOST attribute to identify the applicati= on and/or determine which REALM to return. >=20 > Browsers don't need to do anything special other than adding a single attr= ibute, which comes directly from the supplied TURN URI. No name matching, no= multiple origins, no SRV records. >=20 > This approach also deals effectively with the concerns around the browser d= isclosing the user's ORIGIN to the TURN provider. Since the app is in charge= of what TURN URI it uses, it has control over what is disclosed to the TURN= provider - which is just the name in the TURN URI, not the app's origin. >=20 > For example: consider an app at www.myapp.com, which uses a TURN server at= myapp.turnprovider.com (a CNAME for turnserver.turnprovider.com that was pr= ovisioned for myapp.com by turnprovider.com). In this case, the HOST attribu= te would contain "myapp.turnprovider.com", but not "www.myapp.com".=20 >=20 > Overall, I think this approach solves the core problem ORIGIN was meant to= solve (e.g. REALM for multi-tenant servers), avoids the privacy gotchas tha= t have recently come up, and as a bonus, is simpler. --Apple-Mail-C30EC95E-5E3F-4444-BCBB-32FF1A610EAC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Justin,

Thanks for posting this. 

I've been thin= king about using HOST as well, but I think this approach generates new meta-= data.  Essentially, new WebRTC usage information is generated at the ST= UN/TURN server where none was generated before. This is true for both cases:= where the URI is the domain of the TURN provider and also where the domain i= s the WebRTC provider. 

Unless a comparison be= tween the HOST and the ORIGIN is made, along the lines of what I proposed in= Yokohama. In this case, all we have done is changed the name of the attribu= te from ORIGIN to HOST.  The same info will be sent over the wire. = ;

So, regardless if we call it ORIGIN or HOST, the s= ame matching rules will be needed. 

- Alan -

On Dec 11, 2015, at 4:06 AM, Justin Uberti <juberti@google.com> wrote:

There was some discussion on this i= n Yokohama, but I haven't seen it make its way onto the list yet. 
=
I think making ORIGIN into something more like HTTP's Host he= ader is a pretty good idea, so here's a quick summary from my perspective.

Basically, I propose we get rid of ORIGIN and add a n= ew HOST attribute which carries the DNS name of the TURN server the applicat= ion wants to connect to (not the application origin). When the server is mul= ti-tenant, the provider can use CNAMEs to set up different DNS names for dif= ferent customers (e.g. app1.turnpro= vider.com, app2.turnprovider.co= m), all pointing to the same multi-tenant TURN server - and use the HOST= attribute to identify the application and/or determine which REALM to retur= n.

Browsers don't need to do anything special o= ther than adding a single attribute, which comes directly from the supplied T= URN URI. No name matching, no multiple origins, no SRV records.
<= div>
This approach also deals effectively with the concerns ar= ound the browser disclosing the user's ORIGIN to the TURN provider. Since th= e app is in charge of what TURN URI it uses, it has control over what is dis= closed to the TURN provider - which is just the name in the TURN URI, not th= e app's origin.

For example: consider an app a= t www.myapp.com, which uses a TURN serv= er at myapp.turnprovider.com (= a CNAME for turnserver.turnpr= ovider.com that was provisioned for myapp.c= om by turnprovider.com). In this= case, the HOST attribute would contain "myapp.turnprovider.com", but not "www.myapp.com". 

Overall, I think this a= pproach solves the core problem ORIGIN was meant to solve (e.g. REALM for mu= lti-tenant servers), avoids the privacy gotchas that have recently come up, a= nd as a bonus, is simpler.
= --Apple-Mail-C30EC95E-5E3F-4444-BCBB-32FF1A610EAC-- From nobody Fri Dec 11 08:52:15 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A260C1B2D0E for ; Fri, 11 Dec 2015 08:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.387 X-Spam-Level: X-Spam-Status: No, score=-1.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URI_TRY_3LD=0.001] autolearn=no 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 fWD0tq4nDLWF for ; Fri, 11 Dec 2015 08:52:11 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (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 7FDE41B2D10 for ; Fri, 11 Dec 2015 08:52:11 -0800 (PST) Received: by vkca188 with SMTP id a188so119947212vkc.0 for ; Fri, 11 Dec 2015 08:52:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/vNKtUHmnG4aRMWNFVfWx9cEF1Ek5DlsL4Hhlya9ZTM=; b=GB4RGTa5J1MKLSexus/Fk715InFffg2vZf2K2Xx9X3fe0N1xfi3I6fAYfTWm/ERRDP UXMNHwkPa1/n8YiyN96uh871fVDvDGXH7SHWbz0jh06egTwwjGvWr/Nwhaa75K8djtQa pJd2UmVCfcHRYzzVW4loMsOnb8sYFuopnzzDyEdsb21w8iSag+L+uPjBwnrfLY8gJdZK e9GRS3tzzILSjmN0VoNfxTRVge5ymvKLJCIwz7FukH5Fz+9uAN9fa94A4+q/yC4ZpUdm iAqplcqhb90tnOYxxUnd1OuuIOo/qOfAXjs6wYRUtRkgbY502xkP70VgP46/ouh4z/4F zxZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/vNKtUHmnG4aRMWNFVfWx9cEF1Ek5DlsL4Hhlya9ZTM=; b=FrZFYO4d11d97PA+KzdBE4FN3oozWliaF8AgmVU2LxeszZTbu+i/+bSZWW+QVw01QH GaeQI3kmvV9IjqbSDtWJ4MkTDmT9ZA3JAHW5hFgIKPWfRjszys4PmxkFtXc8Xut/TPqd 3tOVJkxwYeYBIYFtTSuk0q338xxhR6LARBtVFIk17nR6D+XVf+PJy9q6dSpAsQGUKnMu cN8hpwFM4QiJQBycRABcV09wge//jtoMsxusOLP2f2NBrfqR98zrWhvBefscQHNr5g9z sTtkuFE4BsVZ6uLZ9ycA6kcoD6COFmk/idPB8gdUBGSOtgSPQu8HFn6Bo2UXUgoJRlEY r49Q== X-Gm-Message-State: ALoCoQkJCcbE3hXhY/A3dqsb6lKortTuJCgWWPZKVkRNk7+pvyDJjf2nPpBnQwvO+0pHb48UyC9KI6ArjqJqo/PGRyZtEVVwcR1ktBGFPCvbdPfgEu76Cvg= X-Received: by 10.31.41.2 with SMTP id p2mr15419824vkp.135.1449852730564; Fri, 11 Dec 2015 08:52:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.219.129 with HTTP; Fri, 11 Dec 2015 08:51:51 -0800 (PST) In-Reply-To: <9A0DD478-0392-4A53-B53C-86F0035E7385@gmail.com> References: <9A0DD478-0392-4A53-B53C-86F0035E7385@gmail.com> From: Justin Uberti Date: Fri, 11 Dec 2015 08:51:51 -0800 Message-ID: To: Alan Johnston Content-Type: multipart/alternative; boundary=001a113f1498fbb1730526a224f2 Archived-At: Cc: "tram@ietf.org" , Brandon Williams Subject: Re: [tram] Recasting STUN ORIGIN as a 'Host' header X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 11 Dec 2015 16:52:13 -0000 --001a113f1498fbb1730526a224f2 Content-Type: text/plain; charset=UTF-8 Thanks for your comments. However, I don't think your assertion on matching rules is correct. First, ORIGIN sends the webapp origin. HOST sends the TURN DNS name. These will typically be completely different, and HOST is under application control as well. This is a substantial difference. Second, for the TURN provider, the fact that they are using a multi-tenant server vs several single-tenant servers is an implementation decision. If they have multiple single-tenant servers with separate DNS names, then distinguishing what usage is associated with each DNS name is obviously trivial. The fact that they can continue to do this when running a single-tenant server with multiple DNS names does not seem like a problem. On Fri, Dec 11, 2015 at 5:44 AM, Alan Johnston wrote: > Justin, > > Thanks for posting this. > > I've been thinking about using HOST as well, but I think this approach > generates new meta-data. Essentially, new WebRTC usage information is > generated at the STUN/TURN server where none was generated before. This is > true for both cases: where the URI is the domain of the TURN provider and > also where the domain is the WebRTC provider. > > Unless a comparison between the HOST and the ORIGIN is made, along the > lines of what I proposed in Yokohama. In this case, all we have done is > changed the name of the attribute from ORIGIN to HOST. The same info will > be sent over the wire. > > So, regardless if we call it ORIGIN or HOST, the same matching rules will > be needed. > > - Alan - > > On Dec 11, 2015, at 4:06 AM, Justin Uberti wrote: > > There was some discussion on this in Yokohama, but I haven't seen it make > its way onto the list yet. > > I think making ORIGIN into something more like HTTP's Host header is a > pretty good idea, so here's a quick summary from my perspective. > > Basically, I propose we get rid of ORIGIN and add a new HOST attribute > which carries the DNS name of the TURN server the application wants to > connect to (not the application origin). When the server is multi-tenant, > the provider can use CNAMEs to set up different DNS names for different > customers (e.g. app1.turnprovider.com, app2.turnprovider.com), all > pointing to the same multi-tenant TURN server - and use the HOST attribute > to identify the application and/or determine which REALM to return. > > Browsers don't need to do anything special other than adding a single > attribute, which comes directly from the supplied TURN URI. No name > matching, no multiple origins, no SRV records. > > This approach also deals effectively with the concerns around the browser > disclosing the user's ORIGIN to the TURN provider. Since the app is in > charge of what TURN URI it uses, it has control over what is disclosed to > the TURN provider - which is just the name in the TURN URI, not the app's > origin. > > For example: consider an app at www.myapp.com, which uses a TURN server > at myapp.turnprovider.com (a CNAME for turnserver.turnprovider.com that > was provisioned for myapp.com by turnprovider.com). In this case, the > HOST attribute would contain "myapp.turnprovider.com", but not " > www.myapp.com". > > Overall, I think this approach solves the core problem ORIGIN was meant to > solve (e.g. REALM for multi-tenant servers), avoids the privacy gotchas > that have recently come up, and as a bonus, is simpler. > > --001a113f1498fbb1730526a224f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for your comments. However, I don't think your = assertion on matching rules is correct.

First, ORIGIN se= nds the webapp origin. HOST sends the TURN DNS name. These will typically b= e completely different, and HOST is under application control as well. This= is a substantial difference.

Second, for the TURN p= rovider, the fact that they are using a multi-tenant server vs several sing= le-tenant servers is an implementation decision. If they have multiple sing= le-tenant servers with separate DNS names, then distinguishing what usage i= s associated with each DNS name is obviously trivial. The fact that they ca= n continue to do this when running a single-tenant server with multiple DNS= names does not seem like a problem.




On Fri, Dec 11, 2015 at 5:44 AM, Alan Johnston <alan.b.johnston@gmail.com> wrote:
Justin,

= Thanks for posting this.=C2=A0

I've been think= ing about using HOST as well, but I think this approach generates new meta-= data.=C2=A0 Essentially, new WebRTC usage information is generated at the S= TUN/TURN server where none was generated before. This is true for both case= s: where the URI is the domain of the TURN provider and also where the doma= in is the WebRTC provider.=C2=A0

Unless a comparis= on between the HOST and the ORIGIN is made, along the lines of what I propo= sed in Yokohama. In this case, all we have done is changed the name of the = attribute from ORIGIN to HOST.=C2=A0 The same info will be sent over the wi= re.=C2=A0

So, regardless if we call it ORIGIN or H= OST, the same matching rules will be needed.=C2=A0

- Alan -

On Dec 11, 2015, at 4:06 AM, Justin Uberti= <juberti@google= .com> wrote:

There was some discussion on this in Yokohama, but I haven't seen= it make its way onto the list yet.=C2=A0

I think making= ORIGIN into something more like HTTP's Host header is a pretty good id= ea, so here's a quick summary from my perspective.

=
Basically, I propose we get rid of ORIGIN and add a new HOST attribute= which carries the DNS name of the TURN server the application wants to con= nect to (not the application origin). When the server is multi-tenant, the = provider can use CNAMEs to set up different DNS names for different custome= rs (e.g. app1.tu= rnprovider.com, app2.turnprovider.com), all pointing to the same multi-tenant TURN = server - and use the HOST attribute to identify the application and/or dete= rmine which REALM to return.

Browsers don'= ;t need to do anything special other than adding a single attribute, which = comes directly from the supplied TURN URI. No name matching, no multiple or= igins, no SRV records.

This approach also de= als effectively with the concerns around the browser disclosing the user= 9;s ORIGIN to the TURN provider. Since the app is in charge of what TURN UR= I it uses, it has control over what is disclosed to the TURN provider - whi= ch is just the name in the TURN URI, not the app's origin.
For example:=C2=A0consider an app at www.myapp.com, which uses a TURN server at myapp.turnprovide= r.com (a CNAME for turnserver.turnprovider.com that was provisioned for myapp.com by turnprovider.com). In this case, = the HOST attribute would contain "myapp.turnprovider.com", but not "www.myapp.com".=C2= =A0

Overall, I think this approach solves the core= problem ORIGIN was meant to solve (e.g. REALM for multi-tenant servers), a= voids the privacy gotchas that have recently come up, and as a bonus, is si= mpler.

--001a113f1498fbb1730526a224f2-- From nobody Fri Dec 11 09:19:57 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2C01A894C for ; Fri, 11 Dec 2015 09:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 PmCDPJHbbz-w for ; Fri, 11 Dec 2015 09:19:54 -0800 (PST) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (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 646311A886F for ; Fri, 11 Dec 2015 09:19:54 -0800 (PST) Received: by qgec40 with SMTP id c40so200688609qge.2 for ; Fri, 11 Dec 2015 09:19:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=opOBCFToxITehWC5LZrV4cQUxTM2eazDfTzV08mmw5w=; b=UoRbqPehGQffRzsxHDVfN2sgTUIxEF8itEmRoiF1PQOljn++MIKDSMHNm1qE5wbc4D N0aOuWFpM/RJLmJ9boiq4A29k44jsIENjKgHBLdvnEclbhYvVG+IMOg6SOOXga3gTm+v oxNVnaSUyt22Ab8etI5xync1xP8+3QjxtJm5CLnjHd6XdxFaaF2+AaiQBSew3YOEEcMr tGRuJP8vytvxRuJf2yGYhCAnDW/Ber1naJd8r+j4BPXqwBx5v3U62t3OHKs78OsiFt0M MytbPUKvGFXiGBHqvZc+du/4/B2CcsvDC3CGLFrsOqaiPLkuBXMDWzuV9OxmxX2+Yry/ vdqA== MIME-Version: 1.0 X-Received: by 10.141.28.80 with SMTP id f77mr16514599qhe.66.1449854393583; Fri, 11 Dec 2015 09:19:53 -0800 (PST) Received: by 10.55.14.211 with HTTP; Fri, 11 Dec 2015 09:19:53 -0800 (PST) In-Reply-To: References: <9A0DD478-0392-4A53-B53C-86F0035E7385@gmail.com> Date: Fri, 11 Dec 2015 09:19:53 -0800 Message-ID: From: Ted Hardie To: Justin Uberti Content-Type: multipart/alternative; boundary=001a114238b81b154f0526a28864 Archived-At: Cc: Alan Johnston , "tram@ietf.org" , Brandon Williams Subject: Re: [tram] Recasting STUN ORIGIN as a 'Host' header X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 11 Dec 2015 17:19:56 -0000 --001a114238b81b154f0526a28864 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 11, 2015 at 8:51 AM, Justin Uberti wrote: > Thanks for your comments. However, I don't think your assertion on > matching rules is correct. > > First, ORIGIN sends the webapp origin. HOST sends the TURN DNS name. Thes= e > will typically be completely different, and HOST is under application > control as well. This is a substantial difference. > > Second, for the TURN provider, the fact that they are using a multi-tenan= t > server vs several single-tenant servers is an implementation decision. If > they have multiple single-tenant servers with separate DNS names, then > distinguishing what usage is associated with each DNS name is obviously > trivial. The fact that they can continue to do this when running a > single-tenant server with multiple DNS names does not seem like a problem= . > =E2=80=8BSo, many years ago livejournal.com moved from a model where the ty= pical URI was http://www.livejournal.com/name-of-journal to one where it was http://name-of-journal.livejournal.com/ (that had been a paid option prior to the shift, but it was relatively rare). The users liked the change because it resulted in better branding, but it meant that both the DNS queries and later the SNI leaked the information about which journal was being accessed. Other blogging platforms went through similar changes. What you are suggesting could have a similar effect. While it might theoretically possible for someone to set up an independent single-tenant TURN server for each blog-name.example.com=E2=80=8B that was using WebRTC t= o fuel a chat system, it seems pretty unlikely. Using a multi-tenant system disambiguated by HOST.turnserverfarm.example does not. The result would be that look-ups to the DNS for these turn servers would now reveal which HOST is being contacted. When DPRIVE is deployed, that will be mitigated, but it is currently a privacy concern. The current ORIGIN method, which the draft requires to be protected by DTLS or DTLS, in contrast, does not leak anything via the DNS. If the working group does accept this change, I would strongly urge it to update the security considerations to cover this case and to update the description of multi-tenancy to match the most likely methods of disambiguation. regards, Ted Hardie --001a114238b81b154f0526a28864 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 11, 2015 at 8:51 AM= , Justin Uberti <juberti@google.com> wrote:
Thanks for= your comments. However, I don't think your assertion on matching rules= is correct.

First, ORIGIN sends the webapp origin. HOST= sends the TURN DNS name. These will typically be completely different, and= HOST is under application control as well. This is a substantial differenc= e.

Second, for the TURN provider, the fact that they= are using a multi-tenant server vs several single-tenant servers is an imp= lementation decision. If they have multiple single-tenant servers with sepa= rate DNS names, then distinguishing what usage is associated with each DNS = name is obviously trivial. The fact that they can continue to do this when = running a single-tenant server with multiple DNS names does not seem like a= problem.

=E2=80=8BSo= , many years ago livejournal.com mov= ed from a model where the typical URI was http://www.livejournal.com/name-of-journal to one= where it was http://na= me-of-journal.livejournal.com/ (that had been a paid option prior to th= e shift, but it was relatively rare).=C2=A0 The users liked the change beca= use it resulted in better branding, but it meant that both the DNS queries = and later the SNI leaked the information about which journal was being acce= ssed.=C2=A0 Other blogging platforms went through similar changes.

=
What you are suggesting could have a similar effect.=C2=A0 = While it might theoretically possible for someone to set up an independent = single-tenant=C2=A0 TURN server for each blog-name.example.com=E2=80=8B that was using WebRTC to fuel a c= hat system, it seems pretty unlikely.=C2=A0 Using a multi-tenant system dis= ambiguated by HOST.turnserverfarm.example does not.=C2=A0 The result would = be that look-ups to the DNS for these turn servers would now reveal which H= OST is being contacted.=C2=A0 When DPRIVE is deployed, that will be mitigat= ed, but it is currently a privacy concern.=C2=A0 The current ORIGIN method,= which the draft requires to be protected by DTLS or DTLS, in contrast, doe= s not leak anything via the DNS.

If the working grou= p does accept this change, I would strongly urge it to update the security = considerations to cover this case and to update the description of multi-te= nancy to match the most likely methods of disambiguation.

regards,

Ted Hardie



--001a114238b81b154f0526a28864-- From nobody Fri Dec 11 17:05:01 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9CF1AC3D4 for ; Fri, 11 Dec 2015 17:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 t2VT41PA7oZv for ; Fri, 11 Dec 2015 17:04:58 -0800 (PST) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 DE7281AC3CD for ; Fri, 11 Dec 2015 17:04:57 -0800 (PST) Received: by vkca188 with SMTP id a188so126698658vkc.0 for ; Fri, 11 Dec 2015 17:04:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CfGr4IRCwIVcQcOBi5M187r8A17gDIcWHnS7Zo24XJk=; b=jZHHpobdagPjZcQzmtS1IioaCVqbCl9t9lgFGPi6Xd4fFu9Yv8smPgXFEjjHXpuOV5 gEdMIM3wQMHdACgZgIOIkatcuZ7JiKltiG4Emz4ZuFEJsij2GJ2c7jQnpZfxGLPESTi4 3HNBo0gmaLJpVaz1tvD0kVAmV6iKy/19PwHrrMf8ZWa/3Svr8v15Et+tbQvZJYkPprx2 ffQDciGymig/0BLwqHhpFEkitkRg8IqwZx+7t+HND5unBLT08uHE8GGOtsgSECa2tPSR V1/We5XeTlrSzpIYuri0v0zRjwlvsGwS0Rbf7xZNcT1vfkYo6k2m8BJTe2UbnQvHAeLz OQ8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=CfGr4IRCwIVcQcOBi5M187r8A17gDIcWHnS7Zo24XJk=; b=WqDRB4GobBnMvioWNfWBZR7AawGGezDGOPDxUPBTA3hpGvXdA8bqmfE1EdLLTJjaAd Ub1ShGyZ+BNBSpLrc4RgyFuZIdLqveK7X+BQCnzBXKrNQ+Kw50GGBa32H6npi2CNjm+6 jxVlM9UvA6DqHSLV1Y6nGlOHNMY9o7MVc6O+AAEdaI0ng6EdrGLoVkZMDsNjHiFfP6Xg P2gMA9N12nTq44+F4GUC6BDxQet3G14/dPW6wYfsXM9QN9IjgwojSXorg/lOn5Eu9Ft6 UNxxY4Oqk28k9U/ySsYgTe7PEtz9UnpIzVIvdH5qhw3qFU7eLdTdG/EgaetwbtlP7tAv ObnA== X-Gm-Message-State: ALoCoQlNGqTRyCV8aZRaSOZAV2F/eQk/Ud4Sa1Q0vkTP/EHWELNkHEFnU8308BjLlY/aubcIsiVkOgeKEmPyhzhUHEDwKgZS8xVqtw5i5c7ZcbZe836uAqY= X-Received: by 10.31.41.2 with SMTP id p2mr16794917vkp.135.1449882297008; Fri, 11 Dec 2015 17:04:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.219.129 with HTTP; Fri, 11 Dec 2015 17:04:37 -0800 (PST) In-Reply-To: References: <9A0DD478-0392-4A53-B53C-86F0035E7385@gmail.com> From: Justin Uberti Date: Fri, 11 Dec 2015 17:04:37 -0800 Message-ID: To: Ted Hardie Content-Type: multipart/alternative; boundary=001a113f149847cf5b0526a90724 Archived-At: Cc: Alan Johnston , "tram@ietf.org" , Brandon Williams Subject: Re: [tram] Recasting STUN ORIGIN as a 'Host' header X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 12 Dec 2015 01:05:00 -0000 --001a113f149847cf5b0526a90724 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ted, I agree that DNS queries for the TURN server will be accessible to eavesdroppers. However, the same can be said for blog-name.example.com itself, which seems like a larger concern. In the end the application has discretion on what it wants to do here - if the TURN URI could be considered sensitive, it has the option of using a non-sensitive URI, or another mechanism altogether, e.g. OAuth. Agree this should be spelled out in the security considerations. On Fri, Dec 11, 2015 at 9:19 AM, Ted Hardie wrote: > On Fri, Dec 11, 2015 at 8:51 AM, Justin Uberti wrote= : > >> Thanks for your comments. However, I don't think your assertion on >> matching rules is correct. >> >> First, ORIGIN sends the webapp origin. HOST sends the TURN DNS name. >> These will typically be completely different, and HOST is under applicat= ion >> control as well. This is a substantial difference. >> >> Second, for the TURN provider, the fact that they are using a >> multi-tenant server vs several single-tenant servers is an implementatio= n >> decision. If they have multiple single-tenant servers with separate DNS >> names, then distinguishing what usage is associated with each DNS name i= s >> obviously trivial. The fact that they can continue to do this when runni= ng >> a single-tenant server with multiple DNS names does not seem like a prob= lem. >> > > =E2=80=8BSo, many years ago livejournal.com moved from a model where the = typical > URI was http://www.livejournal.com/name-of-journal to one where it was > http://name-of-journal.livejournal.com/ (that had been a paid option > prior to the shift, but it was relatively rare). The users liked the > change because it resulted in better branding, but it meant that both the > DNS queries and later the SNI leaked the information about which journal > was being accessed. Other blogging platforms went through similar change= s. > > What you are suggesting could have a similar effect. While it might > theoretically possible for someone to set up an independent single-tenant > TURN server for each blog-name.example.com=E2=80=8B that was using WebRTC= to fuel > a chat system, it seems pretty unlikely. Using a multi-tenant system > disambiguated by HOST.turnserverfarm.example does not. The result would = be > that look-ups to the DNS for these turn servers would now reveal which HO= ST > is being contacted. When DPRIVE is deployed, that will be mitigated, but > it is currently a privacy concern. The current ORIGIN method, which the > draft requires to be protected by DTLS or DTLS, in contrast, does not lea= k > anything via the DNS. > > If the working group does accept this change, I would strongly urge it to > update the security considerations to cover this case and to update the > description of multi-tenancy to match the most likely methods of > disambiguation. > > regards, > > Ted Hardie > > > > --001a113f149847cf5b0526a90724 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ted,

I agree that DNS queries for the T= URN server will be accessible to eavesdroppers. However, the same can be sa= id for blog-name.example.com i= tself, which seems like a larger concern.

In the e= nd the application has discretion on what it wants to do here - if the TURN= URI could be considered sensitive, it has the option of using a non-sensit= ive URI, or another mechanism altogether, e.g. OAuth.

<= div>Agree this should be spelled out in the security considerations.
<= div>

On Fri, Dec 11, 2015 at 9:19 AM, Ted Hardie <ted.ietf@gmail.com>= ; wrote:
On Fri, Dec 11, 2015 at 8:51 AM, Justin= Uberti <juberti@google.com> wrote:
Thanks for your com= ments. However, I don't think your assertion on matching rules is corre= ct.

First, ORIGIN sends the webapp origin. HOST sends th= e TURN DNS name. These will typically be completely different, and HOST is = under application control as well. This is a substantial difference.

Second, for the TURN provider, the fact that they are usin= g a multi-tenant server vs several single-tenant servers is an implementati= on decision. If they have multiple single-tenant servers with separate DNS = names, then distinguishing what usage is associated with each DNS name is o= bviously trivial. The fact that they can continue to do this when running a= single-tenant server with multiple DNS names does not seem like a problem.=

=E2=80=8BSo, = many years ago livejou= rnal.com moved from a model where the typical URI was http://www.livejour= nal.com/name-of-journal to one where it was http://name-of-journal.livejourn= al.com/ (that had been a paid option prior to the shift, but it was rel= atively rare).=C2=A0 The users liked the change because it resulted in bett= er branding, but it meant that both the DNS queries and later the SNI leake= d the information about which journal was being accessed.=C2=A0 Other blogg= ing platforms went through similar changes.

What yo= u are suggesting could have a similar effect.=C2=A0 While it might theoreti= cally possible for someone to set up an independent single-tenant=C2=A0 TUR= N server for each blog-name.example.com=E2=80=8B that was using WebRTC to fuel a chat s= ystem, it seems pretty unlikely.=C2=A0 Using a multi-tenant system disambig= uated by HOST.turnserverfarm.example does not.=C2=A0 The result would be th= at look-ups to the DNS for these turn servers would now reveal which HOST i= s being contacted.=C2=A0 When DPRIVE is deployed, that will be mitigated, b= ut it is currently a privacy concern.=C2=A0 The current ORIGIN method, whic= h the draft requires to be protected by DTLS or DTLS, in contrast, does not= leak anything via the DNS.

If the working group doe= s accept this change, I would strongly urge it to update the security consi= derations to cover this case and to update the description of multi-tenancy= to match the most likely methods of disambiguation.

regards,

Ted Hardie




--001a113f149847cf5b0526a90724-- From nobody Fri Dec 11 19:10:20 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250E61ACDAA for ; Fri, 11 Dec 2015 19:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URI_TRY_3LD=0.001] autolearn=ham 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 7W5LSMHCFNs1 for ; Fri, 11 Dec 2015 19:10:17 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 4A76B1A9076 for ; Fri, 11 Dec 2015 19:10:17 -0800 (PST) Received: by mail-ig0-x22c.google.com with SMTP id ph11so51234347igc.1 for ; Fri, 11 Dec 2015 19:10:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vnI+ZPFeJ2tDFSB6RoFq7o6rgX8AimJSTXRszsJdaag=; b=MzHBK+7oYwV9HVbkLSPnlivD79nWpONGQxqLS0QJpUmchWs9G2V0roHag6ml5GHTad EnXRsi+S91iG960k1CraXGatEqptAXjtzkDNlgX2p2qaBUcteaOwOP11P5xQzir6+d09 9bDamXlHa+Z0w1g84yaZqQxFH2Iy1R2hRuHqvTHDF8DP15PXAWOhIBiR8DFzJX3TCWxl 0WjBg/wNncavcOay0BBkRb42pt118Czg6quqOXkcCSnJ2dxsbfJHdmczOZhpqdebchiR QRCs09jL23rvNrip9EWj2qvaCBKhPPMKoTiZu3tWXD8NIzv+8rgS6+/Xavyj+1mW84mh OZ2w== MIME-Version: 1.0 X-Received: by 10.50.64.178 with SMTP id p18mr7478735igs.42.1449889816525; Fri, 11 Dec 2015 19:10:16 -0800 (PST) Received: by 10.79.1.226 with HTTP; Fri, 11 Dec 2015 19:10:16 -0800 (PST) In-Reply-To: References: <9A0DD478-0392-4A53-B53C-86F0035E7385@gmail.com> Date: Fri, 11 Dec 2015 21:10:16 -0600 Message-ID: From: Alan Johnston To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7bd75c3a7a45ff0526aac7e1 Archived-At: Cc: "tram@ietf.org" , Brandon Williams Subject: Re: [tram] Recasting STUN ORIGIN as a 'Host' header X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 12 Dec 2015 03:10:20 -0000 --047d7bd75c3a7a45ff0526aac7e1 Content-Type: text/plain; charset=UTF-8 Hi Justin, The DISCUSS on STUN ORIGIN was because it generated new meta-data for operators of STUN/TURN servers. Are you arguing that your HOST proposal does not generate any new meta-data? That is, a STUN or TURN server gets no new data that relates to site usage? Or, are you arguing that the meta-data generated by HOST is of minimal value for site usage? If this is your assertion, I'd like you to explain this more. I can see multiple ways in which HOST could generate site usage meta-data (see below), unless ORIGIN matching rules are applied. See a few comments and questions below. - Alan - On Fri, Dec 11, 2015 at 10:51 AM, Justin Uberti wrote: > Thanks for your comments. However, I don't think your assertion on > matching rules is correct. > > First, ORIGIN sends the webapp origin. HOST sends the TURN DNS name. These > will typically be completely different, > Why will these typically be different? I see two cases: 1) the WebRTC site runs its own STUN/TURN servers, in which case HOST and ORIGIN will have the same domain. 2) the WebRTC gets a STUN/TURN URI from another provider, which may or may not be specific to this WebRTC site, in which case HOST and ORIGIN will be different domains, but could be related. > and HOST is under application control as well. > Do you mean that the WebRTC site gets to choose the domain name present in HOST? Yes, and no. It could either use the domain given it by the STUN/TURN provider (which could identify the site or might not) or it could generate its own DNS record, which would identify the site. > This is a substantial difference. > > Second, for the TURN provider, the fact that they are using a multi-tenant > server vs several single-tenant servers is an implementation decision. If > they have multiple single-tenant servers with separate DNS names, then > distinguishing what usage is associated with each DNS name is obviously > trivial. The fact that they can continue to do this when running a > single-tenant server with multiple DNS names does not seem like a problem. > This is the "we're not making the situation worse because there are other ways of doing the same thing" argument. This has worked in the past with meta-data, but I think the signal from the IESG is that this is no longer a justification. Our proposal will be evaluated on its own as to whether it generates usage meta-data or not, regardless if there are other ways and tricks to generate the same meta-data. This is my opinion based on what I heard during the IESG review. If others think I am wrong, then feel free to jump in. > > > > > On Fri, Dec 11, 2015 at 5:44 AM, Alan Johnston > wrote: > >> Justin, >> >> Thanks for posting this. >> >> I've been thinking about using HOST as well, but I think this approach >> generates new meta-data. Essentially, new WebRTC usage information is >> generated at the STUN/TURN server where none was generated before. This is >> true for both cases: where the URI is the domain of the TURN provider and >> also where the domain is the WebRTC provider. >> >> Unless a comparison between the HOST and the ORIGIN is made, along the >> lines of what I proposed in Yokohama. In this case, all we have done is >> changed the name of the attribute from ORIGIN to HOST. The same info will >> be sent over the wire. >> >> So, regardless if we call it ORIGIN or HOST, the same matching rules will >> be needed. >> >> - Alan - >> >> On Dec 11, 2015, at 4:06 AM, Justin Uberti wrote: >> >> There was some discussion on this in Yokohama, but I haven't seen it make >> its way onto the list yet. >> >> I think making ORIGIN into something more like HTTP's Host header is a >> pretty good idea, so here's a quick summary from my perspective. >> >> Basically, I propose we get rid of ORIGIN and add a new HOST attribute >> which carries the DNS name of the TURN server the application wants to >> connect to (not the application origin). When the server is multi-tenant, >> the provider can use CNAMEs to set up different DNS names for different >> customers (e.g. app1.turnprovider.com, app2.turnprovider.com), all >> pointing to the same multi-tenant TURN server - and use the HOST attribute >> to identify the application and/or determine which REALM to return. >> >> Browsers don't need to do anything special other than adding a single >> attribute, which comes directly from the supplied TURN URI. No name >> matching, no multiple origins, no SRV records. >> >> This approach also deals effectively with the concerns around the browser >> disclosing the user's ORIGIN to the TURN provider. Since the app is in >> charge of what TURN URI it uses, it has control over what is disclosed to >> the TURN provider - which is just the name in the TURN URI, not the app's >> origin. >> >> For example: consider an app at www.myapp.com, which uses a TURN server >> at myapp.turnprovider.com (a CNAME for turnserver.turnprovider.com that >> was provisioned for myapp.com by turnprovider.com). In this case, the >> HOST attribute would contain "myapp.turnprovider.com", but not " >> www.myapp.com". >> >> Overall, I think this approach solves the core problem ORIGIN was meant >> to solve (e.g. REALM for multi-tenant servers), avoids the privacy gotchas >> that have recently come up, and as a bonus, is simpler. >> >> > --047d7bd75c3a7a45ff0526aac7e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Justin,

The DISCUSS on STUN ORIGIN w= as because it generated new meta-data for operators of STUN/TURN servers.

Are you arguing that your HOST proposal does not ge= nerate any new meta-data?=C2=A0 That is, a STUN or TURN server gets no new = data that relates to site usage?

Or, are you argui= ng that the meta-data generated by HOST is of minimal value for site usage?= =C2=A0 If this is your assertion, I'd like you to explain this more.=C2= =A0 I can see multiple ways in which HOST could generate site usage meta-da= ta (see below), unless ORIGIN matching rules are applied.

See a few comments and questions below.

- = Alan -

On Fr= i, Dec 11, 2015 at 10:51 AM, Justin Uberti <juberti@google.com> wrote:
Thanks for y= our comments. However, I don't think your assertion on matching rules i= s correct.

First, ORIGIN sends the webapp origin. HOST s= ends the TURN DNS name. These will typically be completely different,
=

Why will these typically be differen= t?=C2=A0 I see two cases: =C2=A01) the WebRTC site runs its own STUN/TURN s= ervers, in which case HOST and ORIGIN will have the same domain. =C2=A02) t= he WebRTC gets a STUN/TURN URI from another provider, which may or may not = be specific to this WebRTC site, in which case HOST and ORIGIN will be diff= erent domains, but could be related.
=C2=A0
and HOST is under application control= as well.

Do you mean that the= WebRTC site gets to choose the domain name present in HOST?=C2=A0 Yes, and= no.=C2=A0 It could either use the domain given it by the STUN/TURN provide= r (which could identify the site or might not) or it could generate its own= DNS record, which would identify the site.=C2=A0
=C2=A0
This is a substantial dif= ference.

Second, for the TURN provider, the fact tha= t they are using a multi-tenant server vs several single-tenant servers is = an implementation decision. If they have multiple single-tenant servers wit= h separate DNS names, then distinguishing what usage is associated with eac= h DNS name is obviously trivial. The fact that they can continue to do this= when running a single-tenant server with multiple DNS names does not seem = like a problem.

This is t= he "we're not making the situation worse because there are other w= ays of doing the same thing" argument.=C2=A0 This has worked in the pa= st with meta-data, but I think the signal from the IESG is that this is no = longer a justification.=C2=A0 Our proposal will be evaluated on its own as = to whether it generates usage meta-data or not, regardless if there are oth= er ways and tricks to generate the same meta-data.=C2=A0 This is my opinion= based on what I heard during the IESG review.=C2=A0 If others think I am w= rong, then feel free to jump in.

=C2=A0




On Fri, Dec 11, 2015 at 5:44 AM, Alan Jo= hnston <alan.b.johnston@gmail.com> wrote:
Justin,

Thanks for posting this.=C2=A0

I&#= 39;ve been thinking about using HOST as well, but I think this approach gen= erates new meta-data.=C2=A0 Essentially, new WebRTC usage information is ge= nerated at the STUN/TURN server where none was generated before. This is tr= ue for both cases: where the URI is the domain of the TURN provider and als= o where the domain is the WebRTC provider.=C2=A0

U= nless a comparison between the HOST and the ORIGIN is made, along the lines= of what I proposed in Yokohama. In this case, all we have done is changed = the name of the attribute from ORIGIN to HOST.=C2=A0 The same info will be = sent over the wire.=C2=A0

So, regardless if we cal= l it ORIGIN or HOST, the same matching rules will be needed.=C2=A0

- Alan -
=

On Dec 11, 2015, at 4:06 AM, Justin Uberti <juberti@google.com>= wrote:

There = was some discussion on this in Yokohama, but I haven't seen it make its= way onto the list yet.=C2=A0

I think making ORIGIN into= something more like HTTP's Host header is a pretty good idea, so here&= #39;s a quick summary from my perspective.

Basical= ly, I propose we get rid of ORIGIN and add a new HOST attribute which carri= es the DNS name of the TURN server the application wants to connect to (not= the application origin). When the server is multi-tenant, the provider can= use CNAMEs to set up different DNS names for different customers (e.g. app1.turnprovider.c= om, app2.tur= nprovider.com), all pointing to the same multi-tenant TURN server - and= use the HOST attribute to identify the application and/or determine which = REALM to return.

Browsers don't need to d= o anything special other than adding a single attribute, which comes direct= ly from the supplied TURN URI. No name matching, no multiple origins, no SR= V records.

This approach also deals effectiv= ely with the concerns around the browser disclosing the user's ORIGIN t= o the TURN provider. Since the app is in charge of what TURN URI it uses, i= t has control over what is disclosed to the TURN provider - which is just t= he name in the TURN URI, not the app's origin.

For example:=C2=A0consider an app at www.myapp.com, which uses a TURN server at myapp.turnprovider.com (a= CNAME for turnserver.turnprovider.com that was provisioned for myapp.com by turnprovider.com). In this case, the HOST att= ribute would contain "myapp.turnprovider.com", but not "www.myapp.com".=C2=A0

Overall, I think this approach solves the core problem ORI= GIN was meant to solve (e.g. REALM for multi-tenant servers), avoids the pr= ivacy gotchas that have recently come up, and as a bonus, is simpler.
=


--047d7bd75c3a7a45ff0526aac7e1-- From nobody Sat Dec 12 12:52:16 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D3F1A902D for ; Sat, 12 Dec 2015 12:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.387 X-Spam-Level: X-Spam-Status: No, score=-1.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URI_TRY_3LD=0.001] autolearn=no 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 zdFvNpYXIzCQ for ; Sat, 12 Dec 2015 12:52:11 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (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 9A91E1A901F for ; Sat, 12 Dec 2015 12:52:11 -0800 (PST) Received: by vkha189 with SMTP id a189so134503274vkh.2 for ; Sat, 12 Dec 2015 12:52:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=V6rYNxAqv30svqq09Yt8Vcrqz19eTfpE3S38gupbjnU=; b=YEJsNzEatpoL5ZQcZgEWAXFz0SQtIL5Wm5JMK7J9pMjO0k15tuFHbPR25sXMNLTNtB dDaPJsc7ozmMEC3EY9pM/T0DBEl56I8R2kRhUHsVpa9BH1mR21kr7WldxEcSWNPdS1bZ Jx6lBKshA7+Rk9xSDkH7SCIyPdNC78jinOnszGFJGkO3Gqzg33VcqTSvvM58jMjjCjPH dT5bpbEJ56ftBanlZaAWVh4OCSfWdTL3UxdbWOTJmLyaMBnhXLkxyHMLze9fAWtQlU5P bV5p5nCrsqVv7flrTUpUiArvb2DsXXj4C/zn3VQoOgVdAp+rCyXjouszzHGjPoTCEF1B 38Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=V6rYNxAqv30svqq09Yt8Vcrqz19eTfpE3S38gupbjnU=; b=VIM4tUVxNV++O9kPlb0yABlkL7h4yH7bW3ZD5fZojIw0Wxmf28y8q2XDKUIlvqCloj bEtfSzZKL0JWm4iYheolVP2F/w+e3F+pIQVAfjLapOeqzH+eRjnzBq8OoQW2fNx5BnM0 i08FHRNJtqnZ6/6wOv8EQamp2rZovrM5IPsJS0D9sqGwQ5gAGp6Hi99q8xkxexwBCulw ZG0TWQ/ANEpXyTqmGDxzou55avg1NIOZ3n8PVlhmtpGBpLvI3ldeAaXGymjwurBe8dnd DpznOWXlMJMjrZpyKeISRf3cT27adxQ4b7He99AWb03KxoKtIAj7Q1AhIzkPnE5FEJuX BZrA== X-Gm-Message-State: ALoCoQmHubMqNfKrK2Yl87ZmMmu4b+DN3xlj4589pYds5L/m+yQW5qDOvWrJxGL5/vlriuGJzlTe+pJAA4Tutqr25NJArcDTqBUbich2joeVYIsYiwKvJqQ= X-Received: by 10.31.34.198 with SMTP id i189mr18928701vki.111.1449953530552; Sat, 12 Dec 2015 12:52:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.219.129 with HTTP; Sat, 12 Dec 2015 12:51:50 -0800 (PST) In-Reply-To: References: <9A0DD478-0392-4A53-B53C-86F0035E7385@gmail.com> From: Justin Uberti Date: Sat, 12 Dec 2015 12:51:50 -0800 Message-ID: To: Alan Johnston Content-Type: multipart/alternative; boundary=001a113d9c462163a30526b99d59 Archived-At: Cc: "tram@ietf.org" , Brandon Williams Subject: Re: [tram] Recasting STUN ORIGIN as a 'Host' header X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 12 Dec 2015 20:52:14 -0000 --001a113d9c462163a30526b99d59 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 11, 2015 at 7:10 PM, Alan Johnston wrote: > Hi Justin, > > The DISCUSS on STUN ORIGIN was because it generated new meta-data for > operators of STUN/TURN servers. > > Are you arguing that your HOST proposal does not generate any new > meta-data? That is, a STUN or TURN server gets no new data that relates to > site usage? > > Or, are you arguing that the meta-data generated by HOST is of minimal > value for site usage? If this is your assertion, I'd like you to explain > this more. I can see multiple ways in which HOST could generate site usage > meta-data (see below), unless ORIGIN matching rules are applied. > > The argument is somewhere in between. 1) By virtue of it being opt-in to the application, it generates no new *implicit* metadata towards TURN server operators. This is a substantial difference from ORIGIN, and IMO obviates the need for matching rules. - if the site runs its own TURN server, this issue is irrelevant - if the site uses an external TURN server, it can use/insist on a generic name (this app explicit control is a significant difference from ORIGIN). 2) If used without DTLS, it does generate new metadata visible to eavesdroppers. This can be addressed via DTLS, if the app thinks this is important. But this is an orthogonal discussion to any name matching rules. Overall: yes, technically there is new metadata. But it is different than the metadata for ORIGIN, and I think enough so that it is worth taking another run at this. > - Alan - > > On Fri, Dec 11, 2015 at 10:51 AM, Justin Uberti > wrote: > >> Thanks for your comments. However, I don't think your assertion on >> matching rules is correct. >> >> First, ORIGIN sends the webapp origin. HOST sends the TURN DNS name. >> These will typically be completely different, >> > > Why will these typically be different? I see two cases: 1) the WebRTC > site runs its own STUN/TURN servers, in which case HOST and ORIGIN will > have the same domain. 2) the WebRTC gets a STUN/TURN URI from another > provider, which may or may not be specific to this WebRTC site, in which > case HOST and ORIGIN will be different domains, but could be related. > > >> and HOST is under application control as well. >> > > Do you mean that the WebRTC site gets to choose the domain name present in > HOST? Yes, and no. It could either use the domain given it by the > STUN/TURN provider (which could identify the site or might not) or it could > generate its own DNS record, which would identify the site. > > >> This is a substantial difference. >> >> Second, for the TURN provider, the fact that they are using a >> multi-tenant server vs several single-tenant servers is an implementation >> decision. If they have multiple single-tenant servers with separate DNS >> names, then distinguishing what usage is associated with each DNS name is >> obviously trivial. The fact that they can continue to do this when running >> a single-tenant server with multiple DNS names does not seem like a problem. >> > > This is the "we're not making the situation worse because there are other > ways of doing the same thing" argument. This has worked in the past with > meta-data, but I think the signal from the IESG is that this is no longer a > justification. Our proposal will be evaluated on its own as to whether it > generates usage meta-data or not, regardless if there are other ways and > tricks to generate the same meta-data. This is my opinion based on what I > heard during the IESG review. If others think I am wrong, then feel free > to jump in. > > > >> >> >> >> >> On Fri, Dec 11, 2015 at 5:44 AM, Alan Johnston > > wrote: >> >>> Justin, >>> >>> Thanks for posting this. >>> >>> I've been thinking about using HOST as well, but I think this approach >>> generates new meta-data. Essentially, new WebRTC usage information is >>> generated at the STUN/TURN server where none was generated before. This is >>> true for both cases: where the URI is the domain of the TURN provider and >>> also where the domain is the WebRTC provider. >>> >>> Unless a comparison between the HOST and the ORIGIN is made, along the >>> lines of what I proposed in Yokohama. In this case, all we have done is >>> changed the name of the attribute from ORIGIN to HOST. The same info will >>> be sent over the wire. >>> >>> So, regardless if we call it ORIGIN or HOST, the same matching rules >>> will be needed. >>> >>> - Alan - >>> >>> On Dec 11, 2015, at 4:06 AM, Justin Uberti wrote: >>> >>> There was some discussion on this in Yokohama, but I haven't seen it >>> make its way onto the list yet. >>> >>> I think making ORIGIN into something more like HTTP's Host header is a >>> pretty good idea, so here's a quick summary from my perspective. >>> >>> Basically, I propose we get rid of ORIGIN and add a new HOST attribute >>> which carries the DNS name of the TURN server the application wants to >>> connect to (not the application origin). When the server is multi-tenant, >>> the provider can use CNAMEs to set up different DNS names for different >>> customers (e.g. app1.turnprovider.com, app2.turnprovider.com), all >>> pointing to the same multi-tenant TURN server - and use the HOST attribute >>> to identify the application and/or determine which REALM to return. >>> >>> Browsers don't need to do anything special other than adding a single >>> attribute, which comes directly from the supplied TURN URI. No name >>> matching, no multiple origins, no SRV records. >>> >>> This approach also deals effectively with the concerns around the >>> browser disclosing the user's ORIGIN to the TURN provider. Since the app is >>> in charge of what TURN URI it uses, it has control over what is disclosed >>> to the TURN provider - which is just the name in the TURN URI, not the >>> app's origin. >>> >>> For example: consider an app at www.myapp.com, which uses a TURN server >>> at myapp.turnprovider.com (a CNAME for turnserver.turnprovider.com that >>> was provisioned for myapp.com by turnprovider.com). In this case, the >>> HOST attribute would contain "myapp.turnprovider.com", but not " >>> www.myapp.com". >>> >>> Overall, I think this approach solves the core problem ORIGIN was meant >>> to solve (e.g. REALM for multi-tenant servers), avoids the privacy gotchas >>> that have recently come up, and as a bonus, is simpler. >>> >>> >> > --001a113d9c462163a30526b99d59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Dec 11, 2015 at 7:10 PM, Alan Johnston <alan.b.johnsto= n@gmail.com> wrote:
Hi Justin,

The DISCUSS on STUN ORIGIN was beca= use it generated new meta-data for operators of STUN/TURN servers.

Are you arguing that your HOST proposal does not generate = any new meta-data?=C2=A0 That is, a STUN or TURN server gets no new data th= at relates to site usage?

Or, are you arguing that= the meta-data generated by HOST is of minimal value for site usage?=C2=A0 = If this is your assertion, I'd like you to explain this more.=C2=A0 I c= an see multiple ways in which HOST could generate site usage meta-data (see= below), unless ORIGIN matching rules are applied.


The argument is somewhere in between.=C2= =A0
1) By virtue of it being opt-in to the application, it genera= tes no new implicit metadata towards TURN server operators. This is = a substantial difference from ORIGIN, and IMO obviates the need for matchin= g rules.
- if the site runs its own TURN server, this issue is ir= relevant
- if the site uses an external TURN server, it can use/i= nsist on a generic name (this app explicit control is a significant differe= nce from ORIGIN).
2) If used without DTLS, it does generate new m= etadata visible to eavesdroppers. This can be addressed via DTLS, if the ap= p thinks this is important. But this is an orthogonal discussion to any nam= e matching rules.

Overall: yes, technically there = is new metadata. But it is different than the metadata for ORIGIN, and I th= ink enough so that it is worth taking another run at this.

=C2=A0
<= /div>
- Alan -

On Fri, Dec 11, 2015 at 10:51 AM, Justin Uberti <= juberti@google.com> wrote:
=
Thanks for your comments. However, I don't think your = assertion on matching rules is correct.

First, ORIGIN se= nds the webapp origin. HOST sends the TURN DNS name. These will typically b= e completely different,

= Why will these typically be different?=C2=A0 I see two cases: =C2=A01) the = WebRTC site runs its own STUN/TURN servers, in which case HOST and ORIGIN w= ill have the same domain. =C2=A02) the WebRTC gets a STUN/TURN URI from ano= ther provider, which may or may not be specific to this WebRTC site, in whi= ch case HOST and ORIGIN will be different domains, but could be related.
=C2=A0
and HOST is under application control as well.
=

Do you mean that the WebRTC site ge= ts to choose the domain name present in HOST?=C2=A0 Yes, and no.=C2=A0 It c= ould either use the domain given it by the STUN/TURN provider (which could = identify the site or might not) or it could generate its own DNS record, wh= ich would identify the site.=C2=A0
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
This is a substantial d= ifference.

Second, for the TURN provider, the fact t= hat they are using a multi-tenant server vs several single-tenant servers i= s an implementation decision. If they have multiple single-tenant servers w= ith separate DNS names, then distinguishing what usage is associated with e= ach DNS name is obviously trivial. The fact that they can continue to do th= is when running a single-tenant server with multiple DNS names does not see= m like a problem.

= This is the "we're not making the situation worse because there ar= e other ways of doing the same thing" argument.=C2=A0 This has worked = in the past with meta-data, but I think the signal from the IESG is that th= is is no longer a justification.=C2=A0 Our proposal will be evaluated on it= s own as to whether it generates usage meta-data or not, regardless if ther= e are other ways and tricks to generate the same meta-data.=C2=A0 This is m= y opinion based on what I heard during the IESG review.=C2=A0 If others thi= nk I am wrong, then feel free to jump in.

=C2=A0
<= div>




On Fri, Dec 11= , 2015 at 5:44 AM, Alan Johnston <alan.b.johnston@gmail.com>= ; wrote:
Justin,

Thanks for posting this.=C2=A0

I've been thinking about using HOST as well, but= I think this approach generates new meta-data.=C2=A0 Essentially, new WebR= TC usage information is generated at the STUN/TURN server where none was ge= nerated before. This is true for both cases: where the URI is the domain of= the TURN provider and also where the domain is the WebRTC provider.=C2=A0<= /div>

Unless a comparison between the HOST and the ORIGI= N is made, along the lines of what I proposed in Yokohama. In this case, al= l we have done is changed the name of the attribute from ORIGIN to HOST.=C2= =A0 The same info will be sent over the wire.=C2=A0

So, regardless if we call it ORIGIN or HOST, the same matching rules will= be needed.=C2=A0

- = Alan -

On Dec 11, 2015, at 4:06 AM, J= ustin Uberti <ju= berti@google.com> wrote:

There was some discussion on this in Yokohama, but I have= n't seen it make its way onto the list yet.=C2=A0

I = think making ORIGIN into something more like HTTP's Host header is a pr= etty good idea, so here's a quick summary from my perspective.

Basically, I propose we get rid of ORIGIN and add a new HO= ST attribute which carries the DNS name of the TURN server the application = wants to connect to (not the application origin). When the server is multi-= tenant, the provider can use CNAMEs to set up different DNS names for diffe= rent customers (e.g. app1.turnprovider.com, app2.turnprovider.com), all pointing to the same multi-= tenant TURN server - and use the HOST attribute to identify the application= and/or determine which REALM to return.

Brow= sers don't need to do anything special other than adding a single attri= bute, which comes directly from the supplied TURN URI. No name matching, no= multiple origins, no SRV records.

This appr= oach also deals effectively with the concerns around the browser disclosing= the user's ORIGIN to the TURN provider. Since the app is in charge of = what TURN URI it uses, it has control over what is disclosed to the TURN pr= ovider - which is just the name in the TURN URI, not the app's origin.<= /div>

For example:=C2=A0consider an app at www.myapp.com, which uses a TURN = server at myapp= .turnprovider.com (a CNAME for turnserver.turnprovider.com that was provision= ed for myapp.com by turnprovider.com). In= this case, the HOST attribute would contain "myapp.turnprovider.com", but n= ot "www.myapp.com".=C2=A0




--001a113d9c462163a30526b99d59-- From nobody Sun Dec 13 07:42:16 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206471AD377 for ; Sun, 13 Dec 2015 07:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham 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 6ajzkqnEjT2l for ; Sun, 13 Dec 2015 07:42:12 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::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 422E51A6F1F for ; Sun, 13 Dec 2015 07:42:12 -0800 (PST) Received: by qgfb51 with SMTP id b51so29735575qgf.3 for ; Sun, 13 Dec 2015 07:42:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jive-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=R60i9q0bXrcDg52JLN5mbue1op3/a1sgacfEDjZeIuk=; b=qH4BtwcosQqJLDG6BdYNInYw+j0YD4ybdaGwkaKTHTeEpPyiJ2QFhovze2ZqueLAxo i4El0YNIU3mRZ8l7WOHYwLcmsG5DcYeZihWt8hzXGsDnCO78CWUOmuqwqL/ZCbqYH9vb Q6jYYsxpvHNhI4NiGr+7KVh3VU1BQQW09CLXnbInQUg92dwKKCJSvBYBN9puRfc4aFSW H8Y6rItO7FrDOJEXkMWkZmXImjl6uoomcCVL4igU5CgDOOXdhVqc2ckmS0lykpFD1n3o 9hzEIl04bFYG2EZgdCVDIsC5sBO5ton67qj40inWTx0lkw7xmy8Kv46K7VVnRFxWDr71 QZJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=R60i9q0bXrcDg52JLN5mbue1op3/a1sgacfEDjZeIuk=; b=jWayKmVVZeMq4p6eTMxZ9+FEWjpSGZ8XxUOy9ZtFivTLM73+epLoSQkUqAo7VXfimu 2aYsyj/znjEuVObI9fQUGSYvD0+sIR6c92CnB847VJkJBwLV1CDcFHkr1tKk7n3q7Dvg 5FaJ5Wbu3tZHlAV4CPLV5a7O5ee5MD9rhRaBGZBxCYs6ngI+yFXeMtSe2wG0z3MlPl7Y /5V0Q7RjfEVFUqWg3dMgvx9P8BNICGZgycpi33znhDDOAlqldse7KtbQgz4Honrn3iyr dK4Vyvc8Z94A25c9SVJq1n0nolaiVaXmNNVOaJkMAR+5IxlSBqyJUhKMuOphDynrSM53 2tIA== X-Gm-Message-State: ALoCoQmgY+1B1FD7GbDbhzS6g+bgZQFPybD1zrrVza1Jvp18QG3ErGEngKx6pyxOOkbV5Xa3aGnJg2nEGzc6PMoVLDrhpDeWRg== X-Received: by 10.140.201.13 with SMTP id w13mr28949957qha.15.1450021331399; Sun, 13 Dec 2015 07:42:11 -0800 (PST) Received: from [192.168.1.131] (modemcable164.157-22-96.mc.videotron.ca. [96.22.157.164]) by smtp.googlemail.com with ESMTPSA id l38sm2742613qgd.27.2015.12.13.07.42.10 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Dec 2015 07:42:10 -0800 (PST) To: Justin Uberti , Alan Johnston References: <9A0DD478-0392-4A53-B53C-86F0035E7385@gmail.com> From: Simon Perreault Message-ID: <566D91D1.1060509@jive.com> Date: Sun, 13 Dec 2015 10:42:09 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "tram@ietf.org" , Brandon Williams Subject: Re: [tram] Recasting STUN ORIGIN as a 'Host' header X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 13 Dec 2015 15:42:14 -0000 Le 2015-12-12 15:51, Justin Uberti a écrit : > The argument is somewhere in between. > 1) By virtue of it being opt-in to the application, it generates no new > *implicit* metadata towards TURN server operators. This is a substantial > difference from ORIGIN, and IMO obviates the need for matching rules. > - if the site runs its own TURN server, this issue is irrelevant > - if the site uses an external TURN server, it can use/insist on a > generic name (this app explicit control is a significant difference from > ORIGIN). And if the user configures his web browser to use a third-party TURN server (e.g., numb.viagenie.ca) then no information about WebRTC applications usage is revealed to the TURN server operator. That is very different from ORIGIN. Simon From nobody Sun Dec 13 14:22:55 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843C81A8855 for ; Sun, 13 Dec 2015 14:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 xPlwuuujViXL for ; Sun, 13 Dec 2015 14:22:52 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 DFA111A8853 for ; Sun, 13 Dec 2015 14:22:51 -0800 (PST) Received: by iofo67 with SMTP id o67so25998671iof.3 for ; Sun, 13 Dec 2015 14:22:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tDR3B2GV/lYnTc99XT4R1zQlQ9BwClmYqgosnIoEfOo=; b=zWFpFadMoqe0KWAHwGxagcjzKo5E+jaG99mHY7bmo6MrxHiISF0Xy7wKrHp+gMCucX HOqLJ/R7bNGUNJcPVVvx5jLmEmczW2ayCI1AHsuINQmTrYyurTS7Fab6ihtZaGJ4twKO zq2Xcpr029Ky+4RwzqC/mHGLaTFUjEOCtCM5uMPtAwS7irxYNLSSGPlcr8A/l7akc50M Y1RGtgUBs0AaB61+fo7eWoQJRHxtLybQNHlbWLcPWSMFYjkHl7qw1T/BxDjoDeFNG0v1 3RMU46PzF7Xwrzl4a8Sa1DATsrdamgaLbebzAHS6o3KUgeJwQCr3YsWxz7RH/7HvDeev TDzQ== MIME-Version: 1.0 X-Received: by 10.107.169.29 with SMTP id s29mr27813059ioe.190.1450045371269; Sun, 13 Dec 2015 14:22:51 -0800 (PST) Received: by 10.36.149.130 with HTTP; Sun, 13 Dec 2015 14:22:51 -0800 (PST) In-Reply-To: References: <9A0DD478-0392-4A53-B53C-86F0035E7385@gmail.com> Date: Mon, 14 Dec 2015 09:22:51 +1100 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ted Hardie , Alan Johnston , "tram@ietf.org" , Brandon Williams Subject: Re: [tram] Recasting STUN ORIGIN as a 'Host' header X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 13 Dec 2015 22:22:53 -0000 On 12 December 2015 at 12:04, Justin Uberti wrote: > I agree that DNS queries for the TURN server will be accessible to > eavesdroppers. However, the same can be said for blog-name.example.com itself, which seems like a larger concern. Yes, the blogs are a greater concern. I understand why a blog site might choose to make that change (see https://github.com/blog/1452-new-github-pages-domain-github-io#security-vulnerability), but the privacy-security trade-off here is fundamentally different. For the reasons Ted describes, HOST is strictly worse from a privacy standpoint than ORIGIN. Just. And maybe the two will eventually be the same, though the list of prerequisites on a solution to the DNS leakage is rather long. I think that Justin is right to try to find a solution that depends on the application doing something special to enable the leakage. I think that's an important property. Defaults matter. And it's not exactly hard to exfiltrate information using USERNAME, so that's the bar we need to clear. But HOST doesn't have a monopoly on the solution there. The same could be said for a FUNGUS attribute that was explicitly set by the application in TURN server config. From nobody Sun Dec 13 18:16:09 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27D41A909F for ; Sun, 13 Dec 2015 18:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 SJCthxMT1VnB for ; Sun, 13 Dec 2015 18:16:05 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (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 4795C1A90A0 for ; Sun, 13 Dec 2015 18:16:05 -0800 (PST) Received: by vkha189 with SMTP id a189so145523935vkh.2 for ; Sun, 13 Dec 2015 18:16:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qRust3+i3V6sNJZ1T9yZUozLu8snF00oPftGvfmVMQ8=; b=R6oNdjnpvfBzsEyWmFSwJYplLWXl93Md9YuIzqWiPI5ruk2RAsgrwoR84mN+hUApdA y/c88D05iI5JckDrArcx1u4HBzW3i8ww4vOq0bFSnVYEYPGKo+/rmlRgHWYDOU9BYfma w3dRrresbIKOdF0OrUQ8AfC8nCHY95xXDSg4ka+l7CAs88n6t157WNWZJ4smFigf5coq Yqgo8PtXTckjj2l4jIsNZvHXbZUD+0twVLrcK743S8Zg2FBjwULgKeO044kpK3IHkL7C zJudmHRn31lkUPNR4knmlvQ0R8GPAosL2K48ojFP+QfE5Wag17pKjKyhs88dPKbYTXdb IB8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qRust3+i3V6sNJZ1T9yZUozLu8snF00oPftGvfmVMQ8=; b=Tb0MdlwXgw8RbWe3Yb4VpMk1l4DYoMOUvBL9qJeoFeH8NdnlUza/MYH7IPCvCJxinx 8aXtc2fqD7CujHeR7UZ7Ye7IZLBQeN5B0mH6lu2c8jy/YQPx8563/pahPo457xFKGQ9D Xph1usNU9cAEZ8VF82CPB/vY7y5vZ1E/dr7/LSYDnZ24xEHs/OUST+fzLORj0X0xHYH3 QuITOqN/tSoBh4hA+v+YzoHt2ZkYBc6E6MOWm7g84+1Wpj0METd+OxLN6BWRlBYupmXG zviZ9/YEVlg8boHVqkq3MzDZRFrPdJ11IeuFdYG35V4oSq0KoM0ia75s7OQU9sswJffN oIlQ== X-Gm-Message-State: ALoCoQlivYnGBdGIKThfohoNb1VHcs6x15XP/mHvg5ayM5cTEqVdwGIaUUW+d6712JHtRCuXDLfJLIayPfbOlEyo+1QzJ3xLp+1rZ1/4u6uEnaIZpuu20vE= X-Received: by 10.31.141.5 with SMTP id p5mr22791575vkd.158.1450059364288; Sun, 13 Dec 2015 18:16:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.219.129 with HTTP; Sun, 13 Dec 2015 18:15:44 -0800 (PST) In-Reply-To: References: <9A0DD478-0392-4A53-B53C-86F0035E7385@gmail.com> From: Justin Uberti Date: Sun, 13 Dec 2015 18:15:44 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114268605015a70526d241be Archived-At: Cc: Ted Hardie , Alan Johnston , "tram@ietf.org" , Brandon Williams Subject: Re: [tram] Recasting STUN ORIGIN as a 'Host' header X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 14 Dec 2015 02:16:07 -0000 --001a114268605015a70526d241be Content-Type: text/plain; charset=UTF-8 On Sun, Dec 13, 2015 at 2:22 PM, Martin Thomson wrote: > On 12 December 2015 at 12:04, Justin Uberti wrote: > > I agree that DNS queries for the TURN server will be accessible to > > eavesdroppers. However, the same can be said for blog-name.example.com > itself, which seems like a larger concern. > > Yes, the blogs are a greater concern. I understand why a blog site > might choose to make that change (see > > https://github.com/blog/1452-new-github-pages-domain-github-io#security-vulnerability > ), > but the privacy-security trade-off here is fundamentally different. > > For the reasons Ted describes, HOST is strictly worse from a privacy > standpoint than ORIGIN. Just. And maybe the two will eventually be > the same, though the list of prerequisites on a solution to the DNS > leakage is rather long. > > I think that Justin is right to try to find a solution that depends on > the application doing something special to enable the leakage. I > think that's an important property. Defaults matter. And it's not > exactly hard to exfiltrate information using USERNAME, so that's the > bar we need to clear. But HOST doesn't have a monopoly on the > solution there. The same could be said for a FUNGUS attribute that > was explicitly set by the application in TURN server config. > Sure, we could go down that route, in which FUNGUS is a way for the application to set its desired REALM programatically. This would avoid the DNS concerns since no lookup of the REALM would occur, although at that point we're basically coming up with a more standard and aesthetically pleasing way of doing what could already be done with USERNAME (e.g. user@realm.com) --001a114268605015a70526d241be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Dec 13, 2015 at 2:22 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 12= December 2015 at 12:04, Justin Uberti <juberti@google.com> wrote:
> I agree that DNS queries for the TURN server will be accessible to
> eavesdroppers. However, the same can be said for blog-name.example.= com itself, which seems like a larger concern.

Yes, the blogs are a greater concern.=C2=A0 I understand why a blog = site
might choose to make that change (see
https://github.= com/blog/1452-new-github-pages-domain-github-io#security-vulnerability)= ,
but the privacy-security trade-off here is fundamentally different.

For the reasons Ted describes, HOST is strictly worse from a privacy
standpoint than ORIGIN.=C2=A0 Just.=C2=A0 And maybe the two will eventually= be
the same, though the list of prerequisites on a solution to the DNS
leakage is rather long.

I think that Justin is right to try to find a solution that depends on
the application doing something special to enable the leakage.=C2=A0 I
think that's an important property.=C2=A0 Defaults matter.=C2=A0 And it= 's not
exactly hard to exfiltrate information using USERNAME, so that's the bar we need to clear.=C2=A0 But HOST doesn't have a monopoly on the
solution there.=C2=A0 The same could be said for a FUNGUS attribute that was explicitly set by the application in TURN server config.

Sure, we could go down that route, in which FUNGUS is= a way for the application to set its desired REALM programatically.=C2=A0T= his would avoid the DNS concerns since no lookup of the REALM would occur, = although at that point we're basically coming up with a more standard a= nd aesthetically pleasing way of doing what could already be done with USER= NAME (e.g. user@realm.com)
=

--001a114268605015a70526d241be-- From nobody Sun Dec 13 18:48:28 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEEC1A90E2 for ; Sun, 13 Dec 2015 18:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 EkueqbfxQi7d for ; Sun, 13 Dec 2015 18:48:25 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 1EA4E1A90E1 for ; Sun, 13 Dec 2015 18:48:25 -0800 (PST) Received: by iofq126 with SMTP id q126so20324421iof.2 for ; Sun, 13 Dec 2015 18:48:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KXbLrrQAkmBYbB6naPJ+KiRhaZUvoEbD7OaA3BOFXt8=; b=tN+mGRTXArXjBHWIUqHAuYYFYP64JmQJs/222ggyNmFvkUuoektMwk7ZF1ig3FvQjC 9jiSB8kT3l+mMu4/pJ9WeGN05N0Ce3DUrUXzgjSpA00GSCi2fCmGHJARGhMCue4gFBSJ r+DmtjqoHnhY/f0CneAsYmoxTBy2tHttGOVpB3Ue9KZmfx6+0LzX3yZKUKmi113eXLZE SEHJfiShkLJEDEfXlo4/rsjMuxtGJ7Eu9fqCDkdmYG9YxUqkxOlokD14cxncXsxQZtuv gW/18RvQjJJgl/l7nxKw5Ke+iLyB8AkouhxtNlEH+e3jyWfOWLeF3AzVgPSKxbzpO4Nj wiqA== MIME-Version: 1.0 X-Received: by 10.107.169.29 with SMTP id s29mr28559168ioe.190.1450061304506; Sun, 13 Dec 2015 18:48:24 -0800 (PST) Received: by 10.36.149.130 with HTTP; Sun, 13 Dec 2015 18:48:24 -0800 (PST) In-Reply-To: References: <9A0DD478-0392-4A53-B53C-86F0035E7385@gmail.com> Date: Mon, 14 Dec 2015 13:48:24 +1100 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ted Hardie , Alan Johnston , "tram@ietf.org" , Brandon Williams Subject: Re: [tram] Recasting STUN ORIGIN as a 'Host' header X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 14 Dec 2015 02:48:26 -0000 On 14 December 2015 at 13:15, Justin Uberti wrote: > at that point we're basically coming up with a more standard and > aesthetically pleasing way of doing what could already be done with USERNAME > (e.g. user@realm.com) Yeah, my thoughts exactly. In that case it would possibly be better to rely on an @domain convention for USERNAME and be done with it. From nobody Sun Dec 13 20:25:31 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957AA1A8A8E for ; Sun, 13 Dec 2015 20:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 ei49nbSSQ87m for ; Sun, 13 Dec 2015 20:25:28 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 68A551A8A99 for ; Sun, 13 Dec 2015 20:25:28 -0800 (PST) Received: by vkha189 with SMTP id a189so146640904vkh.2 for ; Sun, 13 Dec 2015 20:25:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=i15QdjTdK+dZCTnEnLESpqmCYlaOn54b84xtrZjGYYw=; b=k3ftXUjboxC2Wkb9+QVQaSdIONqGeAtLqPlfLbN5eXMhhxDGqPwogeF5sFfDEmUZAu WZIOdqLfbVmRN/qvDob8jriJRgJGAE1LaJxGPvmV9jiy+KxfYgr8PgO7/Vo6f/WpqFHl 1QQdvMcRhCgZoVqI3DMEVU308iD0YtZXDhJ4DiUsYiZ/WQzUFGwxLGZmsc7zTFnsdm2y SQogMGVhO6xijpuR+yf8IIAuasBlW8Khi32fzD5bkItSVdFK2n42G6ZvlgsZUM8iR9UM kXyTJMnruoyhAdd97Cqyjh14wNvZmoIUS1gK2UeqQGwkaLEkr6JlYfCOfZw8Rp0ew+Af gGZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=i15QdjTdK+dZCTnEnLESpqmCYlaOn54b84xtrZjGYYw=; b=JH5XOJCN1xgXzC+m6RQtWWsVA/toEK6hKp2tqYBzirSqrXMlnzWg6dNivnKpDWwVIV ItfUteJr+pae3sBUKqG8hCiOpmqEysNWeHLBmOzEz/LZ4aPPW7OjEVspzReTtB2ti7Mv 8Q8HLQrdHJVhv/ZXSi9xr/hgOhCUDKiePxzsUT65YvbSXnlQKr0nn+7+Amv6xZy6jIVS YzAA+U4Zy8WCyj/enQTcyZSCsCNvDQMZypl9bxQlk4mzQeta7ksT7fkcm3VL9wCLrxRb dgl+jRL9IixadxC5l5ONa4LMMMYsktGZAr08rFgTKbjLOil/ejcs1U8oVoarA96TjJs4 Z6Ug== X-Gm-Message-State: ALoCoQkBsIS+fC/kUa/IosaGzz9N0yID4AZAZnwtcjGJTl7BmsXs6LwS39W5VolDHDTF2illH+JlG28Hfrw5h0TpD7CKIHUqpLFm2mE/Leiw3OEqVcYIqDY= X-Received: by 10.31.169.21 with SMTP id s21mr23995829vke.62.1450067127353; Sun, 13 Dec 2015 20:25:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.219.129 with HTTP; Sun, 13 Dec 2015 20:25:07 -0800 (PST) In-Reply-To: References: <9A0DD478-0392-4A53-B53C-86F0035E7385@gmail.com> From: Justin Uberti Date: Sun, 13 Dec 2015 20:25:07 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114267f00726100526d41090 Archived-At: Cc: Ted Hardie , Alan Johnston , "tram@ietf.org" , Brandon Williams Subject: Re: [tram] Recasting STUN ORIGIN as a 'Host' header X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 14 Dec 2015 04:25:29 -0000 --001a114267f00726100526d41090 Content-Type: text/plain; charset=UTF-8 One possibly important point: USERNAME isn't sent in the initial ALLOCATE. If choosing a correct REALM on the server is important (which was the original justification for this work), we need to either send USERNAME in the initial ALLOCATE, or send up the preferred REALM. On Sun, Dec 13, 2015 at 6:48 PM, Martin Thomson wrote: > On 14 December 2015 at 13:15, Justin Uberti wrote: > > at that point we're basically coming up with a more standard and > > aesthetically pleasing way of doing what could already be done with > USERNAME > > (e.g. user@realm.com) > > Yeah, my thoughts exactly. In that case it would possibly be better > to rely on an @domain convention for USERNAME and be done with it. > --001a114267f00726100526d41090 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One possibly important point: USERNAME isn't sent in t= he initial ALLOCATE. If choosing a correct REALM on the server is important= (which was the original justification for this work), we need to either se= nd USERNAME in the initial ALLOCATE, or send up the preferred REALM.
<= div class=3D"gmail_extra">
On Sun, Dec 13, 20= 15 at 6:48 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 14 Decembe= r 2015 at 13:15, Justin Uberti <ju= berti@google.com> wrote:
> at that point we're basically coming up with a more standard and > aesthetically pleasing way of doing what could already be done with US= ERNAME
> (e.g. user@realm.com)

Yeah, my thoughts exactly.=C2=A0 In that case it would possibly be b= etter
to rely on an @domain convention for USERNAME and be done with it.

--001a114267f00726100526d41090-- From nobody Sun Dec 13 21:18:15 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88A21AC43A for ; Sun, 13 Dec 2015 21:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 t7EBOS87vnNS for ; Sun, 13 Dec 2015 21:18:13 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 731681AC439 for ; Sun, 13 Dec 2015 21:18:13 -0800 (PST) Received: by wmpp66 with SMTP id p66so45256965wmp.1 for ; Sun, 13 Dec 2015 21:18:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UfNzXMtsySdwIf8c8B++Y+Mtnj8o9o6zsuywEo5CO7w=; b=WzVl99UWEkIXJZbO9vbgF3glfczTl3w1y658JfniZB5AEmcbnOwu9dBU/UCU4oEApr bU3Nd7d7LoIQIxLn41AGwowTeSPS3vNLNbHZ7tG/hStlblf5P8DfkjFW5DXIjiQyLi5F yaGD5Eq7dyF9iIIYW5FkeZaDeKcuULzfufTIqLfN0Sx8dTbcs7SSdAncVAeKrk+hNPQ8 e71wUj/64gbY7nLT5pfNeobZK+zwWZyt8MD0zIJMIJy6tKkvBLPbkkP4RaxpXEyoOXDH xRWihPHD3jNOAXExNkj6vG5+lPqQoElTsUDhTYzLJlGvCV36frp6bsqYoqdQ2G022b4W DULA== MIME-Version: 1.0 X-Received: by 10.28.18.138 with SMTP id 132mr21771348wms.6.1450070292081; Sun, 13 Dec 2015 21:18:12 -0800 (PST) Received: by 10.194.173.170 with HTTP; Sun, 13 Dec 2015 21:18:12 -0800 (PST) In-Reply-To: References: <9A0DD478-0392-4A53-B53C-86F0035E7385@gmail.com> Date: Sun, 13 Dec 2015 21:18:12 -0800 Message-ID: From: Oleg Moskalenko To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ted Hardie , Alan Johnston , Martin Thomson , "tram@ietf.org" , Brandon Williams Subject: Re: [tram] Recasting STUN ORIGIN as a 'Host' header X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 14 Dec 2015 05:18:14 -0000 USERNAME is not helpful in the initial ALLOCATION because different realms may have the same (duplicate) names. We cannot require that the name is unique across all realms. On Sun, Dec 13, 2015 at 8:25 PM, Justin Uberti wrote: > One possibly important point: USERNAME isn't sent in the initial ALLOCATE. > If choosing a correct REALM on the server is important (which was the > original justification for this work), we need to either send USERNAME in > the initial ALLOCATE, or send up the preferred REALM. > > On Sun, Dec 13, 2015 at 6:48 PM, Martin Thomson > wrote: >> >> On 14 December 2015 at 13:15, Justin Uberti wrote: >> > at that point we're basically coming up with a more standard and >> > aesthetically pleasing way of doing what could already be done with >> > USERNAME >> > (e.g. user@realm.com) >> >> Yeah, my thoughts exactly. In that case it would possibly be better >> to rely on an @domain convention for USERNAME and be done with it. > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > From nobody Sun Dec 13 21:31:38 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637881ACCED for ; Sun, 13 Dec 2015 21:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 wecu2xj7PD22 for ; Sun, 13 Dec 2015 21:31:35 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 514D01AC3E3 for ; Sun, 13 Dec 2015 21:31:35 -0800 (PST) Received: by vkgj66 with SMTP id j66so50966783vkg.1 for ; Sun, 13 Dec 2015 21:31:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZWoQWv9eX/kQ9SREOUCfysxBb8eKYdwuN9AspcMwCGs=; b=eoUk8EwNm0PD/vNCJ2w6kcr4WfBPGC2Ln1N1uHRWOGtJeRUzj6tiQimZQM98cDSLY2 05zC8yt3a2eq/ebrdVxglxEh/dU4GupiLgkoeIfFcF0mJmAk2MrfNHldHoGLP1RjvW/h TEsfIx99+WPJDUZyzpfQ8MuCO+ewiDCgbbW/1uZbJ6O/rSvrZlcb5hqwdOXDb2Tv5afX UMOKXIsh4r0SoODd1mmei/Mo+rNVRT4nDxw22nNAnzg4Od3Y8fx1yIGbSdfsYUbyWyOk AE9l7GkqUNAPukN0XSvLubyTu4a01tAEqEtJ8+E12XI9t3Gs7kAKr62MGF/sOK4fXK30 JyFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZWoQWv9eX/kQ9SREOUCfysxBb8eKYdwuN9AspcMwCGs=; b=VlAIotFRSkqHe84s5s613ZvOVZKYDVxyORMHrrt0mpQ/08JF4OoNMYqPXarmXucWIv CHjPwPfb1wMpcyzK/hDgQXKUVHYLyQPT8gv+NQy58mijsdnhT7lYVgiiZv+9A7RXERRr y8bwu1YlrHmtpvZkuf6Ilp18Fg6Rm43EaWy+RCv6LKoaALopjbYLw0aUMIHM65Bif/jZ NQuuM0oguuxnKK1HMr66Q9sU/FcR4ZfUy5Mzw4/nktiuLgPCQLBweYP8XNd/elMD/JuO CopFzP24MF752OZxy/ts3JBjjMnQuUjYK2vEZLodgv9uViJQwY4XvdouNEdoihStc/5i 2rQA== X-Gm-Message-State: ALoCoQmDEakWaZAYE2WvxxPf7G9TvAyZgfKuDzOzdomZD5VoXleK5vtnBxM86je7KfeERHdt4pk+p07bJjQ5aqw5txt76RVUEGctE8zItp227+/KiysIi/U= X-Received: by 10.31.137.194 with SMTP id l185mr21011257vkd.98.1450071094278; Sun, 13 Dec 2015 21:31:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.219.129 with HTTP; Sun, 13 Dec 2015 21:31:14 -0800 (PST) In-Reply-To: References: <9A0DD478-0392-4A53-B53C-86F0035E7385@gmail.com> From: Justin Uberti Date: Sun, 13 Dec 2015 21:31:14 -0800 Message-ID: To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=001a11441bbe7993480526d4fc8d Archived-At: Cc: Ted Hardie , Alan Johnston , Martin Thomson , "tram@ietf.org" , Brandon Williams Subject: Re: [tram] Recasting STUN ORIGIN as a 'Host' header X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 14 Dec 2015 05:31:37 -0000 --001a11441bbe7993480526d4fc8d Content-Type: text/plain; charset=UTF-8 USERNAME would have a domain component (@example.com) in this scenario. On Sun, Dec 13, 2015 at 9:18 PM, Oleg Moskalenko wrote: > USERNAME is not helpful in the initial ALLOCATION because different > realms may have the same (duplicate) names. We cannot require that the > name is unique across all realms. > > > On Sun, Dec 13, 2015 at 8:25 PM, Justin Uberti wrote: > > One possibly important point: USERNAME isn't sent in the initial > ALLOCATE. > > If choosing a correct REALM on the server is important (which was the > > original justification for this work), we need to either send USERNAME in > > the initial ALLOCATE, or send up the preferred REALM. > > > > On Sun, Dec 13, 2015 at 6:48 PM, Martin Thomson < > martin.thomson@gmail.com> > > wrote: > >> > >> On 14 December 2015 at 13:15, Justin Uberti wrote: > >> > at that point we're basically coming up with a more standard and > >> > aesthetically pleasing way of doing what could already be done with > >> > USERNAME > >> > (e.g. user@realm.com) > >> > >> Yeah, my thoughts exactly. In that case it would possibly be better > >> to rely on an @domain convention for USERNAME and be done with it. > > > > > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > > --001a11441bbe7993480526d4fc8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
USERNAME would have a domain component (@example.com) in this scenario.

On Sun, Dec 13, 2015 at 9:18 PM, Oleg = Moskalenko <mom040267@gmail.com> wrote:
USERNAME is not helpful in the initial ALLOCATION because d= ifferent
realms may have the same (duplicate) names. We cannot require that the
name is unique across all realms.


On Sun, Dec 13, 2015 at 8:25 PM, Justin Uberti <juberti@google.com> wrote:
> One possibly important point: USERNAME isn't sent in the initial A= LLOCATE.
> If choosing a correct REALM on the server is important (which was the<= br> > original justification for this work), we need to either send USERNAME= in
> the initial ALLOCATE, or send up the preferred REALM.
>
> On Sun, Dec 13, 2015 at 6:48 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>>
>> On 14 December 2015 at 13:15, Justin Uberti <juberti@google.com> wrote:
>> > at that point we're basically coming up with a more stand= ard and
>> > aesthetically pleasing way of doing what could already be don= e with
>> > USERNAME
>> > (e.g. user@realm.com) >>
>> Yeah, my thoughts exactly.=C2=A0 In that case it would possibly be= better
>> to rely on an @domain convention for USERNAME and be done with it.=
>
>
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>

--001a11441bbe7993480526d4fc8d-- From nobody Sun Dec 13 22:59:30 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529AE1B2D0E for ; Sun, 13 Dec 2015 22:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 CVgnqrAWJDPY for ; Sun, 13 Dec 2015 22:59:28 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 E233A1B2D0D for ; Sun, 13 Dec 2015 22:59:27 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id n186so31225541wmn.0 for ; Sun, 13 Dec 2015 22:59:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OHotnt+IvaIAbQqcu0Cm0IkO/OylZDSNtr/0F73+SLw=; b=uGvAk0io6ckxklrE/e95sDs5TFtw0z4Q/CJ1aZNCGCr7MLgItgWswONLvqW88DJi3g t2xbGQQkPvDf2YrTzpT+vanar6NbqRle12jn3iT7aZYeJvoPjNwMCCeT3M63x7bq2YZu LjE9ijGdN70RIrtNyxmCrjCH2n4uR63P61ihjjxThzFqnIeHWDvg5mFIdA4tvDTaGYBc zwmCJ5rriPGj683AMy36YkYMBVwyjRNSJqN4hOJu74tHUUeD188ITh4N8BcBVwg6JL8F dWq4MozL2t+JfyF5u9ZcskMe5dZOjk3+4/4lcAO4tgZeIbcbqXHJ7VdOsUsjQHr0UbI+ 8xfw== MIME-Version: 1.0 X-Received: by 10.194.123.8 with SMTP id lw8mr35145837wjb.72.1450076366463; Sun, 13 Dec 2015 22:59:26 -0800 (PST) Received: by 10.194.173.170 with HTTP; Sun, 13 Dec 2015 22:59:26 -0800 (PST) In-Reply-To: References: <9A0DD478-0392-4A53-B53C-86F0035E7385@gmail.com> Date: Sun, 13 Dec 2015 22:59:26 -0800 Message-ID: From: Oleg Moskalenko To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ted Hardie , Alan Johnston , Martin Thomson , "tram@ietf.org" , Brandon Williams Subject: Re: [tram] Recasting STUN ORIGIN as a 'Host' header X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 14 Dec 2015 06:59:29 -0000 Justin, if we are combining username and domain, then the incentives for having a multi-tenant TURN server are significantly diminishing. One of original advantages of the ORIGIN attribute idea was that the usernames are totally independent. On Sun, Dec 13, 2015 at 9:31 PM, Justin Uberti wrote: > USERNAME would have a domain component (@example.com) in this scenario. > > On Sun, Dec 13, 2015 at 9:18 PM, Oleg Moskalenko > wrote: >> >> USERNAME is not helpful in the initial ALLOCATION because different >> realms may have the same (duplicate) names. We cannot require that the >> name is unique across all realms. >> >> >> On Sun, Dec 13, 2015 at 8:25 PM, Justin Uberti wrote: >> > One possibly important point: USERNAME isn't sent in the initial >> > ALLOCATE. >> > If choosing a correct REALM on the server is important (which was the >> > original justification for this work), we need to either send USERNAME >> > in >> > the initial ALLOCATE, or send up the preferred REALM. >> > >> > On Sun, Dec 13, 2015 at 6:48 PM, Martin Thomson >> > >> > wrote: >> >> >> >> On 14 December 2015 at 13:15, Justin Uberti wrote: >> >> > at that point we're basically coming up with a more standard and >> >> > aesthetically pleasing way of doing what could already be done with >> >> > USERNAME >> >> > (e.g. user@realm.com) >> >> >> >> Yeah, my thoughts exactly. In that case it would possibly be better >> >> to rely on an @domain convention for USERNAME and be done with it. >> > >> > >> > >> > _______________________________________________ >> > tram mailing list >> > tram@ietf.org >> > https://www.ietf.org/mailman/listinfo/tram >> > > > From nobody Mon Dec 14 10:55:34 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 219721B2D7F for ; Mon, 14 Dec 2015 10:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 zX30e_g5n2_8 for ; Mon, 14 Dec 2015 10:55:30 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 B13981B2D7D for ; Mon, 14 Dec 2015 10:55:30 -0800 (PST) Received: by qkfb125 with SMTP id b125so150136555qkf.2 for ; Mon, 14 Dec 2015 10:55:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KSYEqohYs4OssT51Q1EE/DgbQbSRH0hhRf1tojG67ks=; b=qkK4glASJ1w2WwxnU6JbarLfPaA1SoOsWTnGcrKM5KGJQf/MA5u1suxeI9SmFSV8hb vxrstKqc536rxUlbbXzoqWH62LOWl7LbavDiV1gFJV92Wqaywr51rk94s9ZZ7VR8r2vu 87AFimGjuYflG1bI4sFXeAKi3tH3/w0VX7Uhbghxc/AUNnzCBFtVBdPCuDoxYpHec4bY OM9Fx8SKTKyOpew7qfN+3BteisTZD5ChnIkklhnFL8dt31qTOZluPW0T3KwbE+gfEq4x M2QwWPCriCNaNuqabQf3uEwB4gUDr0qk83lIaXryzi3ZTVFil8OZ/Gv8J/T/6fSrSds/ J+CA== MIME-Version: 1.0 X-Received: by 10.55.204.211 with SMTP id n80mr46166002qkl.36.1450119329715; Mon, 14 Dec 2015 10:55:29 -0800 (PST) Received: by 10.55.14.211 with HTTP; Mon, 14 Dec 2015 10:55:29 -0800 (PST) In-Reply-To: References: <9A0DD478-0392-4A53-B53C-86F0035E7385@gmail.com> Date: Mon, 14 Dec 2015 10:55:29 -0800 Message-ID: From: Ted Hardie To: Justin Uberti Content-Type: multipart/alternative; boundary=001a1149ad72879d650526e03758 Archived-At: Cc: Alan Johnston , Martin Thomson , "tram@ietf.org" , Brandon Williams Subject: Re: [tram] Recasting STUN ORIGIN as a 'Host' header X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 14 Dec 2015 18:55:33 -0000 --001a1149ad72879d650526e03758 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Dec 13, 2015 at 8:25 PM, Justin Uberti wrote: > One possibly important point: USERNAME isn't sent in the initial ALLOCATE= . > If choosing a correct REALM on the server is important (which was the > original justification for this work), we need to either send USERNAME in > the initial ALLOCATE, or send up the preferred REALM. > > =E2=80=8BI'm not seeing a downside to sending up the preferred REALM in the= initial allocate, other than it not re-using the known username@realm convention. Am I missing something, or is it just spend the bytes and call it done? regards, Ted=E2=80=8B > On Sun, Dec 13, 2015 at 6:48 PM, Martin Thomson > wrote: > >> On 14 December 2015 at 13:15, Justin Uberti wrote: >> > at that point we're basically coming up with a more standard and >> > aesthetically pleasing way of doing what could already be done with >> USERNAME >> > (e.g. user@realm.com) >> >> Yeah, my thoughts exactly. In that case it would possibly be better >> to rely on an @domain convention for USERNAME and be done with it. >> > > --001a1149ad72879d650526e03758 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Dec 13, 2015 at 8:25 PM= , Justin Uberti <juberti@google.com> wrote:
One possib= ly important point: USERNAME isn't sent in the initial ALLOCATE. If cho= osing a correct REALM on the server is important (which was the original ju= stification for this work), we need to either send USERNAME in the initial = ALLOCATE, or send up the preferred REALM.

<= div>
=E2=80=8BI'm not seeing a downside to sending up the = preferred REALM in the initial allocate, other than it not re-using the kno= wn username@realm convention.=C2=A0 Am I missing something, or is it just s= pend the bytes and call it done?

regards,

Ted=E2=80=8B


=C2=A0
<= div class=3D"gmail_quote">On Sun, Dec 13, 2015 at 6:48 PM, Martin Thomson <= span dir=3D"ltr"><martin.thomson@gmail.com> wrote:
On 14 December 2015 at 13:15, Justin Uberti <juberti@google.com>= wrote:
> at that point we're basically coming up with a more standard and > aesthetically pleasing way of doing what could already be done with US= ERNAME
> (e.g. user@realm.c= om)

Yeah, my thoughts exactly.=C2=A0 In that case it would possibly be b= etter
to rely on an @domain convention for USERNAME and be done with it.


--001a1149ad72879d650526e03758-- From nobody Mon Dec 14 11:02:36 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCC51B2DA8 for ; Mon, 14 Dec 2015 11:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 7e-tBbrv4i1f for ; Mon, 14 Dec 2015 11:02:32 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 BB4251B2DA4 for ; Mon, 14 Dec 2015 11:02:30 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id p66so58532034wmp.0 for ; Mon, 14 Dec 2015 11:02:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EJ15tdNeQG/fanQI4L5fjJo6nZxMtZ3VUC7SB8xRBpQ=; b=NRzRobda6k2TpNy8+Ta0f4Jol9I87AwOKxRcRt+G/MGsVQ6e1AqBWyNT+2iJooHcpi h3ZamWgjTPRChR9IjLu1G7BsEmR0a3qSRqaFuwtSwGGOh0WZxI5uELYIrTn0zRassk9T pieGoyzVJyuB5rDGcpBUq1vqRXdwD+FArDrOf3FKx23GEOkJdVLToQGT7kptyy8JL8y7 pses7G62zQZqRZ+RBEa5LconBdL2M4QyuKj0U0n1nFyL3miwgbtSejsBrSwBHr4n7meo KBEk6H7L2Th2HmoTQD+xUh20jG9RcMemfgLf7jMEFOjI2xIXD9Lld+eL0ru+9qNi4boD OHRg== MIME-Version: 1.0 X-Received: by 10.194.243.103 with SMTP id wx7mr10751308wjc.136.1450119749368; Mon, 14 Dec 2015 11:02:29 -0800 (PST) Received: by 10.194.173.170 with HTTP; Mon, 14 Dec 2015 11:02:29 -0800 (PST) In-Reply-To: References: <9A0DD478-0392-4A53-B53C-86F0035E7385@gmail.com> Date: Mon, 14 Dec 2015 11:02:29 -0800 Message-ID: From: Oleg Moskalenko To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Alan Johnston , Martin Thomson , "tram@ietf.org" , Brandon Williams , Justin Uberti Subject: Re: [tram] Recasting STUN ORIGIN as a 'Host' header X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 14 Dec 2015 19:02:33 -0000 In general case, how the user knows his realm ? He may not know it. The user knows the name, the password, and the TURN server's IP address or URL; knowing the realm is the TURN server's responsibility. And how transferring the realm in an open request is different from transferring the ORIGIN ? Those are metadatas of the same nature. On Mon, Dec 14, 2015 at 10:55 AM, Ted Hardie wrote: > On Sun, Dec 13, 2015 at 8:25 PM, Justin Uberti wrote: >> >> One possibly important point: USERNAME isn't sent in the initial ALLOCATE. >> If choosing a correct REALM on the server is important (which was the >> original justification for this work), we need to either send USERNAME in >> the initial ALLOCATE, or send up the preferred REALM. >> > > I'm not seeing a downside to sending up the preferred REALM in the initial > allocate, other than it not re-using the known username@realm convention. > Am I missing something, or is it just spend the bytes and call it done? > > regards, > > Ted > > > >> >> On Sun, Dec 13, 2015 at 6:48 PM, Martin Thomson >> wrote: >>> >>> On 14 December 2015 at 13:15, Justin Uberti wrote: >>> > at that point we're basically coming up with a more standard and >>> > aesthetically pleasing way of doing what could already be done with >>> > USERNAME >>> > (e.g. user@realm.com) >>> >>> Yeah, my thoughts exactly. In that case it would possibly be better >>> to rely on an @domain convention for USERNAME and be done with it. >> >> > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > From nobody Mon Dec 14 11:11:10 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B6C1B2DBC for ; Mon, 14 Dec 2015 11:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 8GLXQWxYTBvq for ; Mon, 14 Dec 2015 11:11:06 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::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 410BE1B2D9C for ; Mon, 14 Dec 2015 11:11:06 -0800 (PST) Received: by qgev16 with SMTP id v16so37321153qge.0 for ; Mon, 14 Dec 2015 11:11:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x99regMn1J8ejntS4hW+KSSs7jkL2KA6jDDUPmNwJpM=; b=nDsAMUqox0Z3CdwwV6ks2cnGlXZ/4PeJfdQoVw5t5Mi8icW6M8+iP8G84IUN9PbDNp oKvJRlaemYIoU5dx1toUnTpXoN9ieEQdZ2vQpfQOv2JIHD0uUjyk9b915fm448frtUEd pSWheFtoCcG9ZwdzSBR8N07mSWOe9RXbFAUtSOrCj5bVR/kL3cV82/EltZZvsGkGg+uG 4ucRmKHnQI/SiWccniPyHUrn4IhSoTYNoGgpZuIvSY1ErbTkHNE0oeWYtY9O3etxLLiV c9DjwSUSHXgn7u2t8pXiJYAPWZV8OaR+5GOIOWJqkYO1sf9tpunFGNUNVwBo0WHG77wE CxbA== MIME-Version: 1.0 X-Received: by 10.140.104.167 with SMTP id a36mr42479065qgf.19.1450120265415; Mon, 14 Dec 2015 11:11:05 -0800 (PST) Received: by 10.55.14.211 with HTTP; Mon, 14 Dec 2015 11:11:05 -0800 (PST) In-Reply-To: References: <9A0DD478-0392-4A53-B53C-86F0035E7385@gmail.com> Date: Mon, 14 Dec 2015 11:11:05 -0800 Message-ID: From: Ted Hardie To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=001a1134ee5c4d4ad90526e06f20 Archived-At: Cc: Alan Johnston , Martin Thomson , "tram@ietf.org" , Brandon Williams , Justin Uberti Subject: Re: [tram] Recasting STUN ORIGIN as a 'Host' header X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 14 Dec 2015 19:11:08 -0000 --001a1134ee5c4d4ad90526e06f20 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Dec 14, 2015 at 11:02 AM, Oleg Moskalenko wrote: > In general case, how the user knows his realm ? He may not know it. > The user knows the name, the password, and the TURN server's IP > address or URL; knowing the realm is the TURN server's responsibility. > > =E2=80=8BIf I understood Justin's drift on this, the application needs to= know the realm, not the user. It could be set by the application just as HOST would have been set. regards, Ted=E2=80=8B > And how transferring the realm in an open request is different from > transferring the ORIGIN ? Those are metadatas of the same nature. > > On Mon, Dec 14, 2015 at 10:55 AM, Ted Hardie wrote: > > On Sun, Dec 13, 2015 at 8:25 PM, Justin Uberti > wrote: > >> > >> One possibly important point: USERNAME isn't sent in the initial > ALLOCATE. > >> If choosing a correct REALM on the server is important (which was the > >> original justification for this work), we need to either send USERNAME > in > >> the initial ALLOCATE, or send up the preferred REALM. > >> > > > > I'm not seeing a downside to sending up the preferred REALM in the > initial > > allocate, other than it not re-using the known username@realm > convention. > > Am I missing something, or is it just spend the bytes and call it done? > > > > regards, > > > > Ted > > > > > > > >> > >> On Sun, Dec 13, 2015 at 6:48 PM, Martin Thomson < > martin.thomson@gmail.com> > >> wrote: > >>> > >>> On 14 December 2015 at 13:15, Justin Uberti > wrote: > >>> > at that point we're basically coming up with a more standard and > >>> > aesthetically pleasing way of doing what could already be done with > >>> > USERNAME > >>> > (e.g. user@realm.com) > >>> > >>> Yeah, my thoughts exactly. In that case it would possibly be better > >>> to rely on an @domain convention for USERNAME and be done with it. > >> > >> > > > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > > --001a1134ee5c4d4ad90526e06f20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Dec 14, 2015 at 11:02 A= M, Oleg Moskalenko <mom040267@gmail.com> wrote:
In general case, how the= user knows his realm ? He may not know it.
The user knows the name, the password, and the TURN server's IP
address or URL; knowing the realm is the TURN server's responsibility.<= br>
=E2=80=8BIf I understood Justin's drift= on this, the application needs to know the realm, not the user.=C2=A0 It c= ould be set by the application just as HOST would have been set.

regards,

Ted=E2=80=8B


=C2= =A0
And how transferring the realm in an open request is different from
transferring the ORIGIN ? Those are metadatas of the same nature.

On Mon, Dec 14, 2015 at 10:55 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
> On Sun, Dec 13, 2015 at 8:25 PM, Justin Uberti <juberti@google.com> wrote:
>>
>> One possibly important point: USERNAME isn't sent in the initi= al ALLOCATE.
>> If choosing a correct REALM on the server is important (which was = the
>> original justification for this work), we need to either send USER= NAME in
>> the initial ALLOCATE, or send up the preferred REALM.
>>
>
> I'm not seeing a downside to sending up the preferred REALM in the= initial
> allocate, other than it not re-using the known username@realm conventi= on.
> Am I missing something, or is it just spend the bytes and call it done= ?
>
> regards,
>
> Ted
>
>
>
>>
>> On Sun, Dec 13, 2015 at 6:48 PM, Martin Thomson <martin.thomson@gmail.com>
>> wrote:
>>>
>>> On 14 December 2015 at 13:15, Justin Uberti <juberti@google.com> wrote:
>>> > at that point we're basically coming up with a more s= tandard and
>>> > aesthetically pleasing way of doing what could already be= done with
>>> > USERNAME
>>> > (e.g. user@realm.com)
>>>
>>> Yeah, my thoughts exactly.=C2=A0 In that case it would possibl= y be better
>>> to rely on an @domain convention for USERNAME and be done with= it.
>>
>>
>
>
> __________________= _____________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>

--001a1134ee5c4d4ad90526e06f20-- From nobody Mon Dec 14 11:36:41 2015 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940A21B2E08 for ; Mon, 14 Dec 2015 11:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 BeX5-0ohrSKS for ; Mon, 14 Dec 2015 11:36:33 -0800 (PST) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 9DD781B2E07 for ; Mon, 14 Dec 2015 11:36:33 -0800 (PST) Received: by vkgj66 with SMTP id j66so64410737vkg.1 for ; Mon, 14 Dec 2015 11:36:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TQz0hcoHbQptf9Yryyikc9461/FebIuv8SkNKDJDdWI=; b=g/oPhy59+9Dh85qBasdcCldVFlPSU5HuNqHvAAAdDSGH9mFNOOjZqcG5pjOPQGGfnE GLpN1XbJzHJPxvMlzpRQ8TZ478dRplBRdb+h67uhMV4Ht0coXYKayNOHBMAmhYlqJ1q2 3Je4gZRhe3rpTxHTOk0hk+sAfk7X+dhR++wdA7Z3w7oCdj0Qm18IxoWOBqN1mDXemW0l 7/RwewErw5BFo5d0c2Nar+sLIW23eJAm6Qc6dv11nsHsiW2AAQwFJ86ltSemdJkqTF86 4cDltSsxgR+8Z2ZJjOTqHlAYNZGcIgF0HugYB5oJ/EqEVSK+h6mscvz9J87WM/gjQlzt tKRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=TQz0hcoHbQptf9Yryyikc9461/FebIuv8SkNKDJDdWI=; b=ejpqrKAf4lIFbx9EWqjooT5mySoUJZT+ZNdBZl6Fg4G8kqWfSJ4ob4IcYhaMIsWRsU 3VpaWwNi20pv+H9oY+rYYOxq1hgtccnhOPhDW3PYXpnv2yXEL+WlWnkLNZhPVBTTh706 5ttQg+rCfrdVGIduUXlA9DK4JF2DZflFHxfpctJZEdYHOFVMtUmSKcAB84tJ3vThyxk3 01/TfR7Li+pqgAr1rxlQzNvv7aec6itGKW86OFyoZszK3Gozs7JpnkLfrWb0M7CoTmob NNThbtQoSJiQBYlTGCx/iQCWiWufE0vKRSZ1rXtzNp0WI5ZeFG5lvPpAupP3mpWK5D71 zeaQ== X-Gm-Message-State: ALoCoQkuITtudffzAp54AJdj7EjFCTA0Ii95fBwcm1+2tUkOEx/EqZNpFXakKa+Y52gVRK6msnBCDaVujMT6yDSpeJXMUnxGPFGShbvY3+bcKRjVmn2dDh4= X-Received: by 10.31.44.77 with SMTP id s74mr25690977vks.4.1450121792616; Mon, 14 Dec 2015 11:36:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.219.129 with HTTP; Mon, 14 Dec 2015 11:36:13 -0800 (PST) In-Reply-To: References: <9A0DD478-0392-4A53-B53C-86F0035E7385@gmail.com> From: Justin Uberti Date: Mon, 14 Dec 2015 11:36:13 -0800 Message-ID: To: Ted Hardie Content-Type: multipart/alternative; boundary=001a11c075a254d9f70526e0ca6b Archived-At: Cc: Oleg Moskalenko , Alan Johnston , Martin Thomson , "tram@ietf.org" , Brandon Williams Subject: Re: [tram] Recasting STUN ORIGIN as a 'Host' header X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 14 Dec 2015 19:36:35 -0000 --001a11c075a254d9f70526e0ca6b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Exactly what Ted said. The difference between REALM/HOST and ORIGIN is that the application needs to set REALM/HOST, but ORIGIN would be auto-set by the browser. The key outstanding question IMO is whether setting REALM properly is actually useful, versus simply having the application include the domain in USERNAME. Chrome uses REALM solely to compute HA1 and thereby MESSAGE-INTEGRITY; since HA1 is defined as MD5(username ":" realm ":" SASLprep(password)), the benefit of using REALM would be that you can use existing password databases that compute HA1 with username/realm specified separately. However, I'd like someone who actually has to deal with this sort of thing to weigh in. On Mon, Dec 14, 2015 at 11:11 AM, Ted Hardie wrote: > On Mon, Dec 14, 2015 at 11:02 AM, Oleg Moskalenko > wrote: > >> In general case, how the user knows his realm ? He may not know it. >> The user knows the name, the password, and the TURN server's IP >> address or URL; knowing the realm is the TURN server's responsibility. >> >> =E2=80=8BIf I understood Justin's drift on this, the application needs t= o know > the realm, not the user. It could be set by the application just as HOST > would have been set. > > regards, > > Ted=E2=80=8B > > > > >> And how transferring the realm in an open request is different from >> transferring the ORIGIN ? Those are metadatas of the same nature. >> >> On Mon, Dec 14, 2015 at 10:55 AM, Ted Hardie wrote: >> > On Sun, Dec 13, 2015 at 8:25 PM, Justin Uberti >> wrote: >> >> >> >> One possibly important point: USERNAME isn't sent in the initial >> ALLOCATE. >> >> If choosing a correct REALM on the server is important (which was the >> >> original justification for this work), we need to either send USERNAM= E >> in >> >> the initial ALLOCATE, or send up the preferred REALM. >> >> >> > >> > I'm not seeing a downside to sending up the preferred REALM in the >> initial >> > allocate, other than it not re-using the known username@realm >> convention. >> > Am I missing something, or is it just spend the bytes and call it done= ? >> > >> > regards, >> > >> > Ted >> > >> > >> > >> >> >> >> On Sun, Dec 13, 2015 at 6:48 PM, Martin Thomson < >> martin.thomson@gmail.com> >> >> wrote: >> >>> >> >>> On 14 December 2015 at 13:15, Justin Uberti >> wrote: >> >>> > at that point we're basically coming up with a more standard and >> >>> > aesthetically pleasing way of doing what could already be done wit= h >> >>> > USERNAME >> >>> > (e.g. user@realm.com) >> >>> >> >>> Yeah, my thoughts exactly. In that case it would possibly be better >> >>> to rely on an @domain convention for USERNAME and be done with it. >> >> >> >> >> > >> > >> > _______________________________________________ >> > tram mailing list >> > tram@ietf.org >> > https://www.ietf.org/mailman/listinfo/tram >> > >> > > --001a11c075a254d9f70526e0ca6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Exactly what Ted said.=C2=A0

The differ= ence between REALM/HOST and ORIGIN is that the application needs to set REA= LM/HOST, but ORIGIN would be auto-set by the browser.

<= div>The key outstanding question IMO is whether setting REALM properly is a= ctually useful, versus simply having the application include the domain in = USERNAME. Chrome uses REALM solely to compute HA1 and thereby MESSAGE-INTEG= RITY; since HA1 is defined as=C2=A0MD5(username ":" realm ":" SASLprep(passwo= rd)),=C2=A0the benefit of using REALM would be that you can use exis= ting password databases that compute HA1 with username/realm specified sepa= rately. However, I'd like someone who actually has to deal with this so= rt of thing to weigh in.



On Mon, Dec 14, 2015 at 11= :11 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
On Mon, Dec 14, 2015 at 11:02 AM, Oleg Moskalenko <mom040267@gma= il.com> wrote:
In general case, how the user knows = his realm ? He may not know it.
The user knows the name, the password, and the TURN server's IP
address or URL; knowing the realm is the TURN server's responsibility.<= br>
=E2=80=8BIf I understood Justin'= s drift on this, the application needs to know the realm, not the user.=C2= =A0 It could be set by the application just as HOST would have been set.
regards,

Ted=E2=80=8B

=
=C2=A0
And how transferring the realm in an open request is different from
transferring the ORIGIN ? Those are metadatas of the same nature.

On Mon, Dec 14, 2015 at 10:55 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
> On Sun, Dec 13, 2015 at 8:25 PM, Justin Uberti <juberti@google.com> wrote:
>>
>> One possibly important point: USERNAME isn't sent in the initi= al ALLOCATE.
>> If choosing a correct REALM on the server is important (which was = the
>> original justification for this work), we need to either send USER= NAME in
>> the initial ALLOCATE, or send up the preferred REALM.
>>
>
> I'm not seeing a downside to sending up the preferred REALM in the= initial
> allocate, other than it not re-using the known username@realm conventi= on.
> Am I missing something, or is it just spend the bytes and call it done= ?
>
> regards,
>
> Ted
>
>
>
>>
>> On Sun, Dec 13, 2015 at 6:48 PM, Martin Thomson <martin.thomson@gmail.com>
>> wrote:
>>>
>>> On 14 December 2015 at 13:15, Justin Uberti <juberti@google.com> wrote:=
>>> > at that point we're basically coming up with a more s= tandard and
>>> > aesthetically pleasing way of doing what could already be= done with
>>> > USERNAME
>>> > (e.g. user@realm.com)
>>>
>>> Yeah, my thoughts exactly.=C2=A0 In that case it would possibl= y be better
>>> to rely on an @domain convention for USERNAME and be done with= it.
>>
>>
>
>
> _______________________________________________<= br> > tram mailing list
> tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram
>


--001a11c075a254d9f70526e0ca6b--