TLS for the link handshakes/encryption

[Roger Dingledine <arma@mit.edu>]

On Sat, Aug 30, 2003 at 01:05:53PM -0400, Joel N. Weber II wrote:
>    I'd actually like to solve link key rotation at the same time as I update
>    the handshake protocol. It would be nice if establishing the first key
>    is pretty much the same operation as rotating the key, so we can keep
>    the design simple. More design work remains. Feel free. :)
> 
> I don't know offhand if TLS does this, but sshv2 certainly takes care
> of all of this.

I think we should definitely look into tls for the OR link-level
encryption/auth. Stunnel looks like it has some not-too-crazy code we
could use (albeit gpl).

On the other hand, doing all the ssl hoops looks like about as much (or
more!) code as just doing the handshakes ourselves (that is, calling
each step of the openssl library). I think much of the ssl calling
overhead is for sessions, etc, which I don't think we need to worry
about. Nick: you've got some experience with ssl/tls from minion --
what's your impression here? Also, are there tls libs that play well
with asynchronous systems, or do they demand a separate thread/process?

Which brings me to my next realization: we've been planning to split
out a couple of cpu worker processes (threads on windows) to do the
heavy crypto lifting, eg public key decryption. Rather than keeping our
crazy asynchronous logic in connection_or.c, why not simply hand the
newly accepted socket to a worker, and after a while he informs you
that it's now in the 'open' state? (And he hands back the necessary
crypto material.)

Whether we use fullblown TLS or just the subset of it that we need,
this is something worth considering.

--Roger