Re: [rtcweb] URI schemes for TURN and STUN

Eric Rescorla <> Thu, 03 November 2011 19:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2DF3011E80AE; Thu, 3 Nov 2011 12:54:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d5haqR-opkEd; Thu, 3 Nov 2011 12:54:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5927321F843B; Thu, 3 Nov 2011 12:54:05 -0700 (PDT)
Received: by ywt2 with SMTP id 2so1942922ywt.31 for <multiple recipients>; Thu, 03 Nov 2011 12:54:05 -0700 (PDT)
Received: by with SMTP id k34mr2671990yad.26.1320349431235; Thu, 03 Nov 2011 12:43:51 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 3 Nov 2011 12:43:10 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Eric Rescorla <>
Date: Thu, 3 Nov 2011 12:43:10 -0700
Message-ID: <>
To: Keith Moore <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Keith Moore <>, "" <>, Ned Freed <>, Behave WG <>
Subject: Re: [rtcweb] URI schemes for TURN and STUN
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Nov 2011 19:54:06 -0000

On Thu, Nov 3, 2011 at 12:29 PM, Keith Moore <>; wrote:
> On Nov 3, 2011, at 2:58 PM, Eric Rescorla wrote:
>> On Tue, Nov 1, 2011 at 5:05 AM, Keith Moore <>; 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.

OK. I agree with this.

> 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.

I don't agree with this, however. The reason you need https: versus
http: is that it's the server providing the reference and it's the
only one that knows whether the resource is to be accessed over TLS or

As a point of historical trivia, the initial use of this general
convention wasn't https:// but rather shttp://, and the intent of the
originator, Allan Schiffman, was to make it impossible for a
non-Secure HTTP capable client to accidentally reference via HTTP a
resource which should be secure.