Subject: Re: [MMUSIC] ICE-tcp: TLS then STUN or STUN then TLS

From: Philip Matthews <[email-masked]>
Date: Wed, 4 Apr 2007 16:38:43 -0400

On 26-Mar-07, at 22:24 , Jonathan Rosenberg wrote:

> During the Prague IETF, an issue was raised with ICE-tcp that we  
> didn't resolve.
>
> The question is, if you are using TLS with ICE, do you perform the  
> TCP setup, then TLS handshake, and then STUN checks or do the TCP  
> setup, then STUN checks, then TLS handshake?
>
> There are some pros/cons that were discussed:
>
> STUN then TLS
> -------------
>
> + avoids doing TLS handshakes except on connections that are  
> selected by ICE
> + consistent with how we are doing DTLS where the STUN is clearly  
> not protected by SRTP and would happen prior to the DTLS handshaking
> - Likely to be really hard to implement since most TLS stacks  
> probably won't let you interleave data like this
> - will lose the TLS protection on STUN itself, introducing possible  
> framing attacks whereby a MITM modifies the STUN lengths to disrupt  
> frame sync
>
> TLS then STUN
> -------------
>
> + easier to implement
> + protects STUN messages
> - will do TLS handshake even for candidates that are not selected;  
> but can you perhaps reuse the TLS session?
> - different from how UDP works
>
>
> I'm inclined towards TLS then STUN (which is the assumption in the  
> current draft), mostly because I don't think the alternative will  
> be easily implementable.

I don't know a lot about TLS, so please correct me if I am wrong, but  
it seems to be that TLS is best viewed as a layer that runs on top of  
TCP. For that reason, it seems to me to be best to do STUN outside of  
TLS (in other words, "STUN then TLS"). Doing the reverse seems to me  
to be a mixing of layers that will come back to hurt us later.

However, if I am wrong, then it seems to me that we should consider  
TLS/TCP to be the transport protocol, in other words we need to talk  
about ICE-TLS as distinct from ICE-TCP.

One other question: If someone was to invent a different type of  
security layer on top of TCP, would you recommend that STUN run  
inside that layer as well?

- Philip

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 5 Apr 2007 10:16:20 +0300

On Wednesday 04 April 2007 23:38:43 ext Philip Matthews wrote:
> TCP.

TLS runs on top of a reliable, ordered, bytes stream. This is typically TCP, 
but can be something else (I see no reason why TLS would not work on top of 
SCTP or even IPX/SPX ;-) ).

It definitely can theoretically run on top of STUN/TCP. The issue is whether 
this is practical or not: Most TLS stacks are biased toward using a BSD 
socket or equivalent, and it is either intricate, or maybe impossible with 
some stacks, to use something else (without rewriting the stack).

> inside that layer as well?

I think nobody wants to reinvent TLS here :)

-- 
Rémi Denis-Courmont

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Apr 2007 09:42:11 -0400

So far, we're nicely split on this issue in list discussions. More inline:

Philip Matthews wrote:

>> current draft), mostly because I don't think the alternative will  be 
>> easily implementable.
> 
> 
> 
> TLS (in other words, "STUN then TLS"). Doing the reverse seems to me  to 
> be a mixing of layers that will come back to hurt us later.
> 
> security layer on top of TCP, would you recommend that STUN run  inside 
> that layer as well?

To answer a different question, with UDP, we are assuming that DTLS and 
STUN are 'peers' so that STUN is run outside of DTLS (not protected by 
it), and that the stun checks happen prior to the DTLS handshakes.

One argument in favor of "STUN then TLS" for TCP is to make the UDP and 
TCP designs equivalent.

-Jonathan R.

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

---

From: Philip Matthews <[email-masked]>
Date: Thu, 5 Apr 2007 09:59:30 -0400

> SCTP or even IPX/SPX ;-) ).

Is a TLS session bound to a pair of transport addresses, or can it be  
moved
from one pair to another? That is, if I have an connection up on one  
valid candidate pair,
and later want to move it to another valid candidate pair, do I have  
to start a new TLS
session, or is there someway to move the existing session to the new  
candidate pair?

If a TLS session can be moved from one pair to another, then I think  
this is an argument
for doing STUN outside of TLS.

If it cannot, then things are not as clear-cut.

Also, what is the right way to do DTLS over UDP? Should we run STUN  
inside or outside
the DTLS session? It seems to be that we should have a consistent  
decision here.

- Philip

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 05 Apr 2007 09:22:07 -0700

At Thu, 5 Apr 2007 09:59:30 -0400,
> session, or is there someway to move the existing session to the new  

Well, TLS doesn't know one way or another. It just assumes it has
a reliable bytestream. But What you're suggesting pretty seriously
violated TLS metaphor, so I would advise against it.

> the DTLS session? It seems to be that we should have a consistent  

I think the right thing is the current thing: to demux DTLS versus STUN.
I.e. run them in parallel.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 05 Apr 2007 09:23:21 -0700

At Thu, 5 Apr 2007 10:16:20 +0300,
> SCTP or even IPX/SPX ;-) ).

In fact it's already been bound to SCTP.

> some stacks, to use something else (without rewriting the stack).

Hmm... As far as I know, most stacks have pluggable IO abstractions.
Certainly OpenSSL does and the Java stacks I know of are built on
Socket which can be subclassed...

-Ekr