13:31:14 <nickm> #startmeeting
13:31:14 <MeetBot> Meeting started Wed Jan 21 13:31:14 2015 UTC.  The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:31:14 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:31:16 <nickm> ohai!
13:31:18 <nickm> who's here?
13:31:37 <nickm> (could be a short meeting if it's just me this morning...)
13:32:46 <nickm> I'll give it another 10-15 minutes...
13:39:33 * teor is here, technical issues
13:39:40 <nickm> hi, teor!
13:39:47 <nickm> It looks like it might be just you and me this morning :)
13:40:54 <nickm> how's it going?
13:41:07 <nickm> personally, I'm hoping I can get a bit more hacking done this week, and take the weekend off.
13:41:13 <nickm> I'll see if circumstances cooperate.
13:43:57 <teor> I have got absolutely no hacking done this week
13:44:08 <teor> The anticipated disruption happened then more happened then...
13:44:19 <teor> So maybe this weekend there will be hacking
13:45:22 <nickm> remember, hacking is fun. :)
13:45:36 * dgoulet here!
13:45:37 <teor> Yes, which is why I regret not having time to do it
13:45:59 <nickm> For me, I've got meetings and communication this morning, after which I'm going to try to force myself to calm down and hack.  Then, in the office all day tomorrow.  Then, a short day friday
13:46:09 <nickm> hello dgoulet!
13:47:51 <teor> hi dgoulet
13:48:04 <nickm> I'm going to prioritize testing, mgetting things merged, and getting guard-related issues resolved.
13:48:07 <dgoulet> teor, nickm: hello! and also Yawning ! :)
13:48:07 <nickm> hi Yawning !
13:48:08 <nickm> hi toralf !
13:48:09 <teor> Well, the crew is here...
13:48:38 <Yawning> I'm still half asleep
13:49:06 <dgoulet> right, I have to day #9682 and #13339 to review (which are rather big), will also sit on some phone calls for the pm thing
13:49:40 <toralf> nickm: hi
13:49:53 <dgoulet> nickm: please direct me anything that you think should be reviewed asap
13:50:02 <asn> hello i'm also around
13:50:03 <dgoulet> (or need patches)
13:50:07 <dgoulet> asn: o/
13:50:44 <asn> mainly going to be working on SponsorR PM stuff this week.
13:51:01 <asn> and also uni stuff.
13:51:13 <nickm> asn: ok.  Do we have a plan right now for guardiness branches and "freak out if guards go away" ?
13:51:21 <asn> hm
13:51:29 <asn> guardiness branch needs some more fixes.
13:51:31 <nickm> My sense is that I should be trying to get your branches merged for the former, and trying to do an implementation for the latter
13:51:46 <asn> i need some more feedback from teor, and I will fix them soon.
13:51:55 <asn> it will happen soon.
13:52:02 <asn> now, on the "freak out" ticket.
13:52:07 <asn> i posted my thoughts in the last two comments.
13:53:01 <asn> an implementation doesn't seem very hard technically. but we will need to be careful about edge cases (directory guards, etc.) and also it will need to get lots of testing from people with different tor use cases.
13:53:02 <nickm> If I'm understanding right, your sense is that it's going to be harder than I think to get this right?
13:53:07 <nickm> hm.
13:53:15 <asn> nickm: let me suggest
13:53:18 <asn> you set up your tor
13:53:23 <asn> to log your guard usage
13:53:27 <asn> and check the logs for a few days
13:53:36 <asn> i can give you a branch if you want
13:53:40 <asn> that will do this for you
13:54:03 <asn> i think this will give you a good idea of the situation. that is, how directory guards influence the guard list, etc.
13:54:47 <nickm> hm.
13:55:03 <nickm> sure, upload the branch someplace.
13:55:08 <asn> ok
13:55:13 <asn> i will try to do this tomorrow.
13:55:26 <nickm> I wonder if you have some idea of what exactly the algorithm _would_ look like, if we were going to build in an advisory version now.
13:55:47 <nickm> I have a feeling that everybody but me has a solid notion of what the proposal actually _is_ :)
13:55:58 <nickm> If that's not the case, then I'd love to know, so I can try to make one up. :p
13:55:59 <asn> heh
13:56:22 <asn> let's see..
13:56:35 <asn> the simple version would be to find the right place in the code where direct connections to guards are happening
13:56:43 <asn> and every time we connect to a new guard, we increment a counter.
13:56:54 <asn> if the counter is over THRESHOLD, we warn.
13:57:04 <asn> now, the problem is finding The Right Place.
13:57:17 <asn> I candidate is entry_guard_register_connect_status() .
13:58:30 <asn> however, there are a few caveats that I mentioned in the ticket.
13:58:54 <asn> namely, that directory guards are causing lots of connections to guards that are not on the top of the list.
13:59:05 <nickm> hm.  Why is that?
13:59:08 <nickm> Do we know?
13:59:11 <asn> yes
13:59:19 <asn> it's because we have NumDirectroyGuards = 3
13:59:34 <nickm> ah.
13:59:41 <nickm> well then.
13:59:42 <asn> so our guard algorithm will walk our guard list till it finds 3 guards that can be used as directory guards
14:00:04 <asn> and not all guards can be used as directory guards.
14:00:33 <asn> and sometimes a guard will be down, and it will be skipped, and our algorithm will go even deeper in the guard list and return guards even more down in the list.
14:01:08 <asn> it might be fine to ignore directory guarsd for the purpose of that ticket.\
14:01:33 <asn> because they are not very good at launching end-to-end correlation attacks, which this ticket is trying to prevent.
14:01:36 <asn> but I'm not sure about this yet.
14:03:15 <asn> as an example, over the past two days I have used 2 circuit guards. and 7 directory guards.
14:05:21 <asn> i haven't had much time to think how to make this work.
14:05:36 <nickm> ok.  I'm going to try to stare at it and see if I make any progress.
14:05:39 <asn> i've only had time to think of ways that the simplest approach might fail.
14:05:50 <nickm> Is this on a reliable or an unreliable connection that you have been testing?
14:05:53 <asn> and i'm not going to have much time this week, but the next week might be better.
14:06:08 <asn> nickm: it's a reliable connection. in an unreliable one the situation would be worse.
14:06:56 <nickm> ok
14:07:05 <nickm> I'll try to experiment with different approaches and see if I find anything out
14:07:09 <asn> ok
14:07:55 <asn> entry_guard_register_connect_status() is a useful function to count circuit guards.
14:08:07 <asn> directory_initiate_command_routerstatus_rend() is a useful function to detect connection directory guards.
14:08:11 <asn> *to dir guards
14:08:24 <asn> gl hf
14:08:35 <nickm> I'll try :)
14:08:40 * asn goes back to uni work
14:09:03 <nickm> anybody else want to pay attention to this issue?  It's  a potential security improvement, and possibly quite valuable if we  can get it int0 0.2.6
14:09:06 <nickm> into
14:09:37 <dgoulet> I would gladly help the way I can
14:09:43 <Yawning> I'll review the branch?
14:09:48 <nickm> ok.  are you up to speed on the ticket?
14:09:52 <nickm> there is no branch there right now
14:10:01 <nickm> afaik
14:10:08 <Yawning> (when iut happens)
14:10:11 <nickm> though there are plenty of other fun fun branches to review
14:10:12 <nickm> ah
14:10:23 <Yawning> yeah I'll review more stuff
14:10:49 <Yawning> I kind of want to get this obfs4proxy scramblesuit stuff done too before poking at more tor, but it's almost there
14:11:16 <nickm> great
14:12:05 <dgoulet> nickm: one thing I would like to talk about is the network testing plan (oh well we can wait after this meeting)
14:12:31 <nickm> what about it? :)
14:13:37 <dgoulet> nickm: one of the next important goal for sponsorR for next quarter is to come up with a way of testing tor in a network with different HS scenarios so we can measure performance, improve and well investiguate future versions
14:13:45 <dgoulet> which overlaps quite well with sponsorS
14:14:42 <dgoulet> nickm: thus I would like to start that, we've made a very "brainstorm" plan in boston but maybe we are ready to move forward to something more concrete?
14:15:17 <nickm> Sounds plausible.  What are you thinking for this testing?  One of the challenges is that shadow is better for performance numbers but IMO harder to work with
14:16:03 <nickm> The testing I'm aiming at for S is less performance centric and more does-it-work centric
14:17:26 <dgoulet> yeah shadow is definitely a choice for what we need for sponsorR I would say, I haven't thought of that in depth though, I wanted to know if you had any more ideas written down on a napkin :)
14:17:45 <nickm> I'm writing down a lot of napkin ideas this week, I hopel.
14:17:47 <nickm> *hope
14:18:14 <nickm> Have you been getting any shadow experience?
14:18:34 <dgoulet> nickm: I have it setup now on my machine and Rob helped me a lot understand more shadow
14:18:41 <nickm> great
14:18:53 <dgoulet> we haven't made it work with tracing though (lttng) ... complicated issues but I have a plan to make it work
14:20:15 <dgoulet> but yeah depends on the use case for shadow I would say and maybe both chutney and shadow would be useful for different things
14:20:45 <teor> Chutney is useful for sanity checks
14:21:09 <teor> asn: yes, I have bumped #9321 up to the top of my list for this weekend.
14:21:19 <nickm> woo
14:21:26 <teor> asn: or was there another you wanted?
14:21:55 <dgoulet> nickm: also, apparently Ian has this big cluster in his lab with a full tor network made by sukhe sooooo could be useful ;)
14:22:29 <nickm> neat
14:25:33 <nickm> Anything else for this meeting?
14:27:59 <nickm> ok
14:28:04 <nickm> thanks, everybody!
14:28:06 <nickm> #endmeeting