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

Jonathan Rosenberg <jdrosen@cisco.com> wrote:
> 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

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.

> - will lose the TLS protection on STUN itself, introducing possible
> framing attacks whereby a MITM modifies the STUN lengths to disrupt
> frame sync

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
> -------------
> 
> + 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?

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

-Ekr

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic