Mike Perry:
David Goulet:
On 22 Mar (13:46:36), George Kadianakis wrote:
Mike Perry mikeperry@torproject.org writes:
Arguments in favor of switching to two entry guards:
- One guard allows course-grained netflow confirmation attacks
The counterargument based on #14917 above also has an additional wrinkle: an adversary watching a suspect list of clients can easily observe the "temporarily use a second guard" activity using just connection-level ISP/AS netflow logs. To a large-scale netflow adversary, the use of a second guard only when the guard is chosen as the RP confirms not only guard choice, but the IP address of the onion service itself.
Devil's advocate: I'm not sure how big the suspect list we are thinking about is, or what kind of threat models we are considering here, and I think this matters quite a bit. Because if the suspect list is not big, and the threat models allows the attacker to cause the victim to build circuits, then the attacker could succeed even with simple traffic signals (or shutting down the internet) and traffic monitoring.
Also, this whole point relies on our suboptimal fix to #14917. We could improve the situation here by doing more advanced fix like the one suggested above.
Agree with George here. I think 1 or 2 Guards here won't matter much in this attack as mentionned where Alice can just keep injecting traffic pattern on both Guards for identification at the netflow records level.
I strongly disagree. Dumping more traffic onto an already existing, otherwise in-use connection is not the same as the ability to force a new connection that is only used for a single request at a very specific time. These are completely different data retention resolutions, and if the netflow padding works as intended, dumping traffic onto an existing connection will be rolled up into all other traffic during that hour, or longer. At large scale, routers will likely be recording flows at just the connection level only, if that.
Minor correction: I misremembered the default active flow timeout for most routers. It is actually 30 minutes, not one hour. (See Section 2.1 of https://gitweb.torproject.org/torspec.git/tree/padding-spec.txt and associated manual links).
Also note that this active timeout value is the highest possible resolution of data retention *at the router*. Netflow logging systems also involve a "collector" machine that takes router records and aggregates them further for long term storage (this is also described in Section 2.1 of that spec).
What this means in practice is the ability for an adversary to go to large ISPs and say "Hey, give me connection logs you already have/can easily generate for these IPs during this specific time period" instead of "Hey, install this custom black box monitoring equipment for me and let me get arbitrary reports from it whenever I want". I know ISPs that have received and refused the black box request case because it was too intrusive. I also know ISPs that have given records over in the connection-level case.
I will reply to the discussion of other options for the #14917 fix in the other branch of this thread.
-- Mike Perry