16:03:01 <asn_> #startmeeting guard-node-proposals
16:03:01 <MeetBot> Meeting started Tue Jan 19 16:03:01 2016 UTC.  The chair is asn_. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:01 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:03:28 <asn_> so the topic is prop#259, prop#241, prop#247
16:03:31 <nickm> morning!
16:03:37 <asn_> ah great
16:03:39 <nickm> good idea to start without me.
16:03:42 <nickm> I was making tea
16:03:45 <nickm> critical tea
16:03:47 <asn_> nickm: maybe you can take over for the start.
16:04:02 <nickm> okay.  So we have three guard-related proposals.
16:04:21 <nickm> Two are about "let's pick guards and connect to the network differently."  Those are 241 and 259.
16:04:33 <nickm> One is about hidden-service guard discovery in particular
16:04:43 <nickm> Let's talk about prop#241 and prop#259 first.
16:04:48 <nickm> Shall we discuss them as a unit?
16:05:01 <nickm> isis: I ping you in case you're around, since you've worked on some of this.
16:05:13 <asn_> nickm: unfortunately they are not unified yet. which is a problem.
16:05:17 <nickm> Also, I'll be linking to the discussion on tor-dev.
16:05:18 <asn_> but maybe it's worth talking about them as a unit.
16:05:32 <nickm> so meetbot is listening more than usual.
16:05:47 <nickm> I think that in the guardsim code, they are integrated-ish.
16:05:54 <asn_> ah right
16:07:40 <nickm> So, I am half-tempted to rewrite them as a unit, _based_ on the guardsim code.
16:07:55 <nickm> I believe that code specifies something in particular more than I believe that either proposal does
16:07:59 <nickm> Let me explain.
16:08:10 <asn_> hm i have not looked much at what the guardsim code specifies.
16:08:42 <nickm> I think that the steps described in prop#259 are _states_, not steps.  The client doesn't have a function called "try to find out if the network is running"...
16:09:10 <nickm> it has functions like "give me an entry node for this circuit" and "should I be building circuits?" and "I failed to connect" and "I failed to extend" etc
16:10:28 <asn_> i think that "0. Determine if the local network is potentially accessible." is a bonus step and not part of the original "algorithm".
16:10:58 <asn_> i think the steps below that are a better suited  for tor's network logic.
16:11:00 <nickm> but do you see what I mean about the original "algorithm" not being implementable per-se ?
16:11:05 <asn_> yes
16:11:54 <nickm> so, have a quick look at the "Client" class in guardsim ?
16:11:55 <asn_> in that sense, i agree that guardsim might be more helpful, than try to write tor code as a proposal.
16:12:06 <nickm> in the lib/client file
16:12:12 <asn_> sec
16:12:20 <asn_> (Gonna use https://github.com/nmathewson/guardsim)
16:12:22 <isis> nickm: i'm around
16:12:33 <isis> my internet glitched out for a second there
16:12:42 <isis> but it's better now :)
16:12:48 <asn_> nickm: im looking.
16:12:53 <asn_> """A stateful client implementation of the guard selection algorithm."""
16:13:02 <nickm> isis: wooo!
16:13:05 <nickm> isis: we
16:13:10 <nickm> 're talking about guard proposals
16:14:17 <nickm> I'm wondering whether we want to call guardsim canonical and rewrite a combined proposal based on it.
16:14:26 <nickm> First we should probably make sure we like how it acts.
16:14:47 <isis> sounds good
16:15:08 <isis> i agree that having three proposals which are all over the place is no good
16:15:42 <nickm> I think only 241 and 259 are related and prop#247 is sorta different
16:15:51 <dgoulet> 241 could be easily merged in 259 tbh
16:15:56 <asn_> I agree that 241 and 259 are mergable.
16:16:35 <asn_> and maybe 247 should be renamed to "Hidden service usage of guards" or something that specifies how to apply the 241/259 logic in the hidden service scenario.
16:17:13 <dgoulet> but regardless of guardism, we should maybe discuss the proposals themselves that is is there still some issues or uncertainty (for 241/259)
16:17:20 <asn_> i'm not sure currently what's the difference between guardsim and 259.
16:18:15 <asn_> dgoulet: i don't like how the dystopic list and the utopic list are completely disjoint. it seems weird to throw all the 80/443 relays out of the network and only use them as a last resort for people behind fascist firewalls.
16:18:18 <dgoulet> for instance, I share the concern with asn_ on the disjoint set of dystopic and utopic
16:18:21 <dgoulet> asn_: ahah
16:18:39 <mikeperry> the final result should be agnostic about the data structures involved. also I think we should turn the 'Uptopia vs dystopia' terminology into being specifically about port-based firewalls.. otherwise it drags in the bridge problem (which I think is much simpler: Tor failed to bootstrap. you need bridges)
16:19:02 <mikeperry> asn_: +1
16:19:16 <dgoulet> datapoints (I just ran): Dystopic set would have 769 nodes and Utopic set would have 1189 nodes for a total of 1958 Guards
16:19:22 <isis> i have some uncommitted guardsim code here… two seconds
16:19:46 <isis> one of the things is an easy way to play with whether UTOPIC_ and DISTOPIC_ are disjoint
16:19:59 <isis> i think i agree with asn that they should not be disjoint
16:20:04 <nickm> +1 to that
16:20:11 <dgoulet> consensus woot
16:21:58 <dgoulet> ok moving on, so what's the reasons for choosing the Consistent Hashring design in there?
16:22:05 <asn_> not sure how 259 would work if they are not disjoint. i think that would require a slightly different proposal.
16:22:23 <asn_> since the whole logic currently  depends on GUARDLIST_FAILOVER_THRESHOLD.
16:22:34 <isis> so, if they are not disjoint, we want UTOPIC_* to include nodes on 80/443
16:22:47 <isis> but then what do we want DYSTOPIC_* to include?
16:22:47 <nickm> I'm not sure I understand what the consistent hashring is _for_
16:23:31 <asn_> isis: maybe all the 80/443 nodes that have not been tried yet?
16:23:34 <isis> the consistent hashring was an attempt to bring in guardset features
16:23:56 <asn_> isis: so if you try an 80/443 node as part of the utopic list, you won't try it as part of the dystopian list. or sth.
16:24:37 <nickm> what "guardset" features are we talking about?  Or let's wait till we figure out how to make things nondisjoint
16:24:40 <nickm> (joint?)
16:25:01 <isis> asn_: all of them?  even outside the chosen guardset?  so if we detect a dystopic network, we switch to not using the guardsets?
16:26:30 <isis> for the guardset features, the idea was that the client should only ever attempt to use guards that are some portion/percentage of the network.  so rather than choose some random subset each time, there should be some deterministic way to determine which is the set of nodes you should potentially try, and never try anything outside that set.
16:27:08 <asn_> hm not too familiar with this guardset feature. what security does it offer?
16:27:17 <isis> *inside that set*, a client then separates things into UTOPIC_ and DYSTOPIC_
16:27:58 <asn_> ah i see. maybe you can get a different deterministic list for the MAC of each wifi router or sth.
16:28:20 <mikeperry> so, you can get the same type of determinism with a sorted list and using Hash(client_info) % total_bandwidth in place of the current random() % total_bandwidth
16:28:27 <isis> asn_: currently a client can try every node in the network before finding a "suitable" guard, which allows an adversary to deny access to all others until the client chooses the adversary's guard
16:28:37 <mikeperry> you don't really need a hashring for this
16:28:57 <mikeperry> maybe Hash(client_info | probe_number) % total_bandwidth, for multiple tries
16:28:58 <nickm> so, what kind of "deterministic" do we want in the presence of changing network?
16:29:30 <isis> mikeperry: yep, that latter one is basically how it works
16:30:05 <mikeperry> yeah, that property can be had with any ordered data structure, I think
16:30:11 <zookolaptop> That sounds quite similar to the deterministic permutation we use in Tahoe-LAFS.
16:30:30 <asn_> hello zooko :)
16:30:37 <asn_> how do you use that data structure?
16:30:43 <isis> nickm: personally, i think that having different guards for different APs/networks is a good idea, since it reduces a global passive adversary's ability to track the physical location of users as they e.g. move from home to a café
16:31:00 <nickm> err, I mean "in the presence of a changing _tor_ network"
16:31:01 <isis> zookolaptop: hi!
16:31:13 <zookolaptop> asn_: this is for Tahoe clients to choose a subset of the Tahoe storage servers.
16:31:37 <nickm> isis: I mean, one option would be to just generate and store the whole guardset the first time they start up.  It's not too big.
16:31:40 <mikeperry> I think both properties (deterministic guard selection, and data structure choice) are independent to the behavior of how you react when certain things are unreachable
16:31:58 <zookolaptop> asn_: I suspect the goals of the algorithm are kind of similar between that need in Tahoe and this need in Tor.
16:32:01 <isis> nickm: ah, i see what you're asking.  the consistent hashring allows for minimal "shifting" changes to a client's chosen guardset as nodes go up/down.
16:32:36 <isis> nickm: storing it is also possible, and perhaps easier.  i would not be opposed to that route, i think.
16:33:26 <mikeperry> ah, the shifting-resistence property is not maintained for a sorted list
16:33:33 <isis> zookolaptop: is the Tahoe algorithm documented somewhere?
16:33:43 <isis> mikeperry: right.
16:34:01 <isis> mikeperry: nor for just storing the guardset in the statefile.
16:35:06 <isis> but if that is not a property we care about, and we are willing to loosen the "you'll only ever connect to X% of the network" promise… then we could store it in the statefile and/or just use a sorted list.
16:35:56 <isis> is this something we care about?
16:36:16 <nickm> not sure
16:36:17 <dgoulet> hrm, keep in mind that with prop241, we end up with restricted guard-sets (connected-to, tried-connect) and because of the threshold there (CANDIDATE_THRESHOLD for instance) so seems we'll have small list kept in the state-file and/or changed very little at new consensus no?
16:37:14 <asn_> i'm not sure i understand the consequences of this shifting thing. :(
16:37:40 <asn_> i'm also not sure if I like this deterministic thing. who would use it? and what is client_info?
16:37:41 <dgoulet> in other words, dystopic/utopic set are potentially built not very often in most case
16:37:44 <nickm> So, the thing I wanted to bring up next is that we have this simulator, and we have a set of scenarios we want to simulate with it... but we don't have simulation results.
16:37:57 <nickm> We even have a list of scenarios that we want to simulate and make sure we withstand well.
16:38:03 <nickm> (in doc in the guardsim repository)
16:39:01 <zookolaptop> isis: yes. I'll look for docs...
16:39:15 <asn_> nickm: i see where this is going.
16:39:38 <mikeperry> such a hash ring requires O(bw_differential_resolution*num_routers) memory storage, for each network subset.. so if the slowest guard is 1000X slower than the fastest guard, then we're talking about 1000*1189*256/8 = 38M of hashes for the Utopic set, and 1000*769*256/8 == 25M of hashes for the dystopic set
16:40:24 <nickm> seems ouchy.
16:40:30 <mikeperry> no more running tor clients on raspi's/openwrts with that, I think
16:41:07 <asn_> #item Write actual simulations for simguard.
16:41:18 <asn_> so this seems to be one TODO item ^
16:41:21 <asn_> (if that even works)
16:41:48 <asn_> to better understand which algorithm we want.
16:42:13 <isis> mikeperry: okay, that's a good argument against it.
16:42:16 <mikeperry> I guess we only would need to store a hash prefix big enough to represent 1000 routers.. maybe.. unless we care about future collisions as the network changes
16:42:52 <nickm> Also, "write simulation for guardset designs"  ; I think guardsim doesn't contain those yet.
16:43:14 <nickm> Are there any missing cases in guardsim/doc/stuff-to-test.txt ?
16:43:15 <isis> mikeperry: the hash prefix length chould be chosen based on the number of nodes with the guard flag in the network
16:44:19 <asn_> maybe we should start moving to prop247 somehow...
16:44:48 <nickm> before we do .. anybody love any of these tasks we've been talking about enough to say "yes, I want to do that!  Like, this week!"
16:44:51 <zookolaptop> isis: https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/architecture.rst#server-selection
16:45:10 <dgoulet> nickm: hrm one maybe case is mising is changing network that is wifi internet -> VPN -> new wifi -> VPN
16:45:23 <dgoulet> nickm: which is 99% of my laptop use case and I use lots of guards because of that ^
16:46:35 <isis> zookolaptop: thanks, i'll take a look
16:46:52 <nickm> dgoulet: could you give me a patch for that document?
16:46:57 <dgoulet> nickm: sure
16:47:21 <nickm> I am hearing nobody jump to say "Me !  Me!  I want to!"  So I'll see what I can do, and make tickets for everything we did an item for
16:47:29 <nickm> #item make tickets for all other items
16:47:36 <nickm> #action nickm will make tickets for all other items
16:47:37 <mikeperry> evern with 2 byte prefixes, we're still talking like 5M of memory overhead for the hashrings. still kinda a lot for things like netaid/openwrt
16:47:49 <nickm> #item extend guardsim to handle guardsets
16:47:58 <nickm> #item revise proposals to more clearly match guardsim
16:48:11 <nickm> #item describe re-joined u/dys-topian sets
16:48:32 <nickm> anything else open or are we ready to move on to 247?
16:49:49 <asn_> i feel that this deterministic guard picking adds lots of complexity to the proposal (hashrings? shifting?) and im not sure if anyone would use it.
16:49:54 <asn_> but anyway
16:50:01 <asn_> i think we should start atlking about prop247
16:50:33 <asn_> because assuming that we make a beautiful prop259  and we use it for the tor client's first hop.
16:50:40 <asn_> we still don't know how to apply this to hidden services.
16:50:43 <asn_> and that's what prop247 should bee about.
16:50:55 <nickm> ok
16:50:58 <dgoulet> +1 moving to prop247
16:51:16 <asn_> so as prop#247 currently stands
16:51:17 <zookolaptop> mikeperry: could you explain like I'm missing something, why you have to store O(num_routers * XYZ), instead of just O(num_routers)?
16:51:29 <asn_> it suggests to move to an architecture
16:51:32 <zookolaptop> Don't you just get a set of all routers, and then *permute* that set one time, and then use the resulting permuted set?
16:51:40 <asn_> where we have a single layer-1 guard.
16:51:53 <asn_> and then four layer-2 guards.
16:52:02 <asn_> and then foreach layer-2 guard, we have four binned layer-3 guards.
16:52:07 <mikeperry> zookolaptop: for load balancing, we'd need copies of each router that is proportional to its bw
16:52:20 <asn_> for a total of 21 guards.
16:52:37 <zookolaptop> What's a bw?
16:52:49 <mikeperry> a bandwidth
16:52:56 <asn_> it's really unclear how we would use the prop#259 algorithm to support all these different layers of guards of prop#247.
16:52:57 * zookolaptop struggles to understand.
16:53:13 <zookolaptop> Is this for a client? So each client needs to have a view of approximately-all-possible routers?
16:53:27 <zookolaptop> Sorry if I'm too far behind and should just drop out of this conversation and catch up off-line.
16:53:44 <nickm> asn_: It sounds to me that the best way to do that kind of algorithm would be to have a notion of "There are N paths you can use".
16:53:48 <nickm> for hidden services.
16:53:53 <nickm> Not sure how great that idea is.
16:54:18 <asn_> not sure how that would work.
16:54:35 <mikeperry> zookolaptop: yeah, if you haven't read https://gitweb.torproject.org/torspec.git/tree/proposals/259-guard-selection.txt#n191, you should. it explains it
16:55:35 <asn_> one of the problems with prop247 is that the layer-1 guard requires a guardset of its own. the layer-2 guards probably require a guardset of their own as well. and each layer-3 set of guards also requires a guardset.
16:55:38 <nickm> asn_: well, if you have 1 entry, 4 middles, and 4 thirds for each middle, you have 1 * 4 * 4 paths.
16:55:41 <nickm> right?
16:56:09 <asn_> yes
16:56:34 <mikeperry> that might simplify an implementation, but right now the path positions have different rotation periods though..
16:56:50 <dgoulet> I have a bunch of questions about that ^
16:56:53 <mikeperry> because we wanted to force at least one sybil attack, and either a very long wait, or a node compromise attack
16:57:28 <mikeperry> so the adversary has to do two different types of detectable attacks
16:58:19 <nickm> hm.
16:58:33 <nickm> ok, that makes sense
16:59:13 <isis> so perhaps we should extract some concept of guardsets that works for both prop#259 and prop#247?
16:59:29 <asn_> isis: yes maybe.
16:59:42 <asn_> although we need to decide if the layer-2 guards will also use a guardset, or they will be handled differently.
16:59:50 <asn_> i think mikeperry said that only layer-1 guards should use a guardset.
17:00:01 <zookolaptop> mikeperry: I see. Thanks.
17:00:02 <mikeperry> I think the uptopic/dystopic guard lists should be built like every other node selection list
17:00:03 <asn_> and if a layer-2 guard drops, we just forget it.
17:00:14 <mikeperry> it doesn't need custom guard-specific code
17:00:17 <isis> from what i understand, prop#247 requires the set to 1) have X number of nodes, and 2) have a rotation period associated with it
17:00:33 <mikeperry> in fact, ideally it would use the same data structure as we use for choosing a random middle hop and exit hop
17:00:49 <s7r> hello meeting. catching up. just a fast observation I want to add myself on the list for pro join list for utopic and dystopic. I suggested something 2 months ago: https://lists.torproject.org/pipermail/tor-dev/2015-November/009871.html
17:00:52 <isis> and prop#259 requires the set to have X% of the total network bandwidth represented in the set
17:00:55 <zookolaptop> I think you can get the load-balancing you want with O(num_routers) storage, with a stateless monte-carlo-style algorithm.
17:00:58 <mikeperry> however, the prop#247 lists need to stay in the state file for a very long time
17:01:38 <asn_> mikeperry: that data structure will need to be kept after reboot though. this is not the case currently. that requires new code.
17:01:41 <zookolaptop> Instead of inserting weak node once and strong node ten times, insert them each once, and when you come to weak node, flip a 10%-weight coin (or maybe that's the wrong number, but you get the idea).
17:01:52 <zookolaptop> And so 10% of the time you take weak node and 90% of the time you pass it over.
17:02:42 <isis> mikeperry: also the data structure is currently pick_middle_node() which just selects randomly from an unsorted list, so that won't work to limit the number of guards connected to.
17:02:43 <dgoulet> I want to clarify something, third-guard-set rotates every ~12 hours, ofc you won't tear down the circuit using them but then a node in that circuit can show up in a set of another path, are we OK with 3rd layered guard being used in between paths?
17:03:12 <asn_> dgoulet: yes that's another thing that needs to be figured out.
17:03:15 <dgoulet> (which could require more intelligent guard node pick for guardset)
17:03:19 <asn_> dgoulet: is it OK for layers to share nodes?
17:03:36 <asn_> dgoulet: we really don't want to have the layer-1 guard be the same as the layer-2 guard, so probably not.
17:03:43 <dgoulet> yeah so this ^
17:03:44 <asn_> but maybe it's OK for layer 3?
17:03:46 <dgoulet> is that we want
17:04:06 <dgoulet> but then I can open RDV circuit all day for 90 days and enumerate a lots of guard inthe third set
17:04:29 <dgoulet> and ultimately _maybe_ coming up with 3 guards that are not in those sets (rotating every 12 hours) and blam I get guard or layer 1 and 2
17:04:34 <asn_> right
17:04:36 <asn_> that's true.
17:05:05 <asn_> we need to be smart about which nodes we exclude in each layer.
17:05:09 <dgoulet> so 1) i think it's OK to share nodes between bin on layer 3
17:06:21 <dgoulet> yeah my 2) was the smart part ^, maybe a subset of guards for layer 3
17:06:44 <dgoulet> like 100 and you rotate over them and you can change those when layer 2 as rotated or something
17:08:00 <isis> what is the timing for layer 2?
17:08:09 <asn_> mean of 11 days.
17:08:28 <asn_> from 0 to 33 days or something i think.
17:08:30 <nickm> so what does this design actually achieve in terms of improved security?  And can we quantify that so that we can figure out which choices in this space give the best results?
17:08:33 <asn_> at least with the current parameters which are probably due to change.
17:08:54 <asn_> nickm: i think we can quantify it to some degree.
17:08:55 <isis> dgoulet: so… your idea is that layer 3 should be force rotated whenever layer 2 rotates?
17:09:21 <asn_> nickm: the easiest way to quantify it is that currently to deanon a hidden service, you need a sybil attack (guard discovery) and a compromise attack (own the guard).
17:09:22 <dgoulet> isis: possible... but most important I think when they rotate, we shouldn't consider _all_ guards but a subset
17:09:46 <asn_> nickm: what we are trying to do is to push it to a much harder sybil attack (break layer 3), and then two compromise attacks (layer 2 and layer 1).
17:09:55 <dgoulet> isis: and then change that subset of guards that we can pick for layer 3 when let's say layer 2 rotates also (untested unproven idea)
17:10:42 <isis> dgoulet: right, i agree (also agree for prop#259)
17:10:57 <asn_> nickm: another thing we would like to optimize in this proposal, is to rotate layer 2 in the right time, so by the time the adversary has finished sybiling layer 3, layer 2 is about to rotate.
17:11:31 <nickm> is breaking layer 3 really a hard sybil attack?  I don't get it. :/
17:11:51 <asn_> it's a sybil attack against a node that rotates every 12 hours or sth. it should take a week or so.
17:11:56 <asn_> currently it takes an hour.
17:12:07 <mikeperry> dgoulet: does this new subset idea mean that it would be safe to use Guard-flagged nodes for layer2 and layer3?
17:12:08 <asn_> so it is harder. not very hard though.
17:12:47 <asn_> "currently it takes an hour". i mean that a guard discovery attack now is instant.
17:13:36 <nickm> so is that really harder?
17:13:41 <mikeperry> yes
17:13:45 <dgoulet> mikeperry: I think so yes actually I think you said it in the proposal, we should either use all Guard nodes to the rdv point or none for 2nd and 3rd
17:13:56 <mikeperry> it is now a function of c/n instead of instant
17:14:29 <mikeperry> there are tables in Section 3.2.1 that specify the number of rotations for layer3 before a given probability of Sybil success
17:14:43 <mikeperry> for 3 different c/n percentages (1%, 5%, and 10%)
17:14:54 <asn_> if we build this or a simulator of it, we could potentially increase the layer3 rotation period if we find that the perofrmance is acceptable.
17:15:44 <asn_> i think all the constants will be tweaked based on experimental evidence. but the current ones seem sensible for now.
17:16:32 <asn_> (also we are 15 minutes past the next hour)
17:16:38 <mikeperry> well, we also want layer3 to tned to rotate quick enough that you can't expect to pop/seize 1 box and get useful info. but that is based on just guesses, though
17:17:18 <dgoulet> mikeperry: just to be clear, since layered guard a disjoint, and layer 1 doesn,t change after 90 days, we can exploit the fact that layer 3 rotates so fast that we can build a big list of guards that are not layer 1 (for 90 days I get to 2880 guards but duplicates possible ofc!)
17:17:26 <mikeperry> that's why I used max(X,X) for the layer3 distribution, to make it have a longer mean, but still have a narrower range of hours
17:20:03 <mikeperry> dgoulet: yes, that is why we specified no Guard-flagged nodes for layer2+layer3. but if I understood your other point for layer2 vs layer3 discovery, you are thinking that subsets for each layer helps defend it instead, meaning that with those subsets, we could now once again use Guard-flagged nodes for layer2 and layer3 (but maybe not the RP still)
17:20:54 <dgoulet> mikeperry: yes basically, that's the theory
17:21:35 <nickm> so if we want to quantify the goodness of this design, it should be "effort until HS located" with effort a function of the design, and of the difficulty of a sybil, and of the difficulty of a compromise?
17:21:54 <asn_> nickm: yes pretty much
17:22:07 <mikeperry> that does seem cleaner.. if only we didn't have to special-case the RP. we might also need to think a little bit about long-term inference for people who hardcode a guard, or if the first layer guard rotation increases more, etc
17:23:34 <mikeperry> dgoulet: ^ (that was to you)
17:23:38 <asn_> nickm: we have "3.1. Threat model, Assumptions, and Goals" trying to do this kind of
17:24:01 <dgoulet> mikeperry: yes, I'm thinking about all this ehhe
17:24:06 <isis> so the way in which these HS guardsets are chosen… this is going to be like random.choice(getAllNodesWithoutGuardFlag()) ?
17:24:29 <asn_> isis: we probably also need to exclude some nodes for each layer.
17:24:30 <isis> and do that 1/4/4 times for each layer, for each period?
17:24:42 <asn_> isis: so for layer 2 we want to exclude the layer 1 guard probably.
17:24:45 <s7r> dgoulet: asn_: sorry if this is stupid. What if the attacker tries to establish circuits with every non guard relay as the rdv point, and builds a list of which fails, assumes are layer 3 guards?
17:24:48 <isis> right
17:25:45 <asn_> s7r: plausible.
17:25:50 <dgoulet> s7r: circuit failling, you could assume the node is somewhere in the path but then maybe the HS could choose another path since with that proposal we have plenty more
17:25:55 <asn_> s7r: the attacker could also set herself as the RP and harvest layer 3 guards.
17:25:58 <s7r> might not be such a short list but still
17:26:11 <dgoulet> yeah what asn_ said is much more efficient :)
17:27:00 <asn_> fwiw, i plan to work on this proposal these days.
17:27:19 <asn_> what i plan to do, is to assume a basic interface from prop#259 and then see how this could be used in prop#247
17:27:56 <asn_> and also think about all the various concerns mentioned in this meeting and elsewhere.
17:28:05 <isis> so layer 3 also needs to exclude the layer 1 guard, because (as currently coded) the layer 2 won't connect forward to the node behind it in the circuit
17:28:08 <dgoulet> very nice asn_
17:28:24 <dgoulet> isis: yeah all layer guards are disjoint right now
17:28:30 <dgoulet> +set
17:28:33 <isis> ok
17:28:51 <asn_> but that's a problem as dgoulet pointed out. since by monitoring guardset layer-3 you can infer details about layer-1.
17:28:59 <asn_> so ?.?
17:29:16 <dgoulet> fun problems! ^
17:29:20 <isis> hmm
17:29:22 <dgoulet> to fix*
17:30:58 <isis> asn_: by "basic interface", do you already have an idea of what functionality you need?  would you be able to note down needed functionality somewhere?
17:31:51 <asn_> isis: hmmm not exactly yet.
17:32:36 <asn_> i was imagining something like: guardset_layer_1 = Guardset(nodes_to_consider, rotation_period_max, flags, exclude_nodes)
17:33:04 <asn_> and then guardset_layer_2 = Guardset(nodes_to_consider, rotation_period_max, flags, guardset_layer_1)
17:33:06 <asn_> or something.
17:33:10 <nickm> interesting
17:33:11 <asn_> but i really don't know the interface yet.
17:33:28 <nickm> I think we can do something pretty neat here with this kind of stacked-abstraction thing
17:33:29 <asn_> ah also n_guards should be an argument too.
17:34:36 <asn_> nickm: what do yoiu have in mind?
17:34:55 <isis> will the notion of guardsets used in prop#259 work for prop#247?  in particular, i'm confused about how the difference between having a hardcoded number of nodes in a set, and having some X% of total_bw in a set, is going to work out cleanly in the interface.
17:36:03 <asn_> isis: i am not sure actually.
17:36:27 <isis> we could have a Guardset type, with subtypes which populate either by {hardcoded number, bw percentage}
17:36:32 <nickm> asn_: The ideas you've been talking about with basing a revised 247 on a revised 259
17:37:01 <asn_> isis: possible.
17:37:11 <isis> this works so much easier in my head in C++… :/
17:37:40 * isis shuts up about that
17:38:01 <asn_> isis: we need to think more about that _for sure_
17:38:41 <asn_> isis: also, if we use prop259 guardsets for the second layer of guards of prop247. this means that a guardset can have more than one active guard (since layer2 has 4 guards)
17:39:10 <isis> should i separate the guardset stuff into a new proposal?
17:39:14 <nickm> So we have any action-item-type things to say about 247 ?
17:39:31 <isis> that way we can say both prop#247 and prop#259 depend on prop#XXX
17:40:07 <asn_> isis: maybe i'm not using the guardset terminology correctly. when I refer to guardset I refer to the final product of prop259.
17:40:26 <asn_> nickm: i think prop247 should be revised and have a fat section about how it works on top of prop259
17:40:50 <asn_> nickm: and _maybe_ prop259 should have some sort of formal interface that prop247 can use. but that might be too much effort.
17:42:13 <asn_> nickm: im planning to work on prop247 (and also on prop259 as a side effect) but i won't be able to do all the things.
17:42:34 <asn_> mikeperry has been super helpful on this, so maybe we can continue working together on prop247
17:43:12 <mikeperry> yeah, when you think prop#247 is ready enough to mock-up in txtorcon, I am down to do that
17:44:13 <asn_> mikeperry: i think implementing parts of prop247 could be useful even now. to get an idea of the performance that we should expect.
17:44:40 <asn_> i expect some parts of prop247 to change and some others not.
17:44:58 <mikeperry> ok, I can play around with it soon then, hopefully
17:45:07 <asn_> in general, i expect the three layer concept to remain in the future.
17:45:26 <asn_> the way these three layers rotate, and interact with each other (by excluding nodes, or meshing up) might change though.
17:45:38 <asn_> but who knows.
17:45:45 <asn_> this seems like another huge amount of work.
17:46:23 <nickm> well, one step at a time.
17:46:26 <asn_> nickm: maybe we should stop this meeting for now? :)
17:46:49 <nickm> Let's do that.  First, should we figure out some report-out format, or should we just send a link to the meetbot notes?
17:47:17 <asn_> hm
17:47:26 <asn_> i will itemify the prop247 discussion for my own sake
17:47:36 <asn_> maybe i could do the same for prop259?
17:47:39 <asn_> and send it out to tor-dev?
17:47:44 <asn_> maybe tomorrow? :)
17:48:27 * asn_ has love and hate relationship with the guard subsystem
17:49:37 <isis> #action isis will double check the guardsim code and figure out what changes have/should been/be made w.r.t. prop#259 and push the changes
17:49:48 <isis> after that i will revise prop#259
17:49:53 <nickm> Okay, excellent.  I'll make the tickets for 259, and see where we stand
17:50:02 <nickm> Anything more?  Else I #endmeeting in a moment
17:50:12 <nickm> or does the meeting-starter need to end it?
17:50:17 <isis> #item separate guardset data structures in prop#259 into a new proposal
17:50:25 <asn_> i think i need to do it
17:50:31 <asn_> i can do it when isis finishes #iteming
17:51:13 <isis> #action isis will separate guardset stuffs from prop#259 into a new proposal, and mark prop#247 and prop#259 as depending on it
17:51:24 <asn_> isis: btw what is guardset stuff?
17:51:33 <asn_> isis: and what's the difference from prop259?
17:51:46 <asn_> (seems stupid to ask this after this whole meeting)
17:52:15 <isis> i though prop#259 was supposed to be about *how* one picks a guard, not how one picks a guardset
17:52:16 <asn_> i thought guardset is the result of prop259. a bunch of guards with a bunch of methods on how to use them and rotate them.
17:52:21 <isis> but currently it is about both
17:52:26 <asn_> isis: i see
17:52:50 <asn_> i think these two topics can fit in a single proposal, no?
17:52:54 <isis> i could not separate them, if we think that they go hand-in-hand
17:53:03 <isis> okay, nvm then :)
17:53:06 <asn_> we could decouple them. but i think that might just make us remember more proposal numbers
17:53:26 <isis> ack, it's less work for me to keep them together, so
17:53:30 <isis> i'll just keep them together
17:53:34 <mikeperry> I think the only thing that should be decoupled is the data structure recommendation
17:53:35 <asn_> .ack
17:54:14 <isis> mikeperry: yes, that is the part i was going to decouple, but now we're not going to decouple it
17:54:16 <mikeperry> or moved to an appendix as an option. I don't really like it as an option though, and it kind of distracts from the idea by confusing the properies of the specific data structure with what we really want
17:54:48 <isis> revise it if you want?
17:55:01 <isis> :)
17:55:03 <asn_> yes appendix seems fine.
17:55:04 <mikeperry> rather than saying "do this thing", maybe say "we want these 2 properties for sure, and these other two might be nice. here's a data structure that has just the first two, and hashrings have all four, but are memory-expensive" or something
17:55:13 <asn_> i might end up doing it when i re-read prop259.
17:55:16 <isis> okay, i'm done with my #iteming
17:55:20 <asn_> great
17:55:21 <asn_> i'm ending this.
17:55:22 <mikeperry> I am confused by Prop#259. it was not clear to me which lists are supposed to persist or not
17:55:29 <mikeperry> partially because of this datastructure problem
17:55:39 <asn_> it's the end~~~
17:55:41 <asn_> #endmeeting