Mike Perry: > 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. 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 -- 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