Re: TLS for the link handshakes/encryption

[Nick Mathewson <nickm@alum.mit.edu>]

On Tue, 2003-09-02 at 01:51, Roger Dingledine wrote:
 [...]
> 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).

Or we can write it ourselves.  We're already using OpenSSL, after all. 
It's not so hard to do.

> 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 don't believe this is so.  There are a few magic words you need to
say, but those magic words are easily abstracted and not very hard to
do, so long as you don't take X.509 too seriously.

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

I'd say go for it, for the link encryption.  TLS isn't hard to use, and
would give us a lot of what we want.

>  Also, are there tls libs that play well
> with asynchronous systems, or do they demand a separate thread/process?

AFAIK, they *all* do fine with asynchronous systems.  The three that I
know of are OpenSSL, GnuTLS, and NSS.  I don't know much about the state
of GnuTLS.  NSS is not an option until it supports the server side of
Diffie-Hellman key agreement.

> 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.)

You can't pass sockets across processes.  If we want to do that, we'll
need to become multithreaded even on Unix.  Not impossible, but a little
dodgy considering the state of pthreads implementations on all the weird
hardware we may need to consider.

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

IMO we need most of TLS, and we're better off using it than handrolling
a subset.  On links, we want two-way authentication with ephemeral keys,
link encryption, data integrity, and occasional key rotation.  The parts
of TLS we wouldn't necessarily need are ciphersuite negotiation,
sessions, support for octet-streams (since we only want cell-streams),
and all the weird corners of X.509.

-- 
Nick