Re: [rtcweb] URI schemes for TURN and STUN

Harald Alvestrand <harald@alvestrand.no> Tue, 01 November 2011 20:54 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E98821F8DF6; Tue, 1 Nov 2011 13:54:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.449
X-Spam-Level:
X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thr-M0AunLLZ; Tue, 1 Nov 2011 13:54:39 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id F2C3221F8DA4; Tue, 1 Nov 2011 13:54:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1270D39E13B; Tue, 1 Nov 2011 21:44:21 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8SW1uNsqm46; Tue, 1 Nov 2011 21:44:20 +0100 (CET)
Received: from [172.20.78.134] (63-145-238-4.dia.static.qwest.net [63.145.238.4]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 982C039E04C; Tue, 1 Nov 2011 21:44:18 +0100 (CET)
Message-ID: <4EB05A23.3060101@alvestrand.no>
Date: Tue, 01 Nov 2011 13:44:19 -0700
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
References: <4EAC6BF4.2000604@alvestrand.no> <CALiegf=f4kFzyDLWK+Y5vbuCEJFXX590+VuZ4bbnHZnvX0CoBA@mail.gmail.com> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp>
In-Reply-To: <4EAF9391.5040209@it.aoyama.ac.jp>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: Ned Freed <ned.freed@mrochek.com>, Keith Moore <moore@network-heretics.com>, Keith Moore <moore@cs.utk.edu>, Behave WG <behave@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] URI schemes for TURN and STUN
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Nov 2011 20:54:39 -0000

Top-posting a general principle, detailed comment at the bottom....

For all URI schemes, I think the URI needs to contain all the 
information you need in order to make contact with the service; you 
can't negotiate until you've made contact.
(the process may involve things like "resolve through a resolution 
mechanism like DNS" or "get authorization tokens from somewhere else").

In the case of TURN, you need to distinguish between TCP, UDP and TLS, 
and you need to make that determination before you send the first 
packet. That means the distinguishing information between those three 
things belongs in the URL; I don't think the scheme is a good place to 
encode it.

On 10/31/2011 11:37 PM, "Martin J. Dürst" wrote:
>
>
> On 2011/11/01 0:33, Keith Moore wrote:
>>
>> On Oct 31, 2011, at 10:57 AM, Marc Petit-Huguenin wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Hi Martin,
>>>
>>> So I understand Roy's email as saying in fact the opposite of what 
>>> Harald said,
>>> i.e. that using an "s" suffix to signify security is a good thing.
>>>
>>> What is your opinion on defining a generic scheme suffix (i.e. "+s" 
>>> or "+sec")
>>> that would indicate a well defined set of security properties that 
>>> could apply
>>> to any scheme, (vs the current "s" suffix where security properties 
>>> has to be
>>> defined scheme by scheme)?
>>
>>
>> There is no "well defined set of security properties that could apply 
>> to any scheme".   Security properties necessarily vary depending on 
>> the way a resource is used, the threat model, and so forth.
>
> Here I agree with Keith.
>
>> Also, the idea that there should be a "secure" bit in a URI scheme, 
>> to distinguish it from the "insecure" form of a URL, doesn't make 
>> much sense.  You always want to use the best security that's available.
>
> You always want the best security you're willing to pay for.
>
>> You don't want that to depend on the URI scheme.
>
> Ideally not, but in actual operation, it made a lot of sense for HTTP 
> as Roy has explained.
I think it made a lot of sense because the port 443 convention meant 
that you had to know whether or not to use SSL had to be known before 
you sent the SYN packet.