tinc and TLS

[Brian Candler]

Hello,

Sorry if this is a frequently-asked question - but I didn't find the answer
on the tinc frequently-asked questions page :-)

OK, the question is:

* Given that tinc uses TCP for its metadata channel, and that tinc also
  uses the OpenSSL library, why doesn't tinc just open a TLS connection for
  its metadata channel?

I'm sure there must be a good reason, but I can't think what it is. I can
see some advantages in using TLS though:

1. You could use certificates to authenticate each side - or just continue
to check the public key, as is done now. At least you'd have the choice. [1]

2. You can derive a shared session key as a side-effect. (I think this is
how WPA EAP-TLS works - hmm, RFC 2716 section 3.5)

3. If the connection is broken and remade, you can restart it quickly by
giving the same session ID as before, as long as the daemon maintains a
session cache.

4. The code might end up being simpler (just calling the OpenSSL library).
Or it might not. I haven't looked into it yet :-)

5. TLS and OpenSSL have both been subjected to widespread scrutiny.

Even though the initial setup of a TLS connection might have a higher
overhead than tinc's TCP protocol, once it's established I don't expect it's
much higher, and in any case isn't the volume of metadata exchanged
relatively low?

Just a thought anyway...

Regards,

Brian.

[1] The 'fetchmail' source code may be a useful reference here. It shows how
to compare just the fingerprint of the far-end's public key using the
--sslfingerprint option, or to perform full certificate validation.