[tor-dev] Setting NumEntryGuards=2

[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.

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
-------------- 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/20180322/37208fd3/attachment.sig>