Sharif Olorin:
Mike,
Additionally, I should clarify that bro and netflow have some fundamental differences and are usually used for different things (but both are common in large networks). Bro's very stateful and is more focused on IDS-type applications, whereas netflow is more directed towards traffic accounting, which is why bro has all the stateful stuff about TCP connections. bro would be more commonly found at a university, but netflow's probably more relevant if you're looking at what the typical ISP will retain for a long time.
Yes, unfortunately this is why "just set up bro/netflow at home and try it!" is not really helpful. It is obvious that these systems can in theory be configured to log+analyze all data for all time, especially if it is just my tiny DSL line with one person browsing the web over Tor and I have a few TB worth of disk to burn.
However, speculation about the evil BOFH who twiddles his mustache and tunes netflow to deanonymize all Tor users forever is rather boring to me. It's a scenario that's unlikely to happen at scale, or be practical for full analysis of the entire Tor network. Even if we are looking at such a BOFH in the Utah case, we have yet another datapoint against the evil BOFH correlation theory: These logs were useless!
The important question to me is: "If we assume honest Tor nodes, what level of logging is likely to be practiced at their ISP or AS today without their knowledge, and what technical measures are available to us to reduce that potential impact?"
In this Utah exit case, the exit operator in question is indeed honest, and we're looking at an upstream admin who just happened to be logging stuff, likely as per some standard (if heavy-handed) connection-level logging policy.
I suspect that type of adversary will be possible to defeat with similar amounts of padding that will defeat hidden service circuit setup fingerprinting, website traffic fingerprinting, traffic type classification, and a host of other low-resource attacks...