Subject: [Ietf-behave] TURN Issue #5: the STARTTLS problem

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 5 Dec 2005 12:24:06 -0800 (PST)

Right now, there is a single TCP port associated with TURN. 
Unfortunately, there are two distinct uses for TCP:

1. for issuing a Shared Secret request, in which case the message sent 
by the client after opening the connection will be a TLS ClientHello.

2. for obtaining TCP bindings, in which case the message sent by the 
client after opening the connection will be a STUN Binding Request.

If we allow binding requests over TCP/TLS, that adds another case.

This is not a new problem; many protocols have faced the challenge of 
muxing an application protocol and its TLS version together. There are 
only a finite set of solutions to it:

1. Different well-known ports for TCP/TLS and just TCP. This is in 
common usage today with HTTP (443 for HTTP over TCP/TLS and 80 for HTTP 
over TCP). This approach has the drawback of halving the number of ports 
that can be registered, and for this reason there has historically been 
pushback on it.

2. DNS NAPTR records to discover dynamic ports for the protocol versions 
over TLS/TCP and just TCP. SIP does this (RFC3263), though it also 
defines a pair of well-known ports (approach 1).

3. STARTTLS procedures. SMTP and HTTP both have procedures that define 
application layer messages that coordinate an upgrade to TLS.

4. Have the server figure out whether the first message is STUN or TLS, 
and direct it appropriately.

Getting this addresses is probably something that belongs in the core 
STUn protocol. Generally, you don't want to mix the transport and 
methods so tightly together as we have them today.

I'm inclined to go with #2, with the caveat that there is already a 
default stun udp and tcp port and those would remain valid (see open 
issue #6 on applicability to turn).

Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@xxxxxxxxx                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Saikat Guha <[email-masked]>
Date: Tue, 6 Dec 2005 02:00:58 -0800 (PST)

On Mon, 2005-12-05 at 15:23 -0500, Jonathan Rosenberg wrote:
> 1. Different well-known ports [...]
> 2. DNS NAPTR records to discover dynamic ports [...]
> 3. STARTTLS procedures. [...]
> 4. Have the server figure out whether the first message is STUN or TLS[...]
>

Would #2 require that TURN servers (and potentially ICE endpoints) have
some DNS server where they can advertise their dynamic ports, hopefully
through some secure dynamic-DNS-update protocol? If so, is the presence
of such a DNS-relationship already required?

Given how hard it is to convince my IT department to add just a CNAME,
#2 would be at the bottom of my preference list. #3 makes for a nice
compromise between 1 and 4.

-- 
Saikat
Attachment:
signature.asc

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 13 Dec 2005 20:36:32 -0800 (PST)

I would prefer a solution that was possible to deploy without using NAPTR
(note, I'm ok if NAPTR is MUST implement just have problems with MUST
deploy). NAPTR is still difficult to deploy in many situations.

If you do a STARTTLS start TLS on a connection, you can not stop it so all
the data traffic after that would have to be TLS encrypted. This is probably
not a good thing. 

I think the combination of the above two makes me lean towards #1.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Dec 2005 09:49:13 -0800 (PST)

Cullen Jennings wrote:

I think the combination of the above two makes me lean towards #1.
My concern is that it would simply not be allowed, i.e., IESG would not 
permit it.

My proposal was somewhat of a hybrid. The idea is, we already have 
default ports for STUN UDP/TCP. Those could be used, and it would be the 
case that there is no TLS on those ports. If a client wants to do 
something that requires TLS however, be it shared secret or 
allocate-over-tls, the client would need to use NAPTR to find the TLS 
port. So, if the client never does TLS stuff, it would never need NAPTR.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Dec 2005 09:52:23 -0800 (PST)

inline.

Saikat Guha wrote:

ICE endpoints, no, since the ICE usages don't require any STUN or TURN 
over TLS.

It would reqiure TURN servers to advertise their ports through DNS. I 
doubt this would be through DDNS updates, since the ports are not 
generally dynamic, they're just not standardized. Thus, you'd typically 
configure the turn server to run on a specific port, and then configure 
that port into the DNS, and then leave it alone from there on.

Given how hard it is to convince my IT department to add just a CNAME,
#2 would be at the bottom of my preference list. #3 makes for a nice
compromise between 1 and 4.
I'm not a fan of START-TLS types of mechanisms since they are 
complicated. I would much prefer the hybrid model I proposed, which 
would only require NAPTR specifically for TLS cases.

-Jonathan R.