13:32:31 <nickm> #startmeeting
13:32:31 <MeetBot> Meeting started Wed May 27 13:32:31 2015 UTC.  The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:32:31 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:32:36 <nickm> hi friends
13:32:45 <nickm> another week it is !
13:32:46 <dgoulet> hi!
13:33:14 <nickm> I am tired from insufficient sleeping.  But let's do this!
13:33:28 <nickm> let's start with status reports?
13:33:30 <Yawning> <- tired
13:33:35 <Yawning> uh sure
13:33:40 <Yawning> I can go, since it'll be short
13:34:13 <Yawning> I poked at the DoS issues and got really depressed about burning a bunch of time to keep darknet markets up when they decided to DoS each other.
13:34:35 <Yawning> I have more ideas here (Eg rate limiting INTRO2 processing) that will increase robustness
13:34:45 <Yawning> also poked at a bunch of TLS/SSL stuff with nickm
13:35:01 <nickm> thanks about the tls stuff.
13:35:10 <Yawning> plans are, "finish flipping out about my living situation, poke at everything that needs fixing and try to make the world a better place"
13:35:12 <Yawning> np
13:35:26 <nickm> i think, if openssl takes my patches, we might be ok
13:35:27 <Yawning> I owe you review for the 1.1 branch with our new accessors
13:35:41 <Yawning> indeed, I peeked at the branches you had and they seemed sane
13:35:46 * asn here
13:35:50 <Yawning> Oh
13:36:03 <nickm> ?
13:36:06 <Yawning> I also briefly wore the Research Director hat and talked to the Astoria people
13:36:19 <nickm> yes, and thanks on that
13:36:22 <Yawning> but it looks like arma/aaron have that well in hand
13:36:37 <nickm> still though, we need more folks doing that stuff
13:36:39 <Yawning> and I am less flipping out about their code drop, and am really glad they are working on that problem
13:36:45 <Yawning> yes
13:36:55 <Yawning> I figured arma is busy, and I might as well contact them
13:37:03 <asn> nice
13:37:20 <Yawning> turned out ok, and I avoided my usual snark
13:37:21 <nickm> has anyone asked them about licenses?
13:37:22 <Yawning> >.>
13:37:32 <Yawning> neg, since it's an external process anyway
13:37:39 <nickm> hm
13:37:42 <Yawning> One thing one of us should ask them about
13:38:24 <Yawning> is "what would they like to see as far as, 'if tor would officilally support external path selection helpers, what would you want the itnerface to be like'"
13:38:37 <Yawning> since we have this grand modularization plan
13:38:37 <nickm> yeah
13:38:48 <asn> yep nice
13:38:55 <Yawning> and they basically kludged it in for their helper
13:39:02 <Yawning> they probably have insight there we can draw on
13:39:22 <Yawning> (ok, I'm done 4 reals now ;P)
13:39:45 <Yawning> (ask me elsewhere about what I mean about living situation, unless you've seen my rants already :P )
13:40:09 <asn> Yawning: where should we ask them that question?
13:40:16 <asn> Yawning: are they active on an ML?
13:40:19 <asn> Yawning: or is there a thread running
13:40:24 <asn> it seems like a question worth asking.
13:41:15 <nickm> who's next, btw?
13:41:22 <asn> i can go.
13:41:25 <asn> don't have much news.
13:41:30 <asn> also helped around with the DoS issues.
13:41:43 <asn> updated the pad a bit on the guard stuff today
13:41:46 <nickm> (the first nontrivial controller i wrote was a path selection replacement)
13:41:56 <asn> that's that :)
13:42:27 <Yawning> asn: tor-assistants@ has the thread started that has them in the loop
13:42:33 <Yawning> asn: otherwise tor-dev maybe
13:42:43 <asn> i can have some little-t-tor time this week, so if you want to me to do something i can do it.
13:42:53 <asn> my current plan is to review (parts of the) ed25519 branch of nick,
13:43:11 <Yawning> asn: I'll prolly ask for testing help/review for the rate limiter I plan to add
13:44:04 <dgoulet> ok here goes mine:
13:44:09 <dgoulet> I was afk for 3 days last week for a security conference, #16120 was opened befo
13:44:10 <dgoulet> re that, did a partial review yesterday on #12498 and will continue today if tim
13:44:10 <dgoulet> e allow it. Been studying guard stuff this morning.
13:44:18 <dgoulet> (woa wrapping..)
13:44:52 <asn> (i also reviewed #8243 and #4862)
13:44:55 <Yawning> (I still think kernel notification/polling based stuff is worth adding there)
13:45:49 <dgoulet> asn: oh didn't notice! awesome
13:47:40 <nickm> woo on everybody looking at all this stuff.
13:48:12 <nickm> so I guess it's over to me
13:48:33 <nickm> I've been distracted (again) with company stuff, but I managed to get some coding in
13:48:56 <nickm> I've written fixes to get us working with openssl 1.1 ( I hope)
13:49:15 <nickm> and I've fixed the issues dgoulet and athena found with my 12498 patch
13:49:32 <nickm> and I've chugged away at getting the link handshake part of prop220 done.
13:49:36 <nickm> (So many certificates!)
13:50:13 <nickm> also, more patches to merge all the time, and need to think about guards.
13:50:16 <nickm> and that's me.
13:50:21 <nickm> anybody else here today?
13:51:37 <asn> o.o
13:52:28 <asn> fine with moving to the guard part fwiw
13:52:46 <nickm> ok.  let's talk about guards.
13:52:59 <asn> :)
13:53:02 <nickm> we have that pad at https://etherpad.mozilla.org/HsR7ubjcUC
13:53:21 <nickm> (err, ,unless there is another discussion topic.  if so, let's do the other thing first)
13:53:25 <nickm> (this will take a while)
13:54:53 <nickm> ok, let's say it's guard time then.
13:54:57 <asn> ok
13:55:02 <nickm> (cool to see everybody so eager!)
13:55:31 <nickm> I think during 0.2.6 we got pretty close to a workable data structure and design, but kinda stepped back for stability reasons
13:55:39 <asn> there are many parts on the guard problem. maybe it makes sense to separate them into modules, and have each person think and do one part?
13:56:14 <asn> like, we could consider the prop#241 as orthogonal to the "network down" project.
13:56:38 <nickm> hmm.
13:56:56 <nickm> I kinda feel like the problem there is that any solution to prop241 needs to handle network down, right?
13:57:06 <asn> it seems so.
13:57:09 <dgoulet> yes
13:58:52 <asn> but if someone builds the network down event as a primitive, it could be used as a black box on prop#241.
13:59:06 <nickm> ah, I see
13:59:11 <Yawning> (Is that someone going to be me?)
13:59:20 <nickm> I think we need to be a little cautious about relying on network-down
13:59:26 <asn> right
13:59:28 <asn> for sure
13:59:33 <nickm> like, we can detect no-route or no-interface
13:59:54 <asn> indeed. in that case "network is down" for sure.
13:59:57 <nickm> but "firewalled upstream by a mean wifi access point" is not really detectable so immediately
14:00:03 <asn> exactly
14:00:04 <Yawning> indeed
14:00:28 <asn> we could build heuristics for captive portals. but then we are digging the rabithole ourselves.
14:00:30 <nickm> so we need to treat that kind of thing as the worst-case scenario, and handle it
14:00:35 <asn> right
14:00:46 <nickm> if there's an optimization for no-route, that's cool...
14:01:20 <nickm> ...but we need to consider whether a solution for no-route falls out of the worst-case case
14:01:55 <asn> the strawman algo i suggested for the captive portal worst case scenario is:
14:01:58 <asn> "Everytime we manage to connect to a guard, if it's not the first guard in our list, we mark all previous guards as retriable, and try from the top."
14:02:12 <asn> but this messes up lots of assumptions of prop#241, and other things.
14:02:23 <nickm> it also seems like it has an infinite loop
14:02:29 <asn> but it ensures that we (almost) always use the top guard we can.
14:02:30 <asn> yes
14:02:43 <nickm> and it seems like , if the network is really down, we try every possible guard
14:03:13 <asn> that's similar to the current behavior.
14:03:23 <nickm> sure, but it's still not good :)
14:03:30 <asn> yep
14:04:53 <asn> ok
14:04:58 <asn> maybe we should think of this worst case scenario
14:05:06 <asn> and think about what we would like to happen in the following cases:
14:05:12 <asn> - network is actually down
14:05:18 <asn> - network is up but some top guards are down
14:05:21 <asn> - we are under path bias attack
14:05:41 <asn> and see if our behavior has any common elements?
14:05:42 <dgoulet> oh good I see a nickm putting that on the pad :)
14:05:45 <nickm> - we are on a 'fascistfirewall'
14:06:08 <asn> yes
14:07:04 <nickm> also see the 'dynamic' cases I added; those are the transitions we need to handle
14:07:12 <asn> aha
14:07:13 <nickm> Are there other cases we need to handle ?
14:07:54 <asn> should we think about all these cases differnetly for cirucit guards and dir guards?
14:08:32 <dgoulet> do we keep the guard "object" if guard goes down? (for a single consensus)
14:08:45 <dgoulet> meaning what if gaurd goes down and up in 5 minutes ?
14:09:11 <Yawning> (afk ish, rage hacking)
14:10:13 <asn> nickm: we also need to think of behaviors for when the prop#241 events happen, but not sure if that section is right for this.
14:10:30 <nickm> prop241 == targetted guard dos?
14:10:31 <asn> yes
14:10:44 <asn> CONNECTED_THRESHOLD CANDIDATE_THRESHOLD etc.
14:10:59 <nickm> better add it to the list
14:11:39 <nickm> asn: dunno about handling dir and circ guards differently
14:12:13 <asn> it seems like we want to treat them differently because of the directory path bias attacks we had discussed
14:12:24 <asn> but at the same time, it would more elegant if we didn't treat them differently.
14:13:07 <asn> and also, ideally your circuit guard should also be your dir guard, so there should probably be a single list of guards.
14:13:16 <nickm> maybe it would help to summarize desired behavior in some of the cases (all?) and then figure out one algorithm that gets it?
14:13:22 <asn> aha
14:13:28 <asn> i could get behind that
14:14:27 <asn> btw, what's the problem with looping over all guards repeatedly when the network is actually down?
14:14:31 <asn> except that it's stupid.
14:14:46 <asn> is there a security issue? assuming that we manage to go back to the top guard when the network gets up again?
14:16:03 <nickm> seems noisy; seems like the kind of thing somebody smart could do something eeevil with
14:16:16 <nickm> not that  I can think of the evil thing today, but it gives me a bad feeling
14:16:22 <asn> ack
14:16:25 <nickm> (Does anybody else get a bad feeling there too?)
14:17:11 <asn> i get a bad feeling too. but can't think of better behaviors, in the absense of a reliable ntwork down primitive.
14:17:19 <dgoulet> defenitively a bad feeling for me
14:17:27 <asn> also I guess, what i should have siad is loop over CANDIDATE_THRESHOLD guards repeatedly
14:17:30 <asn> instead of the whole list.
14:17:37 <asn> using prop241 again
14:18:22 <asn> do web browsers have good network down detectors? or they suck as well?
14:18:30 <nickm> looping over candidate_threshold guards feels less bad.
14:18:36 <Yawning> asn: they probably suck
14:19:07 <Yawning> (pts/upstream proxys also complicate matters somewhat)
14:19:27 <nickm> right
14:20:07 <asn> indeed
14:21:17 <nickm> if we can handle proxies + captive portal, we can handle anything :)
14:22:24 <asn> should we treat captive protal as a different case than fascistfirewall or "netowrk is actually down"?
14:22:50 <asn> probably different than fascistfw, but quite similar to the "network is actually down" in many respects.
14:23:54 <nickm> i think it is one case of "network is down"
14:24:01 <nickm> maybe
14:24:10 <nickm> at least that's how i was thinking of it
14:24:13 <asn> yes me too i think
14:24:40 <nickm> fascisctfw is different thought. ffw looks like a filtering attack
14:25:36 <nickm> [and ffw can be an attack.  Like, one way to force people to your chosen guard is to run an access point that allows only connections to port 13337, and run your guard on that port.]
14:25:56 <asn> right
14:26:28 <asn> should we treat:
14:26:29 <asn> - network is actually down
14:26:31 <asn> and
14:26:34 <asn> - The network was up but goes down.
14:26:38 <asn> as differerent cases?
14:26:45 <asn> is the first one "WE just started Tor and network is actually down"?
14:26:53 <asn> wheras the second one happens in the middle of the session?
14:28:25 <nickm> I don't think those are different cases; the reason that I emphasized the transition is that we need to make sure any algorithm we come up with can handle the transitions
14:28:32 <asn> ack
14:29:10 <asn> i think it might be beneficial to think of these cases, and come up with ideal behaviors
14:29:12 <nickm> I wonder, are there any of those cases where the correct behavior is uncertain?
14:30:07 <asn> hm maybe
14:30:18 <asn> i imagine that more variables need to pinned down as well.
14:30:37 <asn> hm
14:31:37 <asn> nickm: we can try stating correct behavior and see what we come up with?
14:31:47 <asn> i imagine that some corect behaviors will be conflicting with each other.
14:32:52 <asn> and maybe it also depends on whether we want to optimize towards security or reachability on the correct behavior.
14:33:17 <asn> like on the ffw case, if we optimize towards reachability we just want to try more and more guards till we find one that fits through the ffw
14:33:27 <asn> but if we optimize towards security we want to enforce prop241 limits early maybe.
14:34:40 <nickm> yeah
14:34:55 <nickm> ok, we've got a framework and a start.
14:35:15 <nickm> once we know right behavior (and I'm optimistic!) we can think about what algorithm would tell it to us
14:35:21 <asn> let's think more about these cases and ideal behavior and revisit next week?
14:35:25 <asn> same time maybe?
14:36:25 <nickm> sounds good. let's try to come up with strawman algorithms though
14:36:48 <asn> ok
14:36:50 <nickm> i (perhaps wrongly) think best behavior is something we will be able to decide easily. :)
14:36:51 <Yawning> (if y'all need me to explain how to detect interface/routing table status let me know, or I can just write it)
14:37:05 <nickm> first let's make sure it's useful. :)
14:37:09 <nickm> It's cool for certain
14:37:43 <asn> from this chat, it seems like any kind of network down detector will be helpful as an optimization, but we will never actually be able to rely on it for all cases.
14:37:53 <dgoulet> fyi, I think it would be useful also for HS to have net down/up event
14:37:59 <Yawning> well, we need it for other reasons
14:37:59 <nickm> right.  but let's figure out how helpful
14:38:00 <Yawning> but yeah
14:38:13 <dgoulet> sounds good
14:38:19 <Yawning> (see the bug that spawned my netlink branch for why)
14:38:25 <nickm> yeah.  also , let's remember all the stuf we already triaged into 0.2.7.  Surely some of that is valuable :)
14:42:31 <asn> sounds good.
14:42:34 <nickm> ok.
14:42:39 <asn> i think we have a course of action for next week.
14:42:47 <asn> personally, i will try to think of ideal behaviors and strawman algos
14:42:55 <nickm> yup.  thanks!  i will try too.
14:42:58 <asn> great
14:43:07 <asn> the more hte merrier.
14:43:09 <nickm> #endmeeting