Re: [rtcweb] URI schemes for TURN and STUN

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Tue, 01 November 2011 06:37 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
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 DF1F911E8163 for <rtcweb@ietfa.amsl.com>; Mon, 31 Oct 2011 23:37:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.89
X-Spam-Level:
X-Spam-Status: No, score=-98.89 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, SARE_LWSHORTT=1.24, 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 KEZBp2dmDyHw for <rtcweb@ietfa.amsl.com>; Mon, 31 Oct 2011 23:37:36 -0700 (PDT)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 938B211E808E for <rtcweb@ietf.org>; Mon, 31 Oct 2011 23:37:29 -0700 (PDT)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id pA16bD0o015541 for <rtcweb@ietf.org>; Tue, 1 Nov 2011 15:37:17 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 1e1f_16bc_ef0b0728_0453_11e1_abe7_001d096c5782; Tue, 01 Nov 2011 15:37:13 +0900
Received: from [IPv6:::1] ([133.2.210.1]:60382) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S1566BA1> for <rtcweb@ietf.org> from <duerst@it.aoyama.ac.jp>; Tue, 1 Nov 2011 15:37:17 +0900
Message-ID: <4EAF9391.5040209@it.aoyama.ac.jp>
Date: Tue, 01 Nov 2011 15:37:05 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Keith Moore <moore@network-heretics.com>
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>
In-Reply-To: <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Ned Freed <ned.freed@mrochek.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, Keith Moore <moore@cs.utk.edu>, Behave WG <behave@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 06:37:37 -0000

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.

> The "s" convention was a hack to distinguish "x over SSL" from "x" for all of the URIs that existed before SSL was well-established, because those protocols didn't (then) have a way to negotiate security in-band.   It made sense as a short term hack,

Yes. It also makes sense in current-day operation.

> but not as an architectural feature.   It's not something that we want to propagate to new URI types, neither in the form of an "s" suffix, nor as any other syntactic convention.

In most cases probably not. But there may be cases similar to HTTP/S 
where it makes sense. Each case has to be analyzed independently.

Regards,    Martin.

> Keith
>
>