[BEHAVE] Using TLS with a "turn:" URI [was Re: Opsdir Review of draft-ietf-behave-turn-uri-03.txt]

[Marc Petit-Huguenin <petithug at acm.org>]

Margaret Wasserman wrote:
> 
> Hi Marc,
> 
> On Oct 25, 2009, at 3:03 PM, Marc Petit-Huguenin wrote:
>>>
[...]
>> You are absolutely right, this is a bug in the spec, the ordered list
>> of TURN
>> transports should have been filtered by the <scheme> used.
>>
>> I propose to replace "...the TURN transports supported by the
>> application..." by
>> "...the filtered TURN transports supported by the application..." in
>> step #1 and
>> #2 and to add the following paragraph before paragraph 6:
>>
>> "After verifying the validity of the URI elements, the algorithm
>> filters the list of TURN transports supported by the application by
>> keeping only the UDP and TCP TURN transports if the <scheme> is
>> defined as "turn" and by keeping only the TLS TURN transport if the
>> <scheme> is defined as "turns".  If the list of TURN transports is
>> empty after this filtering, the resolution MUST stop with an error."

I think that this is not completely correct.

The reason to have TLS in the leg between the TURN client and the TURN server in
the first place was not for security reasons, but because this is the only way
to be sure that a NAT that knows about the XOR trick will not modify the IP
addresses in the TURN messages.  Because TURN is the lowest priority protocol in
ICE, it was designed in a way that it is always possible to find a path for the
media (This is why I think that do not make TLS mandatory in TURN was a mistake,
but that's another topic).

On the other hand, there is no security downside of "upgrading" a TURN
connection from TCP or UDP to TLS, so I think that a "turn:" URI should be able
to use a TLS connection if available.  The new text would become this:

"After verifying the validity of the URI elements, the algorithm
 filters the list of TURN transports supported by the application by
 removing the UDP and TCP TURN transport if the <scheme> is defined as
 "turns".  If the list of TURN transports is empty after this
 filtering, the resolution MUST stop with an error."

I am interested on feedback from the WG on this.  If there is no feedback by
November 9th, the next release will contain this text.

Thanks.

-- 
Marc Petit-Huguenin
Personal email: marc at petit-huguenin.org
Professional email: petithug at acm.org
Blog: http://blog.marc.petit-huguenin.org