Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN

[Harald Alvestrand <[e-mail]>]

On 10/30/2011 08:34 AM, Marc Petit-Huguenin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/30/2011 12:44 AM, Keith Moore wrote:
>> On Oct 30, 2011, at 12:40 AM, Harald Alvestrand wrote:
>>
>>> On 10/29/2011 04:23 PM, Marc Petit-Huguenin wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 10/29/2011 03:36 PM, Iñaki Baz Castillo wrote:
>>>>> 2011/10/29 Harald Alvestrand<[e-mail]>:
>>>>>> - I do not think it's appropriate to use "turn" and "turns" for indicating
>>>>>> transport. Polluting the URI namespace with more configuration parameters in
>>>>>> the form of trailing "s" is a Bad Thing.
>>>>> But there should be some way to indicate that a TURN server listens in
>>>>> TLS, right?
>>>>>
>>>> We should continue this discussion in BEHAVE, but I would like to ask the OP to
>>>> send a pointer on the RFC or discussion that says that using a trailing "s" to
>>>> indicate security is a bad thing.
>>> I'll have to forward this question to the apps ADs of a few years ago about whether there's documentation for it. It does not seem to have been captured in an RFC that I can find; discussion was in the ~2000-2005 timeframe.
>>>
>>> The short version, from memory: Doing "s" locks you into one and exactly one security scheme, and prevents you from saying anything about the requisite parameters for that scheme, while using AUTH parameters such as POP or in-band negotiation such as IMAP  are much more flexible approaches.
>> Security schemes change over time as new (presumably better) ones appear, and vulnerabilities are discovered in old ones.   There's nothing inherently wrong with having a URI scheme end in "s".  But it's a Bad Idea to promote the notion that "s" means "security".
>>
> I understand the "s" suffix as meaning "the transport to the next app level hop
> MUST be secure", which actually means TLS, but it could be anything else.
err..... TLS with a NULL cipher and no certification checking is NOT secure.
Neither is TLS with 40-bit RC4, although it takes a little effort to 
break (CPU-minutes).
>    I
> agree that it would have been a better idea to define a scheme separator like in
> [1], to not have to register multiple schemes (i.e. "sip+s:", "http+s:",
> "turn+s:", etc...).  Similarly, one can define a suffix (say +sec) that means
> e2e security like in [2].  That would give "sip+sec:" for e2e SIP security, and
> "turn+sec:" for a secure transport and allocation.
If we need to indicate security functionality requirements in the URL (a 
doubtful proposition), I think the better solution is

<scheme>:<stuff>;auth=cert;crypt=tls

or someting like that (with suitable profiling for those values)

In TURN's case, we have exactly 3 currently defined operational modes, 
which require you to know which one to select before you start 
connecting, so

turn://user@host;mode=<udp, tcp or tls>

seems like a reasonable thing to do.

Reading security as a binary "either it's secure or it's not" is usually 
not a sign that the requirements for the situation have been deeply 
analyzed.

>
> [1] http://tools.ietf.org/html/draft-wood-tae-specifying-uri-transports
> [2] http://tools.ietf.org/html/draft-gurbani-sip-sipsec
>
> - -- 
> Marc Petit-Huguenin
> Personal email: [e-mail]
> Professional email: [e-mail]
> Blog: http://blog.marc.petit-huguenin.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iEYEARECAAYFAk6tboMACgkQ9RoMZyVa61eTTACgoDKJ5LQ1KFwFH1Epnc2x/iH4
> x90AoJ+ogURbCcw682se9lj+luF1gQgs
> =MfbQ
> -----END PGP SIGNATURE-----
>