Re: [rtcweb] URI schemes for TURN and STUN

[Keith Moore <[e-mail]>]

On Nov 3, 2011, at 3:43 PM, Eric Rescorla wrote:

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

Right, but it has to communicate that information to the client somehow, and the URI is really the only place to do it.  

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

I wasn't aware of the originator's name, but certainly agree with the intent.   

There's a huge problem with in-band negotiation of security if either (a) it's feasible for an attacker to get the client to downgrade to insufficient security, or (b) it's so much work for the client to negotiate good security that clients tend to be lazy and not bother to even try. 

One thing I find fairly annoying about URIs in that we'd really like to be able to attach attributes and/or constraints to a URI (like what the minimum security requirements should be) for the purpose of things like bookmarks, but we don't have a uniform URI syntax that lets us define such attributes and/or constraints while still being able to easily separate them from the name of the resource being referred to.

Keith