[tor-dev] Setting NumEntryGuards=2

[David Goulet]

On 22 Mar (17:13:40), Mike Perry wrote:
> 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.

Hmm, that is a very good point. I haven't thought in terms of the forcing
a new connection vs shoving traffic in an existing connection.

David

-- 
hgJe5VGAkZPnC/W4iPXnCuf1HcG2evYQqVjeb8Ugb4Y=
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20180322/2f322f38/attachment.sig>