Re: [rtcweb] URI schemes for TURN and STUN

[Eric Rescorla <[e-mail]>]

On Sat, Oct 29, 2011 at 9:40 PM, Harald Alvestrand <[e-mail]> 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.

I haven't formed an opinion on the value of turn[s] URIs one way or
another, but...

What you say above is absolutely true, but there is a tradeoff here. If you just
provide a URI with no indication of the expected security mechanism, and
rely on in-band negotiation, then an active attacker can force the client down
to the weakest security mechanism (a downgrade attack). So, for instance,
if the client supports both TURN and TURN over TLS, the attacker can
impersonate a server which supports only TURN and force the client
to accept that. By contrast, if the URI indicates a minimal security
mechanism that is
sufficiently strong, then this form of attack is not possible. Obviously, the
user could configure his client to only support secure connections
(via whatever mechanism) but this is less convenient.

Another point in the design space is to require some specific security mechanism
that is strong enough to authenticate the server and then use that mechanism
to support secure negotiation of the real mechanism. Unfortunately, the only
widely supported mechanism that meets that standard is TLS, so this isn't
much of an improvement.

-Ekr