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

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Mar 2007 22:24:49 -0400

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.

-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

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 27 Mar 2007 10:43:35 +0300

Inline.

> won't let you interleave data like this

Is there a need to keep using STUN even after the connection has been 
authenticated, and TLS can be started?

If not, it will actually be easier for TLS stacks to handle... pretty much all 
TLS stacks support sending plain-text data before the TLS handshake (if only 
to support HTTP CONNECT and SMTP/POP/IMAP STARTTLS). Also most (all?) TLS 
stacks support using custom underlying I/O (instead of plain sockets).

A third option is to do STUN then continue with STUN over TLS, perhaps.

> framing attacks whereby a MITM modifies the STUN lengths to disrupt

I am not a security expert, and I think I do not understand what the problem 
is. I would assume an active MITM can always disrupt the communication 
anyway.

> TLS then STUN

See above.

> + protects STUN messages

Is there any case for confidentiality of the STUN messages (I assume they are 
authenticated regardless of TLS usage)? Doesn't STUN then DTLS not have it as 
well?

> can you perhaps reuse the TLS session?

I am not a TLS expert, but I think the resuming the session requires killing 
any other connection using that session. I doubt this works, but I do not 
really know.

> current draft), mostly because I don't think the alternative will be

That's unclear to me. I very much agree that implementation complexity is the 
decisive factor (as both approach logically work on the paper) though.

Regards,

-- 
Rémi Denis-Courmont

---

From: EKR <[email-masked]>
Date: Tue, 27 Mar 2007 06:02:29 -0700

> STUN then TLS

Let's examine this question a bit. There are two things you have to do
to make this work:

 1. Insert a shim layer in between the TLS stack and the network to
    bypass the STUN. Most stacks I'm familiar with allow this. I 
    know OpenSSL does, as does PureTLS.
 2. Demux TLS and STUN. This is relatively easy (see the description
    in draft-mcgrew-tls-srtp).

So, I'm not sure this is that hard to do.

> framing attacks whereby a MITM modifies the STUN lengths to disrupt

Not sure I understand this issue. It's of course trivial to DoS a 
TLS over TCP connection by disrupting its frame sync...

> TLS then STUN

Probably, though there are race conditions (again, discussed in
draft-mcgrew-tls-srtp).

-Ekr

---

From: "Eric Cooper" <[email-masked]>
Date: Tue, 27 Mar 2007 09:24:59 -0400

> current draft), mostly because I don't think the alternative will be 

Would STUN then TLS complete faster?  On low-CPU-power devices, TLS handshakes can take a non-trivial amount of time to complete.  

I suppose this mostly matters when multiple working paths exist (two devices on the same LAN behind a hair-pinning NAT, for example), but it would be nice to perform the TLS handshake only once.

Eric.

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 27 Mar 2007 09:57:32 -0400

> then STUN checks, then TLS handshake?

The other possibility is "both".  I.e., the initial connectivity checks are
done outside of TLS.  Once a connection is selected, a TLS handshake is
performed on it; subsequent STUN keepalives are done over the TLS channel.

Presumably this would use a STUN StartTLS method.  This could also help
resolve the "who sends ClientHello" issue for simultaneous-open.

-- 
Jonathan Lennox
[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 29 Mar 2007 09:35:17 -0400

inline.

> authenticated, and TLS can be started?

Yes, I forgot to mention this, its important.

With UDP at least, Binding Indications are used for keepalives. They 
don't get sent if there is active traffic (RTP packets). So, for TCP, we 
would either need to:

1. send STUN binding indications as keepalives, inside the TCP 
connection but outside of TLS, requiring demux after the handhsake has 
completed,

OR

2. for TCP, mandate that something else besides STUN is used for 
keepalives, and in particular, it is whatever the application protocol 
is using,

OR

3. use STUN keepalives within the TLS connection anyway, even if they 
were sent outside of the TLS connection at the time of initial handshake

Also to make things even more complicated, for TCP we are using a shim 
framing protocol ontop of the TCP connection (the one used for RTP 
framing over connection oriented transports), which allows demux of the 
STUN and TCP application data. So would that shim be above or underneath 
TLS? Gack this is all making my head hurt...

> is. I would assume an active MITM can always disrupt the communication 

Yeah, ekr pointed out this attack exists in normal TLS, so maybe its a 
non-issue.

> authenticated regardless of TLS usage)? Doesn't STUN then DTLS not have it as 

Well, more security can't hurt :)

But yes there is some protection in the ICE mechanism itself.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 29 Mar 2007 09:37:43 -0400

Eric Cooper wrote:

>>  current draft), mostly because I don't think the alternative will
>> be easily implementable.
> 
> 
> Would STUN then TLS complete faster?  On low-CPU-power devices, TLS
> handshakes can take a non-trivial amount of time to complete.

Yes, STUN then TLS would be faster. This is because you'd end up 
selecting a single pair with ICE *first* and then run TLS only over the 
selected pair.

If you do TLS then STUN, you need to do a TLS handshake for each TCP 
connection that works, and with ICE there could be more than one. Of 
course once one succeeds, ICE may terminate, though this depends on the 
selection algorithm that is running. ALso you may certainly have several 
handshakes in progress before the first is even done, so even if you 
pick the first one to complete you may be partway through several 
handshakes.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 29 Mar 2007 09:40:27 -0400

inline.

> So, I'm not sure this is that hard to do.

Well, one idea on the demux is if we are using the contrans framing, the 
TLS runs ONTOP of the framing so the demux is trivial.

One thing I wasnt sure of is whether the stacks allow these shimes to 
exist only prior to the handshake completing or through the entire 
duration of the tls connection?

> TLS over TCP connection by disrupting its frame sync...

A concern was raised on the behave list that an attacker could modify 
the length attribute of stun messages, and disrupt framing on the tcp 
connection and consequently trash the connection. I guess your point is 
that this is possible with regular TCP/TLS too....

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 29 Mar 2007 09:41:16 -0400

> resolve the "who sends ClientHello" issue for simultaneous-open.

There is no STUN StartTLS method. ANyway I don't see what this has to do 
with the 'who sends ClientHello' problem...

-Jonathan R.

---

From: EKR <[email-masked]>
Date: Thu, 29 Mar 2007 07:25:41 -0700

Jonathan Rosenberg <[email-masked]> writes:
> Well, one idea on the demux is if we are using the contrans framing,
> the TLS runs ONTOP of the framing so the demux is trivial.

Right. 

> duration of the tls connection?

At least with OpenSSL, all the time. If people want, I could do a survey
of the relevant stacks and see what they do. It won't be this week or
next, though...

> connection and consequently trash the connection. I guess your point
> is that this is possible with regular TCP/TLS too....

Yeah, basically if you can inject stuff into TCP, the game is over
with any TCP-based protocol.

-Ekr

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 29 Mar 2007 10:38:03 -0400

> There is no STUN StartTLS method.

There isn't currently, no; my suggestion is to add one.

In more detail, the process would look like:

* Establish a TCP connection using ICE procedures, and send connectivity
  checks on it.

* Following a successful check, send a StartTLS request on the connection.

* Once that succeeds, send ClientHello and do the TLS handshake.

* Send a request with a STUN USE-CANDIDATE nomination over the established
  TLS connection.

This is probably too many round trips; it could probably be made more
aggressive by combining some of the requests.  But this guarantees that you
don't have to do the TLS handshake until you've selected the connection,
while still allowing the controlling ICE endpoint the flexibility of
choosing a different connection if the TLS handshake fails for some reason.

> ANyway I don't see what this has to do 

If an endpoint which thinks it should be the one to send the ClientHello
receives a StartTLS request, it can respond with an error response, then
send its own StartTLS request in the other direction.  I'm working on the
same principle as your ICE-CONTROLLING/ICE-CONTROLLED logic: if the
endpoints disagree about their roles in a negotiation, it's better to
discover this dynamically and recover from it.

-- 
Jonathan Lennox
[email-masked]

---

From: "Eric Cooper" <[email-masked]>
Date: Thu, 29 Mar 2007 11:01:19 -0400

> selecting a single pair with ICE *first* and then run TLS only over the 

I think faster is better for ICE (assuming it's possible to add the shim).

Eric.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 30 Mar 2007 16:56:51 +0300

> > the TLS runs ONTOP of the framing so the demux is trivial.

My memory might be failing, but I thought RTP/TCP framing only adds a bytes 
length word. That is sufficient to differenciate RTP from STUN, sure... but 
does it work for TLS vs STUN at all?

> of the relevant stacks and see what they do. It won't be this week or

At least, OpenSSL, GnuTLS and DotNet System.Net.Security.SslStream. Not very 
confident about the other ones. And in any case, this requires a bunch of 
extra custom code because they all assume a socket handle by default, so you 
end up writing new I/O callbacks and re-assembling buffers. I am not very 
fond of that idea.

I would rather go for STUN then TLS then (proto-specific keep-alives OR 
STUNoTLS). As far as I can tell, it would be faster and slightly less 
disruptive to application developpers.

Regards,

-- 
Rémi Denis-Courmont

---

From: Adam Roach <[email-masked]>
Date: Sat, 31 Mar 2007 18:24:38 -0500

Given EKR and Rémi's analysis of the situation, it sounds to me like we 
get to choose between making implementors work harder and making CPUs 
work harder.

I would argue that the key to a successful protocol is a low 
implementation complexity. Even for low-end mobile devices, CPUs are 
relatively fast (133 MHz is the low-low-low end nowadays) and getting 
faster all the time -- so the extra TLS handshakes, while a waste of CPU 
time, are going to be rather insignificant in the grand scheme of 
things. (As to battery life: consider that these wasted cycles will 
typically occur only at the start of a session, so there should be 
negligible impact on total power used).

Finally, given that ICE-TCP is being considered for applications other 
than TCP (cf. Aki's ICE-MSRP draft), I'd want to stay away from any 
solution that assumes the use of RTP TCP framing.

/a