13:31:14 #startmeeting 13:31:14 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 13:31:16 ohai! 13:31:18 who's here? 13:31:37 (could be a short meeting if it's just me this morning...) 13:32:46 I'll give it another 10-15 minutes... 13:39:33 * teor is here, technical issues 13:39:40 hi, teor! 13:39:47 It looks like it might be just you and me this morning :) 13:40:54 how's it going? 13:41:07 personally, I'm hoping I can get a bit more hacking done this week, and take the weekend off. 13:41:13 I'll see if circumstances cooperate. 13:43:57 I have got absolutely no hacking done this week 13:44:08 The anticipated disruption happened then more happened then... 13:44:19 So maybe this weekend there will be hacking 13:45:22 remember, hacking is fun. :) 13:45:36 * dgoulet here! 13:45:37 Yes, which is why I regret not having time to do it 13:45:59 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 hello dgoulet! 13:47:51 hi dgoulet 13:48:04 I'm going to prioritize testing, mgetting things merged, and getting guard-related issues resolved. 13:48:07 teor, nickm: hello! and also Yawning ! :) 13:48:07 hi Yawning ! 13:48:08 hi toralf ! 13:48:09 Well, the crew is here... 13:48:38 I'm still half asleep 13:49:06 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 nickm: hi 13:49:53 nickm: please direct me anything that you think should be reviewed asap 13:50:02 hello i'm also around 13:50:03 (or need patches) 13:50:07 asn: o/ 13:50:44 mainly going to be working on SponsorR PM stuff this week. 13:51:01 and also uni stuff. 13:51:13 asn: ok. Do we have a plan right now for guardiness branches and "freak out if guards go away" ? 13:51:21 hm 13:51:29 guardiness branch needs some more fixes. 13:51:31 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 i need some more feedback from teor, and I will fix them soon. 13:51:55 it will happen soon. 13:52:02 now, on the "freak out" ticket. 13:52:07 i posted my thoughts in the last two comments. 13:53:01 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 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 hm. 13:53:15 nickm: let me suggest 13:53:18 you set up your tor 13:53:23 to log your guard usage 13:53:27 and check the logs for a few days 13:53:36 i can give you a branch if you want 13:53:40 that will do this for you 13:54:03 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 hm. 13:55:03 sure, upload the branch someplace. 13:55:08 ok 13:55:13 i will try to do this tomorrow. 13:55:26 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 I have a feeling that everybody but me has a solid notion of what the proposal actually _is_ :) 13:55:58 If that's not the case, then I'd love to know, so I can try to make one up. :p 13:55:59 heh 13:56:22 let's see.. 13:56:35 the simple version would be to find the right place in the code where direct connections to guards are happening 13:56:43 and every time we connect to a new guard, we increment a counter. 13:56:54 if the counter is over THRESHOLD, we warn. 13:57:04 now, the problem is finding The Right Place. 13:57:17 I candidate is entry_guard_register_connect_status() . 13:58:30 however, there are a few caveats that I mentioned in the ticket. 13:58:54 namely, that directory guards are causing lots of connections to guards that are not on the top of the list. 13:59:05 hm. Why is that? 13:59:08 Do we know? 13:59:11 yes 13:59:19 it's because we have NumDirectroyGuards = 3 13:59:34 ah. 13:59:41 well then. 13:59:42 so our guard algorithm will walk our guard list till it finds 3 guards that can be used as directory guards 14:00:04 and not all guards can be used as directory guards. 14:00:33 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 it might be fine to ignore directory guarsd for the purpose of that ticket.\ 14:01:33 because they are not very good at launching end-to-end correlation attacks, which this ticket is trying to prevent. 14:01:36 but I'm not sure about this yet. 14:03:15 as an example, over the past two days I have used 2 circuit guards. and 7 directory guards. 14:05:21 i haven't had much time to think how to make this work. 14:05:36 ok. I'm going to try to stare at it and see if I make any progress. 14:05:39 i've only had time to think of ways that the simplest approach might fail. 14:05:50 Is this on a reliable or an unreliable connection that you have been testing? 14:05:53 and i'm not going to have much time this week, but the next week might be better. 14:06:08 nickm: it's a reliable connection. in an unreliable one the situation would be worse. 14:06:56 ok 14:07:05 I'll try to experiment with different approaches and see if I find anything out 14:07:09 ok 14:07:55 entry_guard_register_connect_status() is a useful function to count circuit guards. 14:08:07 directory_initiate_command_routerstatus_rend() is a useful function to detect connection directory guards. 14:08:11 *to dir guards 14:08:24 gl hf 14:08:35 I'll try :) 14:08:40 * asn goes back to uni work 14:09:03 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 into 14:09:37 I would gladly help the way I can 14:09:43 I'll review the branch? 14:09:48 ok. are you up to speed on the ticket? 14:09:52 there is no branch there right now 14:10:01 afaik 14:10:08 (when iut happens) 14:10:11 though there are plenty of other fun fun branches to review 14:10:12 ah 14:10:23 yeah I'll review more stuff 14:10:49 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 great 14:12:05 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 what about it? :) 14:13:37 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 which overlaps quite well with sponsorS 14:14:42 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 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 The testing I'm aiming at for S is less performance centric and more does-it-work centric 14:17:26 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 I'm writing down a lot of napkin ideas this week, I hopel. 14:17:47 *hope 14:18:14 Have you been getting any shadow experience? 14:18:34 nickm: I have it setup now on my machine and Rob helped me a lot understand more shadow 14:18:41 great 14:18:53 we haven't made it work with tracing though (lttng) ... complicated issues but I have a plan to make it work 14:20:15 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 Chutney is useful for sanity checks 14:21:09 asn: yes, I have bumped #9321 up to the top of my list for this weekend. 14:21:19 woo 14:21:26 asn: or was there another you wanted? 14:21:55 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 neat 14:25:33 Anything else for this meeting? 14:27:59 ok 14:28:04 thanks, everybody! 14:28:06 #endmeeting