Re: [rtcweb] URI schemes for TURN and STUN

Keith Moore <moore@network-heretics.com> Thu, 03 November 2011 19:29 UTC

Return-Path: <moore@network-heretics.com>
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 5A7861F0CAB; Thu, 3 Nov 2011 12:29:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.979
X-Spam-Level:
X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=0.621, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 2DsyfF0iiMZq; Thu, 3 Nov 2011 12:29:28 -0700 (PDT)
Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id A1CBE1F0CB6; Thu, 3 Nov 2011 12:29:28 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 35DA920A74; Thu, 3 Nov 2011 15:29:27 -0400 (EDT)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 03 Nov 2011 15:29:27 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=oY+zzfrkNq8DL6JrAJJ9F05oL8Y=; b=Gk L1wcw8MLB2QsMu8hHg6u06Pw37yJT1tNSeTQIsbrMfAiApIZLKN+7+KNNyHhbvhb jq9IljEZj3+cY2Wn60iyCeFnSwekD/xX1rjVWYJlq0eoLvOBbADtJPH8UvdZSrp2 DCCK1tIagj8dz7wJ4cuPj1ofNV7U5Sa+dquasTgws=
X-Sasl-enc: NkDtGeB2cZwLgDA7TAhiJfVtigovcopaL4XnYFrirMcv 1320348567
Received: from rlmartin.hq.corp.pbs.org (unknown [149.48.225.2]) by mail.messagingengine.com (Postfix) with ESMTPA id EBF928E0FB9; Thu, 3 Nov 2011 15:29:26 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Keith Moore <moore@network-heretics.com>
In-Reply-To: <CABcZeBNDW=29ufn0FkObm1prqu6_PjX9CBJq8_UOdzom7pD5gg@mail.gmail.com>
Date: Thu, 3 Nov 2011 15:29:26 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <ADADD239-10D3-49C1-BA4E-6380E99E9246@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> <4EAF9391.5040209@it.aoyama.ac.jp> <5B7AE760-DBD1-46F9-89D9-E8F7CA56F111@network-heretics.com> <CABcZeBNDW=29ufn0FkObm1prqu6_PjX9CBJq8_UOdzom7pD5gg@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Fri, 04 Nov 2011 08:52:42 -0700
Cc: Keith Moore <moore@cs.utk.edu>, "rtcweb@ietf.org" <rtcweb@ietf.org>, Ned Freed <ned.freed@mrochek.com>, 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: Thu, 03 Nov 2011 19:29:29 -0000

On Nov 3, 2011, at 2:58 PM, Eric Rescorla wrote:

> On Tue, Nov 1, 2011 at 5:05 AM, Keith Moore <moore@network-heretics.com>; wrote:
>>> 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.
>> 
>> agree.  I just don't think it's a good idea to establish a new _convention_.
> 
> i don't really understand what you're arguing here.
> 
> The relevant issue is that we want to have a reference that Bob can provide
> to Alice that guarantees that when it's dereferenced it provides a minimum
> set of security properties.
> 
> Let's imagine some hypothetical new protocol which is like HTTP but not HTTP,
> say HTTQ. It runs over TCP so you can use it directly or over TLS (i.e.,
> HTTP/TCP or HTTP/TLS/TCP). We're planning to define a new URI for it,
> httq://.../. How do you propose to provide the above security property?

If you're going to define a new protocol, it should always use TLS (or it should always provide a minimum set of security properties).  Then you define a single URI type for the new protocol, and it doesn't need the security flag.

It's only when you're trying to retro-fit security into an existing protocol that is already widely used, doesn't inherently provide a reasonable level of security for that application, and the security isn't securely negotiated in-band, that you need a security flag in the URI.

More generally, the right place to set the minimum security level is in the application, not in the name of the resource.  The reason you need https vs. http is that the two are really different protocols, and the client has to know a priori whether to send "GET..." or to negotiate the TLS layer after the TCP open completes.  

Keith