Padding, multiplexing and more

[Marc Rennhard]

> > The main concern here is about linkability, and I fully agree. Why
> > not use a compromize: As long as I'm on www.cnn.com, I can happily
> > use the same connection with a second level of multiplexing. Yes,
> > the adversary learns (a bit) more thant with a new onion per
> > connection, but only if we assume he can observe the last OR and 
> > not the web server. In the latter case, using new connections (and
> > new exit ORs) for each web object won't help much as users usually
> > navigate using links and the adversary should be able to link all
> > objects to the same user by analyzing which page at cnn.com links to
> > what other pages. So the compromize is to use a connection as long we
> > are in the same domain, but build a new onion and use a new connection
> > (with a new exit OR) when we move to another domain. Comments?
> 
> Hm. I like it. But there are all sorts of little complexities that
> creep in.
> 
> For example, right now the client closes connections that have been
> idle for 5 minutes and have no circuits on them. Since most people use
> short-term circuits (eg for web browsing, rather than an all-night ssh
> session), we close the connection a little while after the last circuit
> closes, so the ORs don't get overloaded with idle sockets. (If they've
> been idle for 5 minutes but still have a circuit in use, then we send a
> padding cell. Otherwise a firewall may expire their connection and the
> client will never know --- and then future cells on that connection will
> simply disappear.)
> 
> But now all circuits will be long-term rather than short-term circuits,
> since we can't predict when the user will want to talk to cnn.com
> again. We could time out the circuit after 30 minutes of inactivity
> (either judged because nothing has gone through that circuit in 30
> minutes, or because the user has made no requests of any kind in 30

There is no requirement to keep the circuits for more than 5 minutes. If
a new requets is sent to cnn.com, then I can always produce a new onion;
it doesn't matter if I have been there 6 minutes ago.

> minutes). I'm worried that that really won't save us so much -- a user
> pulling up a website that draws from lots of different places still
> uses lots of onions. 

True. But it still should reduce the number of onoins by several factors.
And very many pages (without ads) pick everything from their own domain,
so that would be just one onion. And even those complex pages ususlly 
don't access more that 4 or 5 different domains for 50 or so objects.

> Further, what about sites like doubleclick? Their
> job is to correlate your movement across various domains. If you have
> separate onions for a variety of sites but each of them causes you to
> talk to doubleclick when you use them... are you allowing doubleclick
> (or somebody observing doubleclick) to correlate which exit nodes are you?

Now that is true. But do we care if doubleclick has no clue who we are?
I mean, what does it help doubleklick to learn a trace cnn.com - amazon.com -
bla.net... if they cannot correlate that to a user? They may even see that 
very same (or similar) trace later again and conclude 'whoops, there's the
same guy again', but still, why should I care? Well maybe I should if 
doubleclick has an 'out-of-band' channel to link those events to me...

> If this doubleclick attack does work, does it not matter because our
> users will all be using privoxy and it blocks sites like that?

Privoxy definitely helps OR a lot. Not only by preventing the doubleclick
attack, but also to releive the ORs from all that spam. We can maybe assume
that anyone as paranoid to use OR is probably using privoxy... One could
also integrate a filter in the application proxy to look for keywords like 
'ads' or 'doubleklick' and then make sure that a fresh onion is built. It
should also be kept in mind that privoxy would help us a lot if non-
encrypted channels are used. But as soon as users switch to https, any
filtering won't work. Here again, we could use to 'one onion per 
connection' as soon as the user switches to https to avoid the double-
click attack. 

> And while I'm at it, here's a counter-compromise which might help draw out
> the issues: rather than one circuit per site, how about one circuit per
> 5 minutes? You use that circuit for all new connections in that period,
> but once it's over when you want a new connection you make a new circuit
> (which again is used for at most 5 minutes). There are also profiling
> opportunities here, but they seem different.

It makes the linkability-window smaller, true, but does not fundamentally
solve the issue. Why not use the 'one onion per domain for 5 minutes at
most'? It's more onions than the 5-minutes-slots approach, but less than the
one-onion-per-connection method. Maybe we should Analyze how much onions
would be used with which approack for some popular sites.

--Marc