17:01:09 <asn> #startmeeting prop#291
17:01:09 <MeetBot> Meeting started Wed Apr 18 17:01:09 2018 UTC.  The chair is asn. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:09 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:01:16 <asn> we have a pad here: https://pad.riseup.net/p/TwoGuardMeeting
17:01:22 <syverson> Hi all. Yes Paul returns to IRC!
17:01:26 <asn> where we are trying to organize things in some capacity
17:02:04 <mikeperry> ok the high level summary is that Tor's path restrictions are already causing us to use two guards right now
17:02:28 <mikeperry> so we're trying to decide if we should remove them, and/or if we should keep using two guards on purpose
17:02:45 * arma4 is here
17:03:17 <mikeperry> #14917 is the original bug that caused us to start using a secondary guard for some activity
17:03:17 <nickm> I vote for 2 (primary) guards
17:03:39 <mikeperry> and there are related issues where this can happen with normal exit traffic
17:04:05 <asn> my position is: we might want to switch to two guards. but regardless of whether we switch to 2 guards, we need to lift the path restrictions, because even with 2 guards, if a guard is down then we get the same problem as currently if path restrictions are enabled.
17:04:05 <mikeperry> and this use of a second guard can be forced by an adversary whenever they like, for both onion services and exit traffic
17:04:33 <asn> hence we should focus on lifting path restrictions for the short-term (034?), and consider 2-guards as a more medium-term action (035?).
17:04:36 <nickm> asn: I don't agree; the guard system is designed for guards to go down sometimes.
17:05:06 <ohmygodel> hello ?
17:05:08 <arma4> asn: i think they're intertwined. that is, if we can fix the path restriction thing a little, or a lot, influences how important it is to switch to 2 guards.
17:05:24 <mikeperry> I agree with asn, but I don't believe that relaxing restrictions is as urgent with two guards. at least I don't see it as a blocker, but a nice-to-fix edge case
17:05:24 <arma4> ohmygodel: welcome! mikeperry is trying to organize us with https://pad.riseup.net/p/TwoGuardMeeting
17:05:27 <nickm> A note: The whole concept of "two guards" is slightly wrong.
17:05:34 <ohmygodel> arma4: thanks!
17:05:54 <nickm> that is, under the current guard design, there are multiple numbers to tune.  One of them is the number of primary guards.
17:06:00 <nickm> two primary guards at a time is possible...
17:06:19 <nickm> but "two guards ever" is fundamentally not, since guards can go up and down.
17:06:28 <arma4> right
17:06:55 <nickm> the guard-spec.txt document (formerly prop#271) has details
17:07:05 <mikeperry> well one very desirable property is to not immediately start using a third guard if one of the two primary go down.
17:07:11 <mikeperry> or at least, that seems desirable to me
17:07:31 <asn> mikeperry: that's a property of the "primary guards" feature. so we good there.
17:07:41 <asn> (if we only use 2 primary guards)
17:07:56 <mikeperry> asn: yes, we have to set both prop#271 params to 2 to get it
17:08:24 <mikeperry> (and when we do that, if both go down, we wander into the wilderness of playing with sampled guards and maybe not making progress right away)
17:09:12 <asn> yes. this wilderness is scary to me. because we have not really experiemnted with all primaries being down. i experimented a bit with it and i found #25783 almost immediately.
17:09:31 <asn> and it's easier for 2 primaries to be down, than 3 (status quo).
17:09:52 <nickm> could do 3 primary, use-first-2
17:09:57 <arma4> it seems to me that most of the design variants we're considering will involve changing code in tor. and to me this is ok.
17:10:09 <asn> nickm: yes we could. that would need to be a new feature tho.
17:10:14 <mikeperry> the way prop#271 works is that it has "number of primary guards" and "number of primary guards to use". if we set the first at 3 and the second at 2, then it is my understanding that even invalid path restrictions will cause us to use that third guard
17:10:15 <asn> and this is ok.
17:10:23 <mikeperry> (because it will be eliminated from the primary guard list in that case)
17:10:49 <arma4> (or said another way, using the wrong design because it's easy to switch to with our current code seems a bad choice to me.)
17:11:06 <asn> mikeperry: i think you are right.
17:11:16 <mikeperry> so we still have the whole "adversary gets to force an additional network path, just for some specific activity": property that I think is really bad for traffic analysis
17:11:27 <nickm> arma4: Does that mean you're volunteering to implement this? :)
17:11:40 <arma4> maybe?
17:11:49 <arma4> i think step zero is to figure out what we would like to have
17:12:10 <arma4> but guards are crucial to tor's security, so let's try to get it at least mostly right
17:12:54 <arma4> anyway. mike, how can we make progress here?
17:12:59 <nickm> does anyone prefer options other than some variant of the 2-guard approach for this?
17:13:48 <ohmygodel> 2 guards makes sense to me
17:13:55 <arma4> i think i like "some variant of the 2-guard approach" best, yes.
17:14:36 <nickm> asn: Do you still think we need to allow circular paths?
17:14:39 <ohmygodel> it seems to be forced by requiring both path restrictions and no leakage at the exit
17:14:53 <asn> i can get behind 2-guard approach. but if we do that without lifting path restrictions, the moment one of our guards is down/DoS/OOM, we are vulnerable to the naive #14917 attack.
17:15:14 <mikeperry> we are also vulnerable if we choose both guards from the same /16 or family
17:15:23 <asn> and when i read prop#291 i see DoS/OOM be the main argument for 2-guards in section-3.1
17:15:39 <ohmygodel> (i agree with mike it is very bad to switch to a second guard sometimes by chance and in a way that the adversary may be able to control)
17:16:00 <ohmygodel> (probbably at least as bad as just using two guards equally)
17:16:14 <nickm> When we say "lifting path restrictions" we mean, "allowing the guard to also be the last node of the circuit", right?
17:16:24 <nickm> because that seems worse than #14917
17:16:30 <asn> nickm: yes. the guard, and its /16 and its family.
17:16:38 <asn> nickm: in what way?
17:16:41 <arma4> nickm: there are two variations of lifting path restrictions. there's the one where you lift the /16 and family restriction. or the one where you lift the /16 and the family and the guard itself.
17:16:44 <nickm> #14917 is guard discovery
17:17:03 <nickm> same node for entry and exit is full deanon
17:17:10 <arma4> is it?
17:17:20 <arma4> even in a four hop path?
17:17:50 <syverson> well certainly by the guard itself.
17:17:55 <asn> hm. full deanon by whom? evil guard? imo, with evil guard we screwed anyhow.
17:18:12 <arma4> seems to me that if we're choosing among bad options, that one's on the table as a possible choice
17:18:55 <arma4> also (see tor-dev) thread, if having the guard at the beginning and end of your circuit is bad, then for 6-hop onion circuits, you can't know whether your guard is reused on the other side of the path.
17:19:10 <arma4> so, right, a simple version of the argument is "either your guard is evil or it isn't"
17:19:25 <nickm> "so let's use one-hop paths; tor was a mistake"
17:19:47 <arma4> no, the other hops are useful if your guard isn't evil
17:19:57 <ohmygodel> lifting the restriction on allowing the guard at the rendezvous point alone seems like a good option
17:20:09 <mikeperry> is using the same guard in the path any worse than using two different nodes controlled by the same adversary?
17:20:09 <arma4> ohmygodel: rendezvous point, and intro point, and hsdir?
17:20:20 <mikeperry> (are there perhaps more side channels if it is the very same tor daemon?)
17:20:31 <ohmygodel> there are multiple introduction points and hsdirs
17:20:56 <arma4> ohmygodel: onion service side, they need to reach all of them
17:21:10 <ohmygodel> arma4: oh right
17:21:11 <nickm> We could adapt the protocol so that the client offers a choice of rendezvous points. :)
17:21:14 <arma4> ohmygodel: and there are slow leaks if the client never uses a certain intro point, or the service never picks a certain one
17:21:21 <nickm> so long as we're talking about protocol adaptation
17:21:39 <nickm> right; those _are_ slower than "just don't connect", or "use other guard".
17:21:43 <nickm> but they're still there
17:22:03 <ohmygodel> well then moving to 2 guard seems to be an improvement over the current state
17:22:16 <asn> also given the [tor-dev] thread it seems tha this threat might also exist in normal exit circs.
17:22:26 <ohmygodel> removing path restrictions in those cases seems like it could be considered separately
17:22:46 <mikeperry> do we enforce that those two are always chosen from a different /16 + family? (that is neccessary to prevent the same thing from happening in some possibly rare but possibly common cases)
17:23:07 <nickm> we do not, but we could.
17:23:22 <nickm> we'd need to actually specify it, in some way that was compatible with guard-spec
17:23:26 <dmr> I agree that removing the path restrictions should be considered separately; as arma4 points out, each path restriction should probably be considered individually
17:23:30 <ohmygodel> yes that seems important
17:23:37 <asn> agreed
17:23:50 <mikeperry> +1
17:23:56 <nickm> (what are we +1ing?)
17:24:08 <ohmygodel> (that being requiring /16 + family diversity for at least first 2 primary guards)
17:24:17 <nickm> ah.
17:24:24 <mikeperry> I am imagining filing a  parent ticket about ways we want to change Tor's path restrictions and/or how they apply in these cases
17:24:24 <nickm> yes, it's a good idea.
17:24:45 <mikeperry> and if we want to keep restrictions, then diversity would be a neccessary sub-ticket
17:24:51 <nickm> Changing path restrictions: +1.  Removing them: I don't think so.
17:25:23 <dmr> nickm: right, that's a concise way to put what I tried to say
17:25:29 <arma4> i have written a proposed combination of choices at the bottom of the pad. and pasted here:
17:25:30 <arma4> * Remove /16 and family path restrictions between guard and last hop
17:25:30 <arma4> * Dir auths don't give you Guard if you're an Exit
17:25:30 <arma4> * Use first guard but pad to backup guard so the switch isn't as obvious
17:25:30 <arma4> * First and backup guard are chosen in different /16's and different families
17:26:02 <asn> "pad to backup guard" seems pretty weak in terms of hiding transitions.
17:26:22 <arma4> what would be stronger, against an adversary that knows the difference?
17:26:45 <mikeperry> well it also means that we have to redefine a lot of the prop#271 logic and how we are approaching oom/transient failure bugs
17:27:06 <arma4> i think we're handling many oom/transient failure bugs wrong right now
17:27:14 <arma4> so we're going to have to fix those
17:27:21 <mikeperry> the key benefit of "two equally likely guards" is that if a circuit fails due to brief downtime or resource exhaustion in guard #1, we immediately try guard #2, and Tor behaves this way right now
17:27:29 <arma4> like, the one where your guard stops handling circuits for you, so you...keep asking it for circuits
17:27:33 <mikeperry> without us needing to write a bunch of complicated detection/decision logic
17:28:01 <dmr> just want to add that prop#291 (esp. "2 primary guards") may have impact on how we communicate the persistent-guard design to users, e.g. #24309 (see my comment on wording)
17:28:06 <dmr> that shouldn't impact this discussion much, but I think it's important to recognize some of the communication we may need to do about this
17:28:09 <arma4> yep. and the key benefit of "first and backup" is that you don't expose your traffic to a second place that didn't need to see it.
17:28:12 <dmr> ^ added this ticket to the pad
17:29:33 <arma4> in either case, we also need to define what you should do when one of your guards fails, and you're down to one. eventually you want to add another, and start using it in some way.
17:30:17 <mikeperry> arma4: I think there are subtleties to traffic analysis that make it harder when traffic is actually going to two places.. consider the HS connection fingerprinting problem, for example.. that is a multi-circuit process that is actually easier to recoginze if it is all at one guard
17:31:06 <syverson> and it's easier to with confidence say there is one client per guard in that case.
17:31:11 <mikeperry> and in the long-term I think we are going to find a lot of similar outcomes with traffic splitting/conflux
17:31:12 <ohmygodel> "pad to backup guard" is an intriguing option
17:32:19 <arma4> mikeperry: i agree that in the hypothetical future where we have a conflux design we like, spreading the traffic across the two guards to achieve that design would be appealing.
17:32:40 <dmr> mikeperry: you're saying that having 2 guards, with splitting/conflux, likely will make traffic analysis harder? (in the hypothetical future)
17:32:48 <syverson> I mean individual user fingerprinting of particular onion service activity by middles is better with one guard default vs. two
17:32:50 <ohmygodel> it could help limit the ability to perform traffic analysis (website fingerprinting or correlation) by limiting real traffic (usually) to one guard
17:32:55 <arma4> the hs connection fingerprinting problem is an interesting one. i wonder how much protection we get if we just have two guards and don't use them strategically, there.
17:32:59 <mikeperry> dmr: and also right now, for some cases..
17:33:48 <arma4> syverson: ah ha, right, if you have two active guards, and you offer two onion services, or you offer one onion service and you go to other sites, then any successful guard enumeration attacks track you down to your guard pair, which is much more unique.
17:33:57 <mikeperry> not knowing if you have seen all traffic or what percentage of it, especially if it is multiplexed at some level (like you watching the guard instead of being the guard), changes your certainty and ability to inference about specific patterns
17:34:29 <ohmygodel> mikeperry: traffic correlation seems unlikely to get any harder when splitting  traffic across guards
17:34:33 <nickm> arma4: that attack is still possible with one guard: Identity the guard, DoS it, identity the 2nd guard.  Now you have a pair of guards.
17:34:55 <asn> arma4: you want "pad to backup guard" so that we don't use 2-guards, to keep sybils as hard as now?
17:34:56 <arma4> ohmygodel: well, it gets harder for each of the guards, maybe? since they see only a subset?
17:34:56 <syverson> arma4: I meant a middle with an onion service fingerprint has greater assurance that a connection from the same guard is from one user.
17:35:03 <asn> arma4: this seems to be the main argument against 2-guards right now.
17:35:28 <ohmygodel> also its pretty unclear how website fingerprinting (which already tolerates tolerates noise and learn on robbust features) would be affected
17:36:26 <arma4> asn: my main worry with actively using two guards is that you expose your traffic to more surface area -- the other guard and the network between you and the other guard.
17:36:27 <mikeperry> ohmygodel: I disagree. the key thing that makes me disagre is that traffic is not being split in a way that the adversary has knowledge about, esp for traffic fingerpriting classifiers..
17:37:32 <arma4> syverson: ah ha. so, for a client visiting an onion service, if you're on the path and you can identify the guard, then since you know clients use a first guard, you can conclude that it's more likely the same client that you saw using that guard last time.
17:37:41 <mikeperry> ohmygodel: as an edge case, consider the very rare 23.23MB download that can become any sum of its parts depending on network load at that time, blending in with different objects
17:38:02 <arma4> mikeperry: doesn't tor browser use the same circuit for the same destination tab? so, it would all be on one guard?
17:38:14 <arma4> (it the 23.23MB)
17:38:19 <ohmygodel> arma4: traffic correlation based on broad features such as “how much data do they appear to be receiving at this point in time?” doesn’t seem like it would be hidden by traffic splitting. traffic correlation based on low-information and fragile features  such as “did i see a specific circuit-creation cell at this point in time?” does seem like it could be affected.
17:38:39 <mikeperry> arma4: we are arguing about conflux.. which we probably shouldn't be at this time, I suppose..
17:39:06 <arma4> mikeperry: i think it's important for us to not mistakenly think we get conflux benefits just by sending traffic to the second guard too
17:39:09 <nickm> mikeperry: How much of this question needs to be decided for you to make progress on the vanguards work?
17:39:40 <syverson> arma4: yes. Don't know numbers for 1 vs 2. But in our arxiv paper, for 1 vs 3 we showed for 20 regular users 7 percent chance of guard overlap with one guard vs 50 percent with three.
17:40:06 <arma4> syverson: i wonder if vanguards are the best help against the attack you described.
17:40:36 <syverson> arma4: best? well possibly good anyway.
17:41:00 <mikeperry> nickm: I am currently blocked on what we decide about path restrictions. if we were going to abandon them entirely, vanguards got a lot easier.. but I think all of path restrictions just became a kind of big hairball
17:41:39 <nickm> mikeperry: so the main question we should solve right ways is "are we going to completely eliminate all path restrictions right away"?
17:41:48 <nickm> s/ways/away/
17:41:59 <mikeperry> arma4: I think thinking about the future is useful, because right now we are also considering a lot of complexity for trying to do oom/failure/downtime detection instead of just using a second guard.. which in the future, I think we have a pretty strong case for wanting to do all the time.
17:42:49 <mikeperry> (I also think that any "detection" we do inherently means *some* downtime while we wait to be sure, which is a signal..)
17:43:05 <mikeperry> where as if we just failed over to the second guard right away, there would be no downtime signal
17:43:14 <arma4> mikeperry: i agree, we should fail over right away.
17:43:35 <arma4> (when we're convinced that our first guard isn't going to be working well at least for the next little while)
17:43:51 <ohmygodel> mikeperry: can changing path restrictions be decided separately ? your main concern about path restrictions seemed to be how they affect vanguards, which are still being worked on.
17:43:58 <arma4> (like for example if it sends back a "destroy, i'm busy" in response to a circuit create attempt)
17:44:09 <mikeperry> I believe that the current code will fail over rigth away, *if* we set "number of primary guards" and "number of primary guards to use" to 2, and don't worry about the sampled guard wilderness just yet..
17:44:43 <arma4> it won't fail over right away in response to a destroy cell. that's one of our open tickets. are there more situations like that one, or is that one it?
17:45:22 <mikeperry> nickm: it feels to me like we do not want to remove all restrictions, and as long as we still have some, it will be just as complicated. (the main complication being that we need to choose vanguards and guards such that they cannot produce an "impossible to create any circuits" condition)
17:45:27 <syverson> This is all a mish-mash of trade-offs. Nothing is going to be better against all attacks while maintaining OK performance. Without an explicit description of adversaries and trade-offs these are all gut intutions combined with yabuttals.
17:45:49 <nickm> mikeperry: that seems like an accurate summary of where we're at.
17:46:02 <nickm> syverson: +1
17:46:23 <mikeperry> arma4,etc al: does prop#271 choose among more than one primary guard at random? I thought it does
17:46:37 <mikeperry> which means that a destroy will cause a retry with probability 1/2 at the second guard
17:46:48 <asn> mikeperry: if n-use-primary-guards is 2, yes prop#271 will choose amongst the 2 top at random
17:46:50 <mikeperry> so it should eventually build a circuit through that second guard fairly soon
17:46:55 <asn> mikeperry: it will use smartlist_choose()
17:47:01 <arma4> so, how to proceed? i see we have three proposals at the bottom of the pad. maybe we try to flesh those out with adversary descriptions and tradeoffs?
17:47:05 <mikeperry> yeah ok that's what I thought
17:47:23 <arma4> mikeperry: hm! i think you're right. it won't mark the busted guard as down, but if they're both up, it will randomly pick until it picks the other one.
17:47:48 <arma4> mikeperry: (in that situation, if they're both giving you destroy-i'm-busy, you sit there trying to make circuits to them anyway)
17:48:13 <arma4> (or if one of them is down and the other is giving you destroy-i'm-busy)
17:48:19 <asn> yes i think we are lacking the decision making process. and it also feels like rushing against the 034 clock, given that neither (1) or (2) are completrely straightforward to do.
17:48:47 <syverson> We only have intuitions right now about the difference between 1 guard with back-up versus 2 guards with an active adversary going after one of them.
17:49:16 <nickm> I think we can resolve mikeperry's question about vanguards at least: we aren't going to remove all restrictions so quickly that vanguards won't have to worry about them.
17:49:47 <arma4> i think that's fair. removing all restrictions means we might pick "A - A - A", and that seems bad when we could choose not to do it.
17:49:48 <asn> sounds reasonable.
17:50:16 <nickm> What do we think about my suggestions about tweaking hs behavior so that this situation happens less often?
17:50:23 <nickm> eg, making sure your intropoints are all the same family,
17:50:31 <nickm> chosing multiple RPs,
17:50:31 <nickm> etc
17:50:50 <arma4> i think the offering multiple RP one is a great attack vector. i give you pairs and see which one from each pair you pick.
17:50:57 <mikeperry> so I think we're having problems deciding because there are a lot of details that need to be worked out.. maybe what would help is a discussion as to if we feel like doing the simplest prop#271 param choice makes things better than the status quo, such that we can iterate on that?
17:51:51 <syverson> No ideas, but if we offer multiple RPs, we should think about what a malicious onion service could do with that choice against a client, not just vice versa.
17:52:09 <mikeperry> where in my mind, simplest is "num primary guards"=2 and "num primary guards to use"=2
17:52:22 <mikeperry> that still has edge cases, but they will be less often in practice than what we have now
17:53:00 <mikeperry> (because of product of probabilities, significantly less often for random uncorrelated events)
17:53:02 <arma4> mikeperry: so that proposal would be "expose client traffic to twice as many places, but at least now in a controlled way rather than an uncontrolled way, and then later we wait for arma to write his patch that will protect clients better again"?
17:53:13 <asn> mikeperry: i can get behind that for the short-term. i'm afraid it might reveal reachability issues due to prop#271 codebase, and if we merge it late in the 034 cycle we wont have enough time to find them and debug them.
17:53:49 <asn> (altho there is not much to merge. it's actually consensus params...)
17:53:57 <arma4> mikeperry: oh, your "simplest" didn't include "relax /16 and family restrictions on the last hop". that's intentional i presume.
17:54:10 <syverson> short-term ;>) like a hacked together bandwidth scanner that will get replaced soon?
17:54:26 <arma4> asn: consensus params is handy here, since it means we're not actually bound to a tor release cycle. except for bug fixes.
17:54:36 <ohmygodel> arma4: what’s your patch ?
17:54:47 <mikeperry> arma4: I'm very wary of trying to build active detection on this. I think that means it can be gamed/influenced in similar ways. I'd rather have our fallback characteristcs emerge from simple stochastic behavior, which thy kind of do now
17:54:59 <arma4> ohmygodel: in mike's proposal, it would be the one where we concentrate all our traffic on one of the guards when we can
17:55:21 <ohmygodel> arma4: ok yeah that makes a lot of sense to me
17:55:54 <arma4> asn: if there are bugs in the current code, like in 0.3.1, would they be exposed (and unfixed) if we change the consensus params?
17:55:55 <ohmygodel> it is really unfortunate if we need to expose client traffic to twice as many relays / ASes
17:56:16 <arma4> ohmygodel: well, mike's argument is that we sometimes do it right now. we just don't really understand when and why.
17:56:28 <asn> arma4: yeah. all post-0.3.0.1 tors will follow the consensus params IIRC.
17:56:42 <nickm> arma4, ohmygodel: we know some cases when and why.
17:56:52 <ohmygodel> the main concern seems to be that occasional / adversarial use of a second guard is just as bad as using two guards bad or worse
17:56:56 <mikeperry> I also don't like it being not very much traffic. I think we are underestimating the benefits of any level of concurrent activity against external observers
17:57:06 <mikeperry> (which are the main thing we get more of with two paths)
17:57:09 <arma4> asn: so, i think one early question to explore is: do those new consensus params produce bad behavior for 0.3.1 or 0.3.2 clients? or is everything great when we turn them on.
17:57:27 <ohmygodel> I can see that argument in the case that you go from no connection to some connection because of the way it sounds like ISPs might maintain flow records.
17:57:31 <syverson> wait. I thought mike's proposal was to chose both regularly not to mostly choose one and the other as needed. What did I miss?
17:58:00 <mikeperry> any hacks we try to do to "prefer one guard" mean that those times where we have to use the second guard leak more info than they would if there was other stuff going on
17:58:17 <ohmygodel> Padding to the second guard and concentrating traffic on the first seems like a good way to deal with this issue, while maintaining limited exposure of client traffic
17:59:08 <syverson> What is this padding? Are these real circuits to real destinations, to fake destinations, to no destinations, what?
17:59:10 <mikeperry> that padding will take a while to devise
17:59:23 <arma4> ohmygodel: i agree. the counterargument though is mike's intuition that "using a guard for real traffic makes things safer"
17:59:32 <ohmygodel> syverson: I am discussing arma’s proposed “patch”, which I just asked about
17:59:37 <arma4> syverson: it is netflow style padding. so one keepalive per 5 minutes or something.
17:59:42 <asn> arma4: based on my testing, moving both consensus params to 2 will work fine in most cases. but there can be edge cases where our guard algo will burp. to find these cases we need user testing.
18:00:05 <asn> arma4: (and more code/proposal reading)
18:00:32 <syverson> I'm dubious of that helping at all. But just registering that. Don't let me derail discussion of it to go into a side discussion.
18:00:48 <arma4> asn: *if* we encounter real bugs in the current code, then "just set the consensus params" screws all the stable tor clients. so it becomes less simple.
18:01:38 <arma4> asn: i'm ignoring 0.3.0 since it's dead already. and 0.3.1 could be dead pretty soon too. so that's not *so* terrible. but we should be aware of it as possible complexity.
18:01:45 <ohmygodel> The argument that using the second guard for real traffic doesn’t make a lot of sense to me. If we have an adversary that can force you to use a second guard, then it would seem that he can also force you to exchange an unusual (and detectable) amount of traffic with that guard.
18:02:10 <asn> yes indeed. that's why i'm saying that even the consensus params approach is not really straightforward. we will be entering unseen grounds.
18:02:31 <arma4> syverson: if you're dubious of that helping at all, then you might not be a fan of moving to two guards, since "use one and then use the other if you need to" might be all you need.
18:02:40 <asn> imo, _we_ should set up our tor clients to 2-primary-guards and use them for a while. see how that goes. and that's the most basic testing we could do from our western countries.
18:04:14 <mikeperry> ohmygodel: hrmm.. that is making me lean more towards eliminating path restrictions more than trying to engineer "favor one guard as much as we can"
18:04:54 * nickm notes that we are beginning our 2nd hour here
18:04:54 <arma4> ohmygodel: the netflow style adversary -- the one who can only read isp netflow logs -- would not learn when your large amount of traffic began or ended exactly. if you do netflow padding from the beginning of the connection.
18:04:54 <syverson> ohmygodel: arma4: I'll defer that discussion.
18:04:54 <dmr> asn, arm4: "all post-0.3.0.1 tors will follow the consensus params IIRC" - what's the population of tor clients that run something prior to 0.3.0.1? are we worried about the anonymity set reduction or backporting something to make others follow this?
18:04:54 <arma4> dmr: the tor clients running long term stable, 0.2.9, are using the old guard algorithm and don't care about these consensus params.
18:04:55 <ohmygodel> arma4: right, I was responding to the counterargument that you attributed to mike that padding to a second guard wouldn’t be as effective as real traffic in preventing traffic analysis
18:04:55 <arma4> they would indeed look more and more different, the more we change things.
18:05:08 <dmr> arma4: right, that's what I was trying to point out - are we worried about that?
18:05:10 <asn> i feel like this "pad to second guard" thing is not a short-term option. in the sense of 034.
18:05:25 <arma4> ohmygodel: i think you might be right. which is why i proposed the "concentrate traffic on one guard" design.
18:05:36 <asn> should we vote/decide on prop#291 as a short-term option? and see if we can reach a conclusion?
18:05:45 <asn> or leave it for another day?
18:05:47 <nickm> dmr: My current thinking on per-version fingerprinting is "let's not do it gratuitously, but it is to some extent inevitable"
18:05:57 <mikeperry> ohmygodel: but in the extreme, I think that multiplexed activity means that more traffic is required on those forced choices.. like if all that is happening is netflow-every-five-second cells normally, the signal the adverdsary needs does not have to be as heavy/loud as it does if there is a possibly unknown amount of other activity
18:06:36 <arma4> mikeperry: if most clients are idle some of the time, maybe the difference isn't so much.
18:06:53 <arma4> like, if i can give you content that makes your tor browser pause an hour and then start doing a pattern
18:07:07 <arma4> sucks to be you
18:09:03 <mikeperry> hrmm.. again making me not like path restrictions..
18:09:04 <arma4> asn: so, for prop291 as currently proposed. i think in favor: clients who have a collaborating netflow-style ISP adversary will be safer. but not if they have a smarter adversary. whereas, *all* clients will become less safe, because they volunteer to send their traffic elsewhere when they didn't need to.
18:09:56 <arma4> asn: also, if we *don't* do prop291, we need to do some of the "you switch guards when you didn't need to" fixes
18:09:56 <dmr> nickm: I think that's a really good rule of thumb. I just note that switching to a "2 primary guard" design would be a pretty obvious fingerprint difference.
18:10:11 <syverson> The issue is adversary controlling or observing contingent guard choice. So having any given backup the adversary can force you to (regardless of initial distribution between the, e.g., 2) is going to be worse than going to something else entirerly (for that adversary, though not for all attacks).
18:10:19 <nickm> dmr: that change from the old guard algorithm to the current guard algorithm was already such a difference.
18:10:55 <arma4> nickm: (but maybe not so big a difference? since they both used 1 guard most of the time?)
18:11:27 <syverson> So making performance/availability decisions within a known/discoverable set is problematic. That doesn't mean 2 guards makes no sense for other reasons.
18:11:43 <ohmygodel> mikeperry: That traffic to the second guard may not be very effective in hiding a signal from the adversary, if it is easy for the adversary to find otherwise idle periods for the client or to cause the client to generate/receive relatively large amounts of traffic at selected times. The traffic to the second guard does definitely make it possible for malicious observers of that connection to the second guard to do
18:11:43 <ohmygodel> fingerprinting/correlation where they wouldn’t otherwise be able to.
18:12:27 <arma4> mikeperry: wait, turns out i didn't understand why you said that. i pointed out that clients will be idle sometimes, and you said you don't like path restrictions?
18:13:26 <mikeperry> arma4: because they allow an otherwise idle client to be forced to use a specific guard rather than one at random
18:14:07 <asn> hmmm at idle clients
18:14:27 <asn> so they do nothing. but adversary can force them to connect to G1, G1, G1, G1 if they find the sweet spot.
18:14:39 <syverson> mikeperry: that's what I've been talking about.
18:15:08 <arma4> mikeperry: yeah. i think if we do "some variant of 2 guards", then we still need to decide "ok when do we avoid using a guard that would trigger our current path restrictions". like, maybe sometimes we should stick to using that guard anyway. and sometimes we really can't stick to it.
18:16:26 <arma4> asn: and in my pad-to-backup design, adversary can force them to connect to G2, G2, G2, G2 if they find the sweet spot. which is why it's important to reduce those scenarios. but "bomb G1 with circuit requests until it stops handling new ones" is one that i don't know how to solve.
18:17:14 <arma4> but at least in that case your traffic only goes to G2 during the congestion attack, and you can go back to G1 when the active attack stops.
18:17:35 <ohmygodel> The adversary can force a client to use G2,G2,G2,G2 even in the proposed two-guard design. That happening by chance is low (1/2^k for k repeated circuits).
18:18:13 <arma4> ohmygodel: yep. the difference is whether the incidental traffic you decide to send to G2 anyway, during that time, helps you.
18:18:37 <arma4> and against a weak enough adversary, maybe it does help
18:18:52 <ohmygodel> yeah, arma4, and I’m not sure how much it would help
18:18:56 <ohmygodel> btw, another option that I’ll just throw out would be to allow some leakage about the guard during path selection
18:18:57 <arma4> (but why we're focusing on the weak-enough-adversary, i don't know. it's mike's netflow-only adversary.)
18:19:05 <asn> yeah i wonder how much incidental traffic can actually hide, when there is a persistent adversary with a sweet spot trying to cause a signal.
18:19:10 <syverson> arma4: is this a hoovering or targeting adversary? If the former it might. Against the latter, I doubt it.
18:19:56 <arma4> syverson: right. "move to two guards in general for all traffic" seems like we're giving up some protection against both hoovering and targeting adversaries.
18:20:01 <ohmygodel> The network could divide guards into sets sharing similar /16 and family restrictions. The the client could choose exits and middles in a way that violates no path restrictions for any guard in your set. This would limit the leakage to learning the guard set. This has the drawbacks of guard set designs in general in addition to the leakage.
18:20:27 <asn> people we approaching 90 mins. what should we do now???
18:20:38 <arma4> ohmygodel: that idea sounds related to my "make sure exits can't be guards" idea.
18:20:49 <asn> (it's 21:20 here. need to go in a bit... :( )
18:20:49 <syverson> arma4: both giving up and gaining.
18:21:22 <ohmygodel> arma4: yes, quite similar. One difference is that it could handle /16 and family restrictions, in addition to just preventing choosing the exact same relay twice.
18:21:24 <arma4> concrete next thing we can do, #1: ourselves set those guard params to 2 and find bugs. encourage others, like on tor-talk, to do it too.
18:21:32 <syverson> ohmygodel: i was trying to avoid making such a proposal while there is still a prayer of keeping things err simple.
18:22:00 <arma4> concrete next thing we can do, #2: enumerate the current situations where we rotate away from our first guard, especially noting the ones where the attacker can make us rotate away from our first guard. fix as many as we want to fix.
18:22:06 <ohmygodel> syverson: I just wanted to put the idea out there. I don’t prefer it.
18:22:13 <mikeperry> asn: do you have a patch to make NumEntryGuards behave like the consensus parms in the way we want? I misread the code earlier and didn't realize 2 meant 2,4
18:22:25 <asn> mikeperry: i have patch yes.
18:22:29 <asn> (it's trivial)
18:22:39 <asn> (but only for testing purposes. not upstream)
18:22:47 <arma4> asn: oh, so already, the 0.3.3 clients won't be doing the prop291 behavior, until we patch them?
18:22:50 <syverson> ohmygodel: I suspect something like that is the real, but way beyond the scope of this discussion, answer.
18:23:04 <mikeperry> arma4: they will, with consensus params. not with torrc
18:23:07 <arma4> oh
18:23:10 <arma4> great.
18:23:10 <asn> arma4: they will. consensus params work as intended. but local testing wont work as intended.
18:23:22 <arma4> let's get that patch into 0.3.3 if we can?
18:23:43 <arma4> so people can do testing on the new (upcoming) stable without needing to patch their tor
18:24:02 <mikeperry> we should probably also have the same directory guard behavior as consensus parms
18:24:16 <mikeperry> (which is I think what we want)
18:24:25 <mikeperry> ((which we did not discuss here :/))
18:24:31 <arma4> concrete thing we can do, #3: merge a patch to make the torrc guard options do what we meant for them to do
18:25:05 <mikeperry> asn stated that the consensus params will cause us to use the same directory guards as primary guards
18:25:26 <mikeperry> which I think is also a win for a few reasons (guard set fingerprinting, free directory cover traffic)
18:25:47 <arma4> same, as in we'd move to 2 dir guards because of it?
18:25:51 <mikeperry> so we should probably make the torrc do the same thing, if it does not already
18:26:00 <arma4> i thought there's a separate consensus param to say dirguards=3 still
18:26:17 <asn> yeah but the way primarie work, it will always prefer the primaries for dirguards
18:26:19 <arma4> and i thought the current behavior is that 2 of your 3 dir guards are also your entry guards
18:26:23 <mikeperry> asn: did you see it decide to use two dir guards, or *the same* dirguards as primary guards?
18:26:37 <asn> so if we reduce primary size to 2, it will always prefer the 2 primaries
18:26:38 <mikeperry> ah ok. I actually like that
18:26:59 <mikeperry> perhaps not as much as using middles for dirinfo but I still think it is an improvement
18:27:01 <arma4> ok. so we get the move to 2 dir guards for free. let's hope we wanted that. :)
18:27:09 <asn> hehe
18:27:26 <asn> pushed torrc branch to my github as prop291_testing . it's really trivial.
18:27:26 <mikeperry> asn: is the behavior the same for the torrc there?
18:27:30 <arma4> (the reason we picked 3 dir guards, not 2, is for the case where your 2 guards conspire to not give you the microdescriptor for relays that want you to avoid)
18:27:43 <asn> mikeperry: i think so. but i'd need to check. i'm fairly sure tho.
18:28:13 <arma4> (oh, and the case where your 2 guards are bandwidth constrained and they're responding with "503 busy" to your consensus requests. then you can't bootstrap.)
18:28:31 <asn> and i also have a branch called guard_monitor which promotes some guard-related logs to warn, so that you can more easily check guard usage.
18:28:34 <asn> in case it'
18:28:37 <asn> in case it's useful
18:28:45 <nickm> asn: Make sure these have appropriate trac tickets ?
18:28:56 <nickm> else I'll lose them
18:29:15 <asn> not sure if we need a ticket for the latter, but i'll make a ticket for the former
18:29:19 <arma4> if your dir guard responds with "503 busy", you might want to move to your next dir guard. if dir guards are entry guards now, does that mean we either can't move to a new dir guard, or we have to rotate to a new entry guard too?
18:29:23 <asn> just not now because it's late over here
18:29:49 <nickm> arma4: I believe that's handled the same way that all guard failures are
18:30:01 <nickm> it's not "rotating" -- nothing is "rotating" -- it's "going down the list" if anything
18:30:09 <nickm> guard-spec should explain ; if it doesn't, that's a bug
18:30:18 <arma4> nickm: but it's handled differently from entry guards. see the "last_dir_503_at" element
18:30:21 <mikeperry> asn: I will make a ticket for you with your branch link
18:30:28 <asn> ok
18:30:34 <mikeperry> for the torrc option one
18:30:44 <arma4> big picture: did anybody have more concrete things to add beyond the 3 i named?
18:31:23 <asn> mikeperry: i dont think that branch is ready for upstreaming btw.
18:31:38 <mikeperry> is fine. I won't set it needs_review
18:31:46 <asn> ok
18:31:49 <nickm> are the big 3 on the pad?
18:32:31 * arma4 puts them there
18:33:35 <arma4> ok now they are on the pad.
18:34:10 <nickm> ok
18:34:15 * arma4 accepts the friendly amenable from pink
18:34:20 <arma4> erm, amendment.
18:34:39 * nickm == pink
18:34:54 <nickm> unless you really meant "rotate away from" (that is, "stop using forever")
18:35:02 <nickm> s/forever/until we pick it again/
18:35:25 <arma4> sounds good
18:35:46 <asn> so next steps?
18:36:01 <asn> mike and me figure out next steps and notify the individuals involved?
18:36:11 <asn> or what?
18:36:19 <arma4> i have 3 next steps on the bottom of the pad. are those different from your next steps?
18:36:49 <asn> true. i meant more like do we meet next week?
18:37:04 <asn> but i guess we can figure it out given on how the 3 steps go.
18:37:17 <arma4> i think we should do these 3 next steps, and meeting again without having done them is not so useful
18:37:27 <asn> ok
18:37:29 <mikeperry> can I post our notes to the mailinglist? is that ok with everyone?
18:37:34 <ohmygodel> yes
18:37:34 <asn> im ok with it
18:37:37 <nickm> +1
18:37:45 <arma4> mikeperry: yes. in fact, we're in a meetingbot, so all of our words are going to a web page too.
18:37:58 <asn> im gonna close the meetingbot in a sec btw
18:38:01 <mikeperry> ok I will also provide that link on-list
18:38:23 <arma4> asn: in particular, #1 is to prove the concept that prop291 can work, #2 is to get closer to this related thing that might or might not be tied together with our prop291 choice, and #3 is to let other people help with #1.
18:38:36 <asn> right
18:38:56 <asn> ok people thanks for the meeting. you can keep talking but i gtg!
18:39:00 <arma4> i guess there could be #4, brainstorm other helpful things to move us forward, and do them as appropriate. maybe that's implicit. :)
18:39:02 <asn> imma end this!
18:39:04 <asn> #endmeeting