Re: Using TLS for circuit-level handshake (Was Re: tor-spec comments)

[Roger Dingledine <arma@mit.edu>]

Thanks for your experience reports here, Marc. Hopefully one day we'll
be at that stage too. :)

On Mon, Sep 15, 2003 at 11:35:20AM +0200, Marc Rennhard wrote:
> on the rate of circuit-establishment, of course. If tor ever moves to
> some cover traffic scheme, I believe doing the handshake and other
> expensive operation in dedicated threads is absolutely mandatory.

This is a good point. Right now we pass onionskin processing on to a
separate process, so we're partway there. But even if we continue to use
TLS handshakes in the main process just for link-level, there are still
vulnerabilities: eg, I can hammer some node in the network and see if
(cover) traffic slows down for the circuit in question. But I can hammer
him in other ways, such as more data cells, or just a bunch of large
pings. So I'd agree that for now it's not the easiest attack.

> view, I would stick with the minimum number of threads that is needed.
> As long as no cover traffic is employed (see above) and looking at the 
> main design of tor, you should use exactly one process/thread.

We need a few extra processes because there's no good portable way to do
async dns resolves. But yes, other than that and the onionskin cpuworker
processes (one per cpu), we're single process. :)

> 4. Cell growth. This is a pain as adding a layer of TLS adds 21 bytes
[snip]
> of about 10. But this again wastes bytes.

Yep.

> This multiple round-trips (3 in the case of TLS per OR) is probably a
> small problem. Right now, tor is vulnerable to many sophisticated
> attacks that this additional leackage of information is probably
> minimal. Again, if tor ever uses clever cover traffic mechanisms, then
> this multiple round-trips should be hidden from the observer, otherwise
> the cover traffic scheme is of not much use.

Right. Tor is currently vulnerable to many sophisticated and
not-so-sophisticated attacks. Part of what we want to do once we've
got the network up and running (which was going to happen a year ago,
but you know how these things go) is look at ways to strengthen the
anonymity without shedding all our users.

Ideally I'd like to move to a synchronous network where cells go through
in batches and are held for a while at each hop, to get at least a bit
of mixing into the picture. So the fewer anonymity leaks we build into
the protocol that prevent us from moving to that model, the better off
we are long-term.

Said a different way, just because there are 5 attacks that work now
doesn't mean we should introduce the 6th, if we can reasonably avoid
it. :)

> Summarising, I cannot give a clear pro/contra using TLS instead of a 
> lighter protocol. Its more overhead and has many features tor does
> not need, but it's also (probably) secure and contains *all* features
> you need.

One flaw with TLS is implementation-dependent behavior. I imagine the
openssl, gnutls, etc implementations of TLS don't behave identically
at the byte level. If a router can recognize which client software is
handshaking with him, that's yet another anonymity vulnerability.

Thanks,
--Roger