On 2018-03-26 20:34, Mike Perry wrote:

Florentin Rochet:

On 2018-03-20 04:57, Mike Perry wrote:

<skip>
Arguments for staying with just one guard:

1. One guard means less observability.

As Roger put it in the above blog post: "I think the analysis of the
network-level adversary in Aaron's paper is the strongest argument for
restricting the variety of Internet paths that traffic takes between the
Tor client and the Tor network."
http://freehaven.net/anonbib/#ccs2013-usersrouted


        

          
Furthermore, I believe that conflux will also be useful against traffic
analysis and congestion attacks. Since the load balancing is dynamic and
hard to predict by an external observer, traffic correlation and website
traffic fingerprinting attacks will become harder, because the adversary
can no longer be sure what percentage of the traffic they have seen
(depending on their position and other potential concurrent activity).
Similarly, it should also help dampen congestion attacks, since traffic
will automatically shift away from a congested guard.


        

        
I am really enthusiast about multipath, either at the Tor level or even at
the transport level: we discussed QUIC at the meeting, but MultipathQUIC
could also be a long-term option now that we discuss more than 1 entry
guard.

However, I would argue that it does not really help against traffic
correlation. Our paper at pets18 exploits Tor's forward compatibility
feature to design silent cheap, almost instantaneous and perfect active
traffic confirmation that does not care about user traffic to succeed.

See Section 5,
https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf


      

      
In this case, Tor's forward compatibility is a bug. The Tor protocol is
now versioned at the feature layer, so Postel-style permissive forward
compatibility is no longer required:
https://gitweb.torproject.org/torspec.git/tree/proposals/264-subprotocol-versions.txt

I have been bothered by the types of side channels you discuss in that
paper for some time. They are tricky to remove, but not impossible.
See https://trac.torproject.org/projects/tor/ticket/25574 and the child
ticket and associated branch.


    

    

    Great! Roger indeed told me you were exploring similar problems. As
    you said, it's tricky to remove because of false positives and
    because you loose protocol flexibility, and it is not clear to me
    what the consequences can be over the years. I think we can reason
    about this as a scalability problem, not in size, but in *time* with
    its underlying technical issues and security concerns depending on
    how much we scale the protocol flexibility. 

    

    It is not really this thread's topic, so I prefer not to talk too
    much here, but I would be glad to discuss more those problems or to
    help on any proposal design, and code. Just ping me on IRC :)
    (Jaym).

    

    

      
Your paper also states that you got multiplier effects from various
issues with Tor's protocol, which improved your results. If we remove
these multiplier effects by fixing the protocol and behavior, then it
seems to me that adaptive traffic routing will add further uncertainty
to congestion-based attacks.


    

    

    Hard to tell, even if the intuition is on your side. It's probably
    possible to come up with something smarter than the various attacks
    I did. We will definitely need another round of analysis after any
    proposed change.

    

    While I feel that the various 'multiplier effects' should be
    removed, I don't really like the approach "patch the weaknesses
    quick and move on", often we miss to understand the root cause of
    the various problems, and we end up to add complexity to the
    software while there might be something better to do.

    

    

      

      

        
Maybe the real debate would be to discuss what's the major threat between
active/passive attackers, and what do we care about? The question is, why
should we care about hardening passive attacker's work when the active form
is always as easy?


      

      
To your point: because I believe it is possible to make both active and
passive attacker's jobs hard. I also believe that when we look deeply
enough, we will find that improvements that make an active attacker's
task harder will also improve things against many, if not all, classes of
passive attacker. 

Roger made a related point that I want to inject here, so I remember to
pick it up in the proposal: Roger said that we should consider active vs
passive observers here. He contended that against passive observers, one
guard is always better, and that we should not discount that benefit
while considering an active attacker making circuits via a second guard.

However, there are two main issues with calling the
Tor-sometimes-uses-a-second-guard "attack" fully "active":

1. It is not always active. In day-to-day operation, clients will use a
second guard whenever they pick an exit that is in the same family or
/16 of their primary guard (this is because Tor rightly chooses exits
first, to avoid leaking guard node choice via exit node choice). Clients
will also do this when an onion service's IP, HSDIR, or RP is in the
same /16 or family as their primary guard, or actually is that guard. In
these cases, they will perform a request over a second guard, with no
benefit from multiplexing it with other traffic. For clients unlucky
enough to choose guards in popular /16s or in big families, they will be
using secondary guards for unmultiplexed activity quite frequently.

2. The active observer and the passive observers here are independent
actors. The passive observers can be logging connection activity simply
due to the default configuration of their network routers. Active
adversaries do not need their collusion in this attack to get the full
benefit from being active -- they merely need to have the ability to ask
passive observers for the logs they already have, independent of the
attack.


    

    

    Also, I believe that there is a common misconception about the
    strength of a passive adversary against the Tor network. The passive
    adversary needs to see a sufficient amount of data to keep false
    positives quite low, and to have a reasonable chance of success,
    while the active form does not really care about such constraints
    (depending on the kind of confirmation attack, though). From my
    observations, most of Tor's traffic is short and unlikely to deliver
    enough information to a passive observer. Can a passive attacker
    correlates efficiently on the real network while most of Tor's flow
    size is below ~ 2000 cells? So, I don't feel that slightly
    increasing the surface area of passive adversaries is problematic
    right now, and as you said, the multiplexing effect of multipath may
    make their job even harder. I am more concerned by the increasing
    surface area of active attackers, and you seem to argue that the
    current situation "Tor-sometimes-uses-a-second-guard" is not fully
    active? So, moving to two guards favors active attackers compared to
    the current situation, right? I still believe that this problem can
    be balanced with our proposal, and that the opportunities raised by
    multipath circuits also worth such loss.

    

    Best,

    Florentin

    

    

      

      

        
For website fingerprinting, it does seem to be interesting if the attack
cannot link the two paths :)


      

      
This is by far the easiest argument to make for both the switch to two
guards, the switch to conflux, and for the addition of padding: we know
from the research literature on website traffic fingerprinting that more
multiplexing reduces attacker accuracy. Both conflux and always-on two
guards increase overall multiplexing, and eliminate cases where lack of
multiplexing bites us hard.

However, the mere fact that this is true against website traffic
fingerprinting suggests to me that increased multiplexing and traffic
splitting is useful in other traffic analysis scenarios.



      

      

      

      
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev