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

[Marc Petit-Huguenin <[e-mail]>]

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


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