tinc - Dec 2005 - tinc and TLS

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.

On Fri, Dec 09, 2005 at 08:52:30PM +0000, Brian Candler wrote:
> 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?
The reason is that tinc development started a long time ago, when SSL
was not yet an obvious choice. Moreover, tinc works in a peer-to-peer
like fashion, while SSL makes a distinction between a server and a
client. Today that is no longer an issue (with client certificates).
There is a branch of tinc
(http://www.tinc-vpn.org/svn/tinc/branches/1.0-gnutls/) that uses the
GNUTLS library, but also really sets up TLS connections.
> 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]
That's right. With GNUTLS you also have the option of using PGP keys or
doing password authentication instead of just X.509 certificates.
> 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)
I'll have a look at that, that's indeed what is needed for the UDP
channel.
> 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.
All true. Except that this does not work for UDP packets, unless DTLS
becomes available or you do something like OpenVPN (reimplementing a
kind of TCP on top of UDP just to support SSL/TLS).
> 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?
True.

If you can code, I would welcome any contribution!

-- 
Met vriendelijke groet / with kind regards,
    Guus Sliepen <guus@sliepen.eu.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://brouwer.uvt.nl/pipermail/tinc/attachments/20051210/3216eb3a/attachment.pgp