David Goulet: > On 22 Mar (13:46:36), George Kadianakis wrote: > > Mike Perry <mikeperry@xxxxxxxxxxxxxx> writes: > > > > > Arguments in favor of switching to two entry guards: > > > > > > 1. 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. 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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev