[tor-dev] Setting NumEntryGuards=2

[Mike Perry]

Mike Perry:
> David Goulet:
> > On 22 Mar (13:46:36), George Kadianakis wrote:
> > > Mike Perry <mikeperry at torproject.org> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20180326/0eb718aa/attachment.sig>