Re: [tor-dev] Proposal: The move to two guard nodes
Roger Dingledine: > On Wed, Apr 11, 2018 at 11:15:44AM +, Mike Perry wrote: > > > To be clear, the design I've been considering here is simply allowing > > > reuse between the guard hop and the final hop, when it can't be avoided. I > > > don't mean to allow the guard (or its family) to show up as all four > > > hops in the path. Is that the same as what you meant, or did you mean > > > something more thorough? > > > > By all path restrictions I mean for the last hop of the circuit and the > > first (though vanguards would be simpler if we got rid of them for other > > hops, too). > > Can you lay out for us the things to think about in the Vanguard design? > Last I checked there were quite a few Vanguard design variants, ranging > from "two vanguards per guard, tree style" to some sort of mesh. > > In particular, it would be convenient if there is a frontrunner design > that really would benefit from relaxing many path restrictions, and a > frontrunner design that is not so tied together to the path restriction > question. There are two frontrunner forms. One has no path restrictions, the other would try to perform restriction checks on each layer to ensure that it is valid and doesn't leak info about other layers or prevent circuit creation. They are otherwise the same. Both are mesh; both are tunable in the number of guards and rotation times in each layer. I am leaning towards "no restrictions" for vanguards for 0.3.4 because it is simpler, and it did not strike me that the arguments in their favor justified trying to implement them quickly in a way that might cause reachability or path influence risks. > > But I do mean all restrictions, not just guard node choice. > > The adversary also gets to force you to use a second network path > > whenever they want via the /16 and node family restrictions. > > Can you give us a specific example here, for this phrase "network > path"? When you say "second network path" are you thinking in the > Vanguard world? Second path to entry into the Tor network (and a second guard), regardless of vanguards. > > > I'd like to hear more about the "cleverly crafted exit policy" attack > > > > another way to do this type of exit rotation attack is to cause > > a client to look up a DNS name where you control the resolver, and keep > > timing out on the DNS response. The client will then retry the stream > > request with a new exit. The same thing can also be done by timing out > > the TCP handshake to a server you control. Both of these attacks can be > > done with only the ability to inject an img tag into a page. > > > > You repeat this until an exit is chosen that is in the same /16 or > > family as the guard, and then the client uses a second network path for > > an unmultiplexed request at a time you control. > > The three fixes that come to mind are > > (A) "Have two guards": so you can pick any exit you like, and then just > use the guard that doesn't conflict with the exit you picked. > > (B) "Add a bonus hop when needed": First relax the /16 and family > restrictions, so the remaining issue is reuse of your guard. Then if > you find that you just chose your guard as your exit, insert an extra > hop in the middle of that circuit. > > (C) "Exits can't be Guards": First relax the /16 and family restrictions, > so the remaining issue is reuse of your guard. Then notice that due > to exit scarcity, guards aren't actually used in the exit position > anyway. Then enforce that rule (so they can't be in the future either). > > All three of these choices have downsides. But all three of them look > like improvements over the current situation -- because of how crappy > the current situation is. > > (Rejected option (D): "Just start allowing it": Relax the /16 and > family restrictions, and also relax the rule where relays refuse a > circuit that goes right back where it came from. Giving the middle node > that much information about the circuit just wigs me out.) > > Also, notice that I think Mike's proposed design will turn out to be some > combination of "A" and also something like "B" or "C", because even if > you start with two guards, if you don't add a new guard right when your > first guard goes down, you might find yourself in the situation where > you have one working guard, and you pick it as your exit, and now you > need to do *something*. The one-guard-down case does impact things. But even when this does happen (which should be rare), it should only be true for a small window of time before the consensus updates. The "down" guard should either be temporarily overloaded, or fully down and kicked off the consensus. I think we should only add a new guard when one falls out of the consensus, or both are unreachable/unusable. This is why I think it is OK to take an incremental approach and start with A, and roll out things like B and C and other restriction relaxations. During these edge cases, the most important property that we should
Re: [tor-dev] Proposal: The move to two guard nodes
On Wed, Apr 11, 2018 at 11:15:44AM +, Mike Perry wrote: > > To be clear, the design I've been considering here is simply allowing > > reuse between the guard hop and the final hop, when it can't be avoided. I > > don't mean to allow the guard (or its family) to show up as all four > > hops in the path. Is that the same as what you meant, or did you mean > > something more thorough? > > By all path restrictions I mean for the last hop of the circuit and the > first (though vanguards would be simpler if we got rid of them for other > hops, too). Can you lay out for us the things to think about in the Vanguard design? Last I checked there were quite a few Vanguard design variants, ranging from "two vanguards per guard, tree style" to some sort of mesh. In particular, it would be convenient if there is a frontrunner design that really would benefit from relaxing many path restrictions, and a frontrunner design that is not so tied together to the path restriction question. > But I do mean all restrictions, not just guard node choice. > The adversary also gets to force you to use a second network path > whenever they want via the /16 and node family restrictions. Can you give us a specific example here, for this phrase "network path"? When you say "second network path" are you thinking in the Vanguard world? > We're not using one guard in the current Tor. We're using two, and the > second one is only used for unmultiplexed activity. That is one property > I don't like about our "let's pretend to use one guard" status quo. Right, I agree. > > I'd like to hear more about the "cleverly crafted exit policy" attack > > another way to do this type of exit rotation attack is to cause > a client to look up a DNS name where you control the resolver, and keep > timing out on the DNS response. The client will then retry the stream > request with a new exit. The same thing can also be done by timing out > the TCP handshake to a server you control. Both of these attacks can be > done with only the ability to inject an img tag into a page. > > You repeat this until an exit is chosen that is in the same /16 or > family as the guard, and then the client uses a second network path for > an unmultiplexed request at a time you control. Hm! Yes, this is a yucky one. (I don't think just an img tag would be enough, because Tor will try a few circuits and then give up. You'd need some sort of javascript or refresh chain or the like that generates new addresses and tries them in succession. But that's totally feasible.) This one is also yucky because we could also imagine a different way to pick your path, where when you're selecting your exit, you avoid choosing exits which would conflict with your guard, and thus you'll never be pushed off of your guard. But then the destination website can do this same attack over time and notice which exit you never try to use. So this is a case where to blend in best, we *need* to be willing to use all of the potential exits. But since normal exit circuits are three hops, if we simply relax the path restrictions, we could be making a circuit of the form "A - B - A", which would not only stand out as weird to B, but actually right now a relay in B's position will refuse such a circuit. Bad news all around. The three fixes that come to mind are (A) "Have two guards": so you can pick any exit you like, and then just use the guard that doesn't conflict with the exit you picked. (B) "Add a bonus hop when needed": First relax the /16 and family restrictions, so the remaining issue is reuse of your guard. Then if you find that you just chose your guard as your exit, insert an extra hop in the middle of that circuit. (C) "Exits can't be Guards": First relax the /16 and family restrictions, so the remaining issue is reuse of your guard. Then notice that due to exit scarcity, guards aren't actually used in the exit position anyway. Then enforce that rule (so they can't be in the future either). All three of these choices have downsides. But all three of them look like improvements over the current situation -- because of how crappy the current situation is. (Rejected option (D): "Just start allowing it": Relax the /16 and family restrictions, and also relax the rule where relays refuse a circuit that goes right back where it came from. Giving the middle node that much information about the circuit just wigs me out.) Also, notice that I think Mike's proposed design will turn out to be some combination of "A" and also something like "B" or "C", because even if you start with two guards, if you don't add a new guard right when your first guard goes down, you might find yourself in the situation where you have one working guard, and you pick it as your exit, and now you need to do *something*. > Our path restrictions also cause normal exiting clients to use a second > guard for unmultiplexed activity, at adversary controlled times, or just > at periodically at random. Just to make
Re: [tor-dev] Proposal: The move to two guard nodes
Roger Dingledine: > On Sat, Mar 31, 2018 at 06:52:51AM +, Mike Perry wrote: > > 3.1. Eliminate path restrictions entirely > > > I'm increasingly a fan of this option, the more I read these threads. > > Let's examine the two attacker assumptions behind two of the attacks > we're worried about. > > Attack one: the client's local ISP collects coarse netflow logs, and these > logs aren't detailed enough to allow a traffic volume detection attack on > an existing long-lived TLS flow, so the connection to that first guard > is safe; but a connection to that second guard will be unusual and not > multiplexed and at exactly the time of the adversary-controlled circuit > that triggered it, so that second guard, because it is used so rarely, > is dangerous to use. > > Attack two: if the client uses its guard as the first hop of its circuit > and also the adversary-requested fourth hop, then the guard can do > pairwise traffic correlation attacks on all of its circuits and realize > that these two circuits it has are really two pieces of the same circuit. > > This second attack seems weird to me. One reason is because in attack > one we're brushing aside the traffic analysis as hard, whereas in attack > two we're assuming it's trivial and perfect. But the simpler reason is: > if your guard is going to participate in a traffic correlation attack > against you, then it could just as easily team up with some other relay > that the adversary picked. That is, avoiding reusing your guard on the > other end of the circuit isn't going to save you if your guard is out > to get you. I agree. I am not concerned about attack two. But we're not choosing between just these two attacks. > To be clear, the design I've been considering here is simply allowing > reuse between the guard hop and the final hop, when it can't be avoided. I > don't mean to allow the guard (or its family) to show up as all four > hops in the path. Is that the same as what you meant, or did you mean > something more thorough? By all path restrictions I mean for the last hop of the circuit and the first (though vanguards would be simpler if we got rid of them for other hops, too). But I do mean all restrictions, not just guard node choice. The adversary also gets to force you to use a second network path whenever they want via the /16 and node family restrictions. And it happens naturally all the time. We're not using one guard in the current Tor. We're using two, and the second one is only used for unmultiplexed activity. That is one property I don't like about our "let's pretend to use one guard" status quo. The second thing I don't like is that one guard is fragile, which enables confirmation attacks when it can be made to go down. > I think "can't be avoided" means HSDir, IP, RP -- which I note are all > onion service related circuits. > > I'd like to hear more about the "cleverly crafted exit policy" attack, and > I wonder if we can't solve that differently. For example, if it's about > making you do a request to a port that only one exit relay allows, and > ha ha whoops your guard was on the same /16 as that exit relay... maybe > it's time for the dir auths to not advertise super rare ports? This was > one of the topics in the users-get-routed paper too. Yes that is the one I was talking about. However, another way to do this type of exit rotation attack is to cause a client to look up a DNS name where you control the resolver, and keep timing out on the DNS response. The client will then retry the stream request with a new exit. The same thing can also be done by timing out the TCP handshake to a server you control. Both of these attacks can be done with only the ability to inject an img tag into a page. You repeat this until an exit is chosen that is in the same /16 or family as the guard, and then the client uses a second network path for an unmultiplexed request at a time you control. > One non-starter idea would be to move onion-service-related Tors to two > guards, and leave other Tors at one guard. It's a non-starter because of > course advertising which you are to your local network is no good. But > that idea gave me a different perspective on this discussion: I wonder > how much this design decision comes down to making all Tors use two > guards in order to protect the onion-service-related Tors, which are > the only ones who actually need it? Our path restrictions also cause normal exiting clients to use a second guard for unmultiplexed activity, at adversary controlled times, or just at periodically at random. > > However, while removing path restrictions will solve the immediate > > problem, it will not address other instances where Tor temporarily opts > > use a second guard due to congestion, OOM, or failure of its primary > > guard, and we're still running into bugs where this can be adversarially > > controlled or just happen randomly[5]. > > I continue to think we need to fix these. I'm glad to see
Re: [tor-dev] Proposal: The move to two guard nodes
On Sat, Mar 31, 2018 at 06:52:51AM +, Mike Perry wrote: > The main argument for switching to two guards is that because of Tor's > path restrictions, we're already using two guards, but we're using them > in a suboptimal and potentially dangerous way. > > Tor's path restrictions enforce the condition that the same node cannot > appear twice in the same circuit, nor can nodes from the same /16 subnet > or node family be used in the same circuit. > > Tor's paths are also built such that the exit node is chosen first and > held fixed during guard node choice, as are the IP, HSDIR, and RPs for > onion services. This means that whenever one of these nodes happens to > be the guard[4], or be in the same /16 or node family as the guard, Tor > will build that circuit using a second "primary" guard, as per proposal > 271[7]. > > Worse still, the choice of RP, IP, and exit can all be controlled by an > adversary (to varying degrees), enabling them to force the use of a > second guard at will. I agree with you that we should do something about this bug, where Tor clients will switch to a rarely used guard in some situations. Our fix from ticket #14917 was not a good fix. More on that below in Section 3.1. > Not surprisingly, > the two guard adversary gets to compromise clients roughly twice as > quickly, but the timescales are still rather large even for the 10% > adversary: they only have 50% chance of success after 4 rotations, which > will take about 14 months with Tor's 3.5 month guard rotation. Three thoughts here: (A) You're right, 14 months doesn't sound bad here. (B) This calculation was ignoring churn, right? That is, guards going away before you wanted to rotate from them. So another way to phrase that would be "once eight of your guards have gone away, you're in bad shape"? Looking at it that way, it seems like two guards is more than twice as scary as one, since *either* of them going away moves you one step closer on the path. Not the end of the world, but worth noticing. And maybe partially solvable by your "when one of your two goes away, stick to the remaining one" design; more on that below. (C) Similarly, we should be sure to remember the network adversary here too. I don't know a simple way to reason about it well. Using more guards over time could be *less* than twice as scary, because sometimes the network paths overlap so you don't expose as much new surface area as you might have. And using more guards over time could be *more* than twice as scary, if the question is whether your traffic ever goes over that one bad place, since you have an exponentially low chance to *never* pick a guard where your traffic to/from that guard travels over the bad place. It really depends on your location, the guard locations, the Internet topology, and a bunch of other confusing factors. > Furthermore, our use of separate directory guards (and three of them) > means that we're not really changing the situation much with the > addition of another regular guard. Right now, directory guard use alone > is enough to track all Tor users across the entire world. Shit, you're right. The guard set fingerprint issue remains right now, because we never solved the directory guard side of it. :( > While the directory guard problem could be fixed[12] (and should be > fixed), it is still the case that another mechanism should be used for > the general problem of guard-vs-location management[9]. The part that freaks me out about all the designs I've seen here is the attack where the local adversary advertises a series of local wireless addresses, first to make you keep generating new guard contexts (similar to forcing quick guard rotation), or second to guess-and-check whether you've already got a guard context for some wireless address in the next city over. Maybe it can be solved by proper UI ("we'll just delegate the decision to the user"), but hoo boy. But that's a separate proposal fortunately. :) > 3.1. Eliminate path restrictions entirely > I'm increasingly a fan of this option, the more I read these threads. Let's examine the two attacker assumptions behind two of the attacks we're worried about. Attack one: the client's local ISP collects coarse netflow logs, and these logs aren't detailed enough to allow a traffic volume detection attack on an existing long-lived TLS flow, so the connection to that first guard is safe; but a connection to that second guard will be unusual and not multiplexed and at exactly the time of the adversary-controlled circuit that triggered it, so that second guard, because it is used so rarely, is dangerous to use. Attack two: if the client uses its guard as the first hop of its circuit and also the adversary-requested fourth hop, then the guard can do pairwise traffic correlation attacks on all of its circuits and realize that these two circuits it has are really two pieces of the same circuit. This second attack
Re: [tor-dev] Proposal: The move to two guard nodes
Mike Perrywrites: > In-line below for ease of comment. Also available at: > https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals/xxx-two-guard-nodes.txt?h=twoguards > > === > > Filename: xxx-two-guard-nodes.txt > Title: The move to two guard nodes > Author: Mike Perry > Created: 2018-03-22 > Supersedes: Proposal 236 > > > > 3.1. Eliminate path restrictions entirely > > If Tor decided to stop enforcing /16, node family, and also allowed the > guard node to be chosen twice in the path, then under normal conditions, > it should retain the use of its primary guard. > > This approach is not as extreme as it seems on face. In fact, it is hard > to come up with arguments against removing these restrictions. Tor's > /16 restriction is of questionable utility against monitoring, and it can > be argued that since only good actors use node family, it gives influence > over path selection to bad actors in ways that are worse than the benefit > it provides to paths through good actors[10,11]. > > However, while removing path restrictions will solve the immediate > problem, it will not address other instances where Tor temporarily opts > use a second guard due to congestion, OOM, or failure of its primary > guard, and we're still running into bugs where this can be adversarially > controlled or just happen randomly[5]. > Seems like the above paragraph is our main argument against removing path restrictions. Might be worth pointing out that if congestion/OOM attacks are in our threat model against the current single guard design, then the same adversary can force prop#291 to open a connection to the *third* guard by first doing an OOM/congestion attack against one of your first two guards, and then pushing you to your third guard using a path restriction attack (#14917). Thought that I should mention that because it might be an argument for both moving to two guards and also lifting some path restrictions... ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal: The move to two guard nodes
Mike Perrywrites: > In-line below for ease of comment. Also available at: > https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals/xxx-two-guard-nodes.txt?h=twoguards > > === > > Filename: xxx-two-guard-nodes.txt > Title: The move to two guard nodes > Author: Mike Perry > Created: 2018-03-22 > Supersedes: Proposal 236 > > > > 3.1. Eliminate path restrictions entirely > > If Tor decided to stop enforcing /16, node family, and also allowed the > guard node to be chosen twice in the path, then under normal conditions, > it should retain the use of its primary guard. > > This approach is not as extreme as it seems on face. In fact, it is hard > to come up with arguments against removing these restrictions. Tor's > /16 restriction is of questionable utility against monitoring, and it can > be argued that since only good actors use node family, it gives influence > over path selection to bad actors in ways that are worse than the benefit > it provides to paths through good actors[10,11]. > > However, while removing path restrictions will solve the immediate > problem, it will not address other instances where Tor temporarily opts > use a second guard due to congestion, OOM, or failure of its primary > guard, and we're still running into bugs where this can be adversarially > controlled or just happen randomly[5]. > Hello Mike, IMO we should not portray removing the above path restrictions as something extreme, until we have good evidence that those path restrictions offer something positive in the cases we are examining. Personally, I see the result of this proposal of making Sybil attacks two times more quick (section 2.3), as an equally radical result. That said, I feel that this proposal is valuable and I'm not trying to say that I don't like this proposal, or that I don't buy the arguments. I'm trying to say that I don't know how to weight the tradeoffs here so that I gain confidence, because I'm not sure how people are trying to attack Tor clients right now. The way I see it is that if we adopt this proposal: + We are better defended against active attacks like congestion attacks and OOM/DoS attacks. + We improve network health by reducing congestion to certain guards. - Sybil attacks can be performed two times more quickly. IMO, we should not rush this decision for 034, given that it's a concensus parameter change that can happen instantaneously. However, we should do the following soon: 1) Accept that there is no single best guard topology, and fix our codebase to work well with either one guard or two guards, so that we are ready for when we flip the switch. Perhaps we can fix #25753/#25705/etc. in a way that works well both now and in the 2-guard future? 2) Investigate our current prop#271 codebase and make sure that the paragraph below will work as intended if we do this proposal. 3) Involve more peple into this (Roger, NRL, etc.) and have them think about this, to gain more confidence. Do you think this approach is too slow or backwards? Just to speed it up, I just did (2) below: > Note that for this analysis to hold, we have to ensure that nodes that > are at RESOURCELIMIT or otherwise temporarily unresponsive do not cause > us to consider other primary guards beyond than the two we have chosen. > This is accomplished by setting guard-n-primary-guards to 2 (in addition > to setting guard-n-primary-guards-to-use to 2). With this parameter > set, the proposal 271 algorithm will avoid considering more than our two > guards, unless *both* are down at once. > OK, the above paragraph is basically the juice of this proposal! I spent all day today to investigate how this would work! The results are very positive, but also not 100% straightforward because of the various intricancies of prop#271. [First of all, there is no way to simulate the above topology using the config file because if you set NumEntryGuards=2 in your torrc, Tor will setup 4 primary guards because of the way get_n_primary_guards() works. So I hacked my Tor client to *have* 2 primary guards (guard-n-primary-guards), and *use* 2 primary guards (guard-n-primary-guards-to-use).] The good part: This topology works exactly how the proposal wants it to work. Because of the way primary guards work, you will have 2 primary guards, and if one of them goes down you will always use the other primary, instead of falling back to a third guard. That's excellent, but it's also abusing the primary guard feature in a good way but not in the way we were intending it to be used. Here are the side-effects from this abuse: - By reducing the amount of primaries from three to two, it's more likely that all primaries can be down at a given time. Prop#271 was written with an inherent assumption that one of the primaries will always be reachable, because when all of them are down the code goes into an "oh
Re: [tor-dev] Proposal: The move to two guard nodes
On Sat, Mar 31, 2018 at 2:52 AM, Mike Perrywrote: > In-line below for ease of comment. Also available at: > https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals/xxx-two-guard-nodes.txt?h=twoguards > > === > > Filename: xxx-two-guard-nodes.txt > Title: The move to two guard nodes > Author: Mike Perry > Created: 2018-03-22 > Supersedes: Proposal 236 Added as proposal 291! ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Proposal: The move to two guard nodes
In-line below for ease of comment. Also available at: https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals/xxx-two-guard-nodes.txt?h=twoguards === Filename: xxx-two-guard-nodes.txt Title: The move to two guard nodes Author: Mike Perry Created: 2018-03-22 Supersedes: Proposal 236 0. Background Back in 2014, Tor moved from three guard nodes to one guard node[1,2,3]. We made this change primarily to limit points of observability of entry into the Tor network for clients and onion services, as well as to reduce the ability of an adversary to track clients as they move from one internet connection to another by their choice of guards. 1. Proposed changes 1.1. Switch to two guards per client When this proposal becomes effective, clients will switch to using two guard nodes. The guard node selection algorithms of Proposal 271 will remain unchanged. Instead of having one primary guard "in use", Tor clients will always use two. This will be accomplished by setting the guard-n-primary-guards-to-use consensus parameter to 2, as well as guard-n-primary-guards to 2. (Section 3.1 covers the reason for both parameters). This is equivalent to using the torrc option NumEntryGuards=2, which can be used for testing behavior prior to the consensus update. 1.2. Enforce Tor's path restrictions across this guard layer In order to ensure that Tor can always build circuits using two guards without resorting to a third, they must be chosen such that Tor's path restrictions could still build a path with at least one of them, regardless of the other nodes in the path. In other words, we must ensure that both guards are not chosen from the same /16 or the same node family. In this way, Tor will always be able to build a path using these guards, preventing the use of a third guard. 2. Discussion 2.1. Why two guards? The main argument for switching to two guards is that because of Tor's path restrictions, we're already using two guards, but we're using them in a suboptimal and potentially dangerous way. Tor's path restrictions enforce the condition that the same node cannot appear twice in the same circuit, nor can nodes from the same /16 subnet or node family be used in the same circuit. Tor's paths are also built such that the exit node is chosen first and held fixed during guard node choice, as are the IP, HSDIR, and RPs for onion services. This means that whenever one of these nodes happens to be the guard[4], or be in the same /16 or node family as the guard, Tor will build that circuit using a second "primary" guard, as per proposal 271[7]. Worse still, the choice of RP, IP, and exit can all be controlled by an adversary (to varying degrees), enabling them to force the use of a second guard at will. Because this happens somewhat infrequently in normal operation, a fresh TLS connection will typically be created to the second "primary" guard, and that TLS connection will be used only for the circuit for that particular request. This property makes all sorts of traffic analysis attacks easier, because this TLS connection will not benefit from any multiplexing. This is more serious than traffic injection via an already in-use guard because the lack of multiplexing means that the data retention level required to gain information from this activity is very low, and may exist for other reasons. To gain information from this behavior, an adversary needs only connection 5-tuples + timestamps, as opposed to detailed timeseries data that is polluted by other concurrent activity and padding. In the most severe form of this attack, the adversary can take a suspect list of Tor client IP addresses (or the list of all Guard node IP addresses) and observe when secondary Tor connections are made to them at the time when they cycle through all guards as RPs for connections to an onion service. This adversary does not require collusion on the part of observers beyond the ability to provide 5-tuple connection logs (which ISPs may retain for reasons such as netflow accounting, IDS, or DoS protection systems). A fully passive adversary can also make use of this behavior. Clients unlucky enough to pick guard nodes in heavily used /16s or in large node families will tend to make use of a second guard more frequently even without effort from the adversary. In these cases, the lack of multiplexing also means that observers along the path to this secondary guard gain more information per observation. 2.2. Why not MOAR guards? We do not want to increase the number of observation points for client activity into the Tor network[1]. We merely want better multiplexing for the cases where this already happens. 2.3. Can you put some numbers on that? The Changing of the Guards[13] paper studies this from a few different angles, but one of the crucially missing