Re: [rtcweb] URI schemes for TURN and STUN

[Eric Rescorla <[e-mail]>]

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

Sure.


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

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.

-Ekr