15:00:59 #startmeeting SponsorR 15:00:59 Meeting started Tue Mar 31 15:00:59 2015 UTC. The chair is asn. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:59 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:01:02 hello all 15:01:05 ohmygodel: o/ 15:01:10 hi 15:01:35 ok let's get started 15:01:45 hi 15:01:48 who wants to start with a briefing, while I organize my stuff. 15:02:07 oh well 15:02:08 i will go 15:02:10 hello syverson 15:02:11 "eeeeeeeeee HS DoS eeeeeeeeeeee"? 15:02:14 so during past week 15:02:31 i voted on the top-down spreadsheet 15:02:36 discussed it a bit more with people 15:02:53 did a tor-dev post about *bridge stats* (not realted to HS stats but whatever): https://lists.torproject.org/pipermail/tor-dev/2015-March/008541.html 15:03:02 we published the crowdfunding post 15:03:09 and now i'm working on #15463 15:03:17 not entirely sponsorr material for some of them, but well... 15:03:29 #15463 is our new HS annoyance. 15:03:36 very excited about the crowfunding ! 15:03:40 we have the first HS bi-weekly meeting tomorrow, that's a GREAT subject for it :) 15:03:41 stupid but effective DDoS without easy solution. 15:03:44 dgoulet: yes. 15:03:49 dgoulet: well timed indeed. 15:03:56 anyway, that's that from me. 15:04:01 who wants to go next? 15:04:11 * dgoulet can go 15:04:24 go 15:04:41 (the hs meeting is at the same time the pt meeting is) 15:05:15 did a full timeline of an HS descriptor over 24 hours (validity time) with client/directory/service interactions, I'm almost done with the text part that had already comment on it for which we found stuff to fix 15:05:19 Yawning: fuck. 15:05:42 dgoulet: can you talk a bit more abou tthis timeline thing. 15:05:56 i still haven't had time to look at it :/ 15:05:58 worked on #15463 also lately, too much tor less R for me unfortunately, at least some progress on the HS improvement part, patch will come out of this 15:05:59 * dgoulet done 15:06:02 asn: np 15:07:21 next? 15:07:22 ok so no more about this timeling thing. 15:07:22 (is +HSPOST R?) 15:07:23 next? 15:07:30 * ohmygodel emailed an update already 15:07:34 Yawning: feel free to say any updates you have about it 15:07:39 Yawning: not really 15:07:42 ohmygodel: it was about your SMC exploration 15:07:47 summary: i found some SMC code 15:07:49 yeah 15:08:10 ok 15:08:20 asn: I reviewed it? And need to again sometime, but everything is on fire? 15:08:44 Yawning: ack 15:08:47 ok who next? 15:08:52 ohmygodel: is that the thing you mentiond "requires an MPI implementation"? 15:09:34 yawning: yes 15:10:01 (only for the StatAuths, relays have completely trivial stats reporting) 15:10:10 can we rip MPI out? 15:10:26 yawning: probably yes. i assume its because they ran the StatAuth over a cluster 15:10:31 maybe discussion after status report ? :) 15:10:44 (sorry) 15:11:03 ok. who next? 15:11:24 * karsten doesn't have much 15:11:37 voted on the top-down thing, done. (sorry.) 15:11:48 ack no worries 15:11:55 next? syverson ? 15:11:57 * syverson was mostly away and/or working on other things. I did enter my vote on the top-down thing, but just an hour ago. 15:12:02 ok 15:12:03 great 15:12:06 that makes sense i guess 15:12:09 let's move to discussion 15:12:40 so, yeah, MPI, I've written a ton of MPI code in the past 15:12:49 topics that you would like to see discussed? 15:12:52 so if we need to rip it out I probably could 15:12:52 ok let's start with SMC. 15:13:01 but I haven't looked at said code yet 15:13:21 asn: different topic, but I think I'll take your advice and sent out an early version of my paper to tor-assistants very soon 15:13:26 asn: topic -> my summary about the voting at top-down list 15:13:31 here is the code: https://github.com/benkreuter/secure-computation-uva 15:13:45 kernelcorn: hah tor-assistants. that's a private list. but ok. 15:13:52 isabela: yes 15:13:59 isabela: top-down discussion is queued up after that. 15:14:03 ok 15:14:22 asn: well I've posted to it before, I'll take another look 15:14:25 this code has a compiler/ dir. 15:14:35 kernelcorn: you can post there, but only tor devs will be able to read it. 15:14:46 kernelcorn: i will be able to read it if you post there. 15:14:54 that's fine, I just need some feedback like you suggested 15:14:56 ok all sorry i have to go now 15:15:03 ohmygodel: alright 15:15:06 ohmygodel: o/ 15:15:07 i think the SMC stuff is still early evaluation 15:15:07 ohmygodel: anything you want to talk about? 15:15:08 before leaving? 15:15:13 ohmygodel: ack 15:15:21 it might be a good idea 15:15:35 to get some thoughts from you all 15:15:51 about if it seems like a reasonable approach 15:15:54 ack 15:16:02 (after the top down thing, we should talk about stats and our current fire) 15:16:10 ok adios 15:16:18 maybe we can talk about the current fire before the top-down? 15:16:22 in case we can add stuff to the top-down? 15:16:24 what's on fire? 15:16:29 kernelcorn: #15463 15:16:42 kernelcorn: HS DoS through circuit creation. 15:16:56 oh wow 15:17:03 14:07 < armadev> it would be nice if we had network wide statistics about how many intro cells we saw 15:17:06 14:07 < armadev> and how many rend points were established 15:17:09 14:07 < armadev> all those things i wanted a few months ago and everybody was like "what good would that be" ;) 15:17:42 that would indeed show the scale of the attack. 15:18:05 ok let's talk about this attack for the next 15 minutes (till 15:30) in case we can find of any nice statistics to collect 15:18:10 after that, let's move to top-down. 15:18:23 so, intro cells is hard to learn safely, right? 15:18:33 and established rend points is mostly harmless. 15:18:44 that's also my impression yes 15:19:10 we could totally work on est rend points and have stats in 2 months from now. 15:19:16 is that useful? .. 15:19:27 seems like overkill for this 15:19:28 maybe. 15:19:39 for this specific attack, it would show us how much the attackers are trying. 15:19:48 theoretically, they could not even estalbish rend points though 15:20:07 but they are I think 15:20:11 yes 15:20:12 because we see successes? 15:20:29 just saying that if we do this stat just to watch this attacker, then maybe they could adapt in the future. 15:20:38 indeed 15:20:47 it would be useful to have the sort of stats that highlight that someone is doing the smarter variant 15:20:48 another useful stat would be something that tells us what we should set MAX_REND_FAILURES to 15:20:53 if/when that happens 15:21:01 Yawning: that would be number of INTRODUCE1 cells. 15:21:11 (or we can try to kill the smarter variants with fire) 15:21:28 but number of INTRODUCE1 cells will leak the popularity of HSes. 15:21:36 so we've been avoiding it so far. 15:21:36 hrm stats of failures could be very useful to us, no idea on the privacy side :S 15:21:54 what's MAX_REND_FAILURES? 15:22:00 8 15:22:06 karsten: it's how many relaunches 15:22:07 I mean, what is it used for? 15:22:12 is there any indication that the DOS attack is being used in conjunction with traffic analysis and observations for that traffic flood? 15:22:15 karsten: the hidden service will do, if it's first rendezvous circuit fails 15:22:20 number of times you relaunch when you fail to connect to the RP 15:22:28 8 times? oh wow. 15:22:34 yeah it's loco. it used to be 30. 15:22:36 lol. 15:22:48 30 was crazy yolo :) 15:22:58 kernelcorn: no. 15:23:05 ty 15:23:06 isn't that something we could measure on a HS? 15:23:09 kernelcorn: no, this is a terribad way to mount this sort of thing 15:23:14 i think 1 relaunch or 0 relaunch is fine. and we should make the client retry. 15:23:30 fairly sure the client does retry 15:23:31 Yawning: all right 15:24:13 if the client retry logic is sensible, I'm fine with 0 relaunches too... but need more thinking. 15:24:13 kernelcorn: could be adapted to me a traffic confirmation thing, but they're randomizing the RP in each intro cell, which makes that unlikely 15:24:14 FYI, if the circuit times out, only one relaunch is done 15:24:17 asn: INTRODUCE1 need not leak popularity (which I continue to not see as a problem anyway, but that's another matter) if these are system aggregated numbers only. 15:24:34 syverson: you mean if we had a stats aggregation thing? i agree. 15:24:43 asn: yes 15:24:48 yes i agree 15:25:33 asn: I would also think 1 is enough fwiw 15:25:41 ack 15:25:46 i will try to look into this tomorrow 15:25:50 or later today 15:26:24 so everything trends toward "We need a stats aggregation system" ... 15:26:47 well, i would prefer to just plug the attack entirely. 15:26:53 then i wouldn't care if someone is doing it ;) 15:27:05 oh well I meant for the stats part of detecting these attacks 15:27:06 it seems stats are not the answer for this attack. 15:27:13 karsten: heh 15:27:29 yeah 15:27:34 ok 15:27:38 topic exhausted. 15:27:40 just thought it was worth bringin gup 15:27:47 let's move to top-down list 15:27:55 the spreadsheet is here https://docs.google.com/spreadsheets/d/1mY8wax7FBUIAPAmDLpGcEtYCYCcsxW21KtLCntRbSk0/edit?pli=1#gid=0 15:28:00 and most actors have voted 15:28:15 interesting patterns merge from the votes 15:28:22 (was I supposed to? no right?) 15:28:25 yes 15:28:36 Yawning: you can if you want! 15:28:37 (I mean yes to asn comment) 15:28:40 oh ok 15:28:51 in any case, it seems that most people are conservative here, and I like this. 15:29:19 the green rows are mainly things that don't require tor modifications at all. 15:29:41 and we can just collect from testnets, or from looking at historical consensus documents 15:29:42 which also means that we can work on them more quickly. 15:29:47 yes 15:29:52 personally, I like this. 15:29:55 yep 15:29:56 row 4 and 5 are being worked on by me 15:30:09 rehi 15:30:11 great 15:30:14 row 3, DonnchaC_ has stuff on it 15:30:15 Yawning: is high memory usage associated with this attack? 15:30:16 meeting still hppening? 15:30:24 dgoulet: exactly 15:30:35 kernelcorn: we don't know. CPU is the main issue. 15:30:48 row 14, naif has a system for that 15:30:52 nickm: yes 15:30:53 I can also take over row 3 from DonnchaC_, if we decide to work on that. 15:31:18 I'm very interested in working more on *stresstesting* HSes. 15:31:19 row 18 also I have an HS that I use for profiling, that should be something tpo could host though 15:31:31 all right, I have a Tor instance that's consuming 1.48 GB of RAM, I guess it's unrelated 15:31:52 isabela: 15:31:53 isabela: hello 15:31:56 asn: tbh, a tor network with rate limiting links would be AMAZING for that :) 15:31:59 isabela: would you mind telling us a bit about your email? 15:32:07 isabela: i think you mainly told us which rows are green, right? 15:32:57 dgoulet: wow, that seems hard. 15:33:25 asn: I actually have what you need for that! I just need time to set it up 15:33:27 dgoulet: i have no idea how you would do that the right way. that's the sort of stuff that ns/opnet etc. does, right? 15:33:28 dgoulet: http://info.iet.unipi.it/~luigi/dummynet/ 15:33:33 ^_^ 15:33:43 asn: https://github.com/nsec/the-internet 15:33:44 now we have more votes there - but when I looked at it there were 2 questions where all the votes were negative and which I was wondering if we should drop or think of other approaches 15:33:59 isabela: fine with dropping them. 15:34:08 isabela: the big question here, I think 15:34:16 isabela: is from the rows that are green, which ones would the sponsor appreciate? 15:34:49 top 3 rows are definitely something the sponsor will like imo 15:34:51 and should we care about this? or should we go full greedy tactic (do the best for Tor) and hope that it works for the best. 15:34:58 dgoulet: ok 15:35:04 how much time is left? 15:35:13 karsten: till july I guess :) 15:35:18 yeah July 15:35:20 ah, not april? 15:35:27 karsten: april long gone man 15:35:28 karsten: well quaterly meeting in 2 weeks 15:35:40 but the real juice of our work should be presented in July 15:35:53 full month of meeting and decision will be taken on our funding ;) 15:36:17 okay, great. plenty of time. 15:36:39 14 is something they would like, no? 15:36:43 row 14 15:36:59 isabela: not entirely sure because they do have crawlers :) 15:37:20 hehe 15:37:31 * isabela will hide the rows that are all red (just for now) 15:37:38 isabela: ok 15:37:48 isabela: that sponsor developed intelligent crawlers that do not abuse the Tor network and use them for fingerprinting bad websites 15:38:44 I don't know if this is the time/place for this. But I have yet to have someone tell me the harm from leaking that the most popular HSes are roughly popular after a delay. I think the assumption that this is bad accounts for a lot of the "no safe way to do this" entries. 15:40:20 isabela: are you hiding rows that are all red or rows that have red in them? 15:40:33 let me pick three rows that we could do for July and you tell me if you enjoy: 15:40:42 * HSDir health stuff that dgoulet is working on 15:40:53 * IP lifetime stuff that donncha started work and I could take over or karsten 15:40:59 yep 15:41:10 * Preemptive circuit building and stresstesting hidden services 15:41:17 that I could do or dgoulet or karsten 15:41:28 asn: for the "IP lifetime stuff", you could also take on 23 easily also 15:41:45 karsten: I hided some that had majority red as well 15:41:59 dgoulet: 23 is hsdir hash ringstuff? 15:42:00 if I choose, I'd prefer crunching numbers/descriptors over setting up things. 15:42:04 if I may* 15:42:11 karsten: just trying to have a perspective of how many are actually something to consider (seems 6 to 9 now) 15:42:19 karsten: yes that's also my preference :P 15:42:24 asn: yeah sounds like could be easy to do and useful to detect maybe attacks? 15:42:27 asn: ah :) 15:42:31 karsten: in that case, I think #15513 might be nice for you? 15:42:43 karsten: it has potential for nice visuals 15:42:53 asn: sounds great 15:42:55 karsten: and also the fact that donncha is checking out actual hidden services might excite the sponsor. 15:42:58 ah yeah that intro point algorithm is still a mistery to me ... 15:43:05 dgoulet: oh my... 15:43:27 would be useful to me to have a comprehensive analysis of it for the HS Descriptor timeline and reachability also 15:43:34 (people can unhide things if they want) 15:43:40 isabela: sounds good. I wasn't sure about one row, and then it went away before I could check. 15:44:05 syverson: i'm also not sure if this is the time/place for this :) 15:45:34 asn: OK sure. 15:46:20 k so what should we do with the top-down thing now? 15:46:39 should we look at the green stuff and see what excites us over the next week? 15:46:40 isabela: ? 15:46:53 yes 15:47:29 another question is how many can be done giving the time 15:48:06 i will need to dig a bit into each problem to understand how deep it is. 15:48:16 so, next week is pretty full here. (it's easter..) can we make plans for the next two weeks? 15:49:18 isabela: ^ ? 15:49:20 karsten: related to the top-down list? 15:49:39 15:46:58 < asn> should we look at the green stuff and see what excites us over the next week? 15:49:46 karsten: following week is during Sponsor R PI meeting. 15:49:47 related to that. 15:49:51 oh, ok. 15:50:12 how about next friday? 15:50:26 karsten: will you be away from IRC over the next two weeks? 15:50:35 karsten: 10? 15:50:37 somewhat, yes. 15:50:47 yep, 10th. 15:50:55 I,m ok with 10 15:50:56 would you like to check out #15513 and tell me what you think about it? if you do it in a week that's good. if you can't do it that fast, that's ok too? 15:50:56 sorry if I'm interrupting here, btw. 15:51:15 #15513 doesn't look too hard. 15:51:20 yes it looks quite easy t bh 15:51:27 I can work on that and try to get something done by tue, more by fri. 15:51:33 yes 15:51:34 like check it out 15:51:41 and see if it has lots of depth 15:51:46 sure. 15:51:49 if not, we can do it fast and move to another one. 15:51:55 right. 15:51:56 if it has depth, just report about it over the next two weeks 15:51:56 is SMC stuff should be considered for July? (not finished but being worked on?) 15:52:05 aka row 13 I just unhide 15:52:48 i have no idea about SMC. someone of us should look at the code... 15:53:06 well I just mean the "concept" in Tor 15:53:25 I was hoping that we'd have a list of SMC implementations to review for QOI. 15:53:31 And for usability 15:53:32 the concept of stats aggregation system, we've been talking about that since December but no decision on should we work towards one :S 15:53:33 nickm: we have 15:53:38 great; where's the list? :) 15:53:39 nickm: aaron email 15:53:42 nickm: [1] https://github.com/benkreuter/secure-computation-uva 15:53:42 [2] https://github.com/cryptouva/pcf 15:53:49 ok. 15:53:51 nickm: aaron sent "Subject: Weekly update in lieu of attending Sponsor R meeting" 15:54:26 one of them is in C++ and has a compiler/ directory. 15:54:31 who knows. 15:54:41 and my guess is that the Sponsor would like to know in april if we are working towards something like that 15:54:44 syverson: am I wrong? 15:55:05 ok 15:55:09 dgoulet: if we are working towards using SMC? 15:55:23 syverson: well a "stats aggregation system" in Tor (tbd) 15:55:48 Aggregation through some means or other is something IMO that we should do. SMC or not is TBD IMO. I think whether SMC mostly depends on the QOI and usability of the SMC implementations. 15:56:06 If not, then we need to return to some of the older proposals, which will limit what we can aggregate. 15:56:19 I think that's where we stand; am I right? 15:56:23 yes 15:56:39 I think giving them an idea of what we are planning to work on and why in general is good, but we don't have to give them everything. 15:57:12 syverson: right not everything just what we have/planned to do 15:57:19 Sorry, I didn't mean to say "SMC". I was using that as a stand-in for somehow doing stats aggregation. 15:57:28 ok i can take a look at the SMC implementations over next week, or nickm you can do it if you prefer? 15:57:51 let's do it together 15:57:56 and compare notes 15:57:59 ok 15:58:07 dgoulet: yes. 15:58:23 ok 15:58:29 so let's sum up what we will be doing for next week? 15:58:54 just to be clear, we don't *HAVE* to present a stats aggreation plan, just that if we want that, presenting some "agenda" in April sounds like a clever idea 15:58:55 - I will be looking at the top-down list, and specifically the stresstesting stuff. 15:59:14 I will also take a look at the SMC stuff with nickm. 15:59:21 And also at the timeline mail by dgoulet. 15:59:24 Someone will need to coordinate with Phil about what will be presented at the PI meeting kickoff. I think that will be Roger and me. 16:00:03 syverson: right armadev wants to be on the stage I think this time :) 16:00:06 you dgoulet, what will you be doing? i guess you will be working towards rows 4 and 5? 16:00:17 PI meeting is related to Memex? 16:00:26 But may imply answers to e.g. what nickm thinks when he looks into what the stuff ohmygodel pointed at will look like. 16:00:37 PI meeting is the Memex PI meeting. 16:00:42 ack 16:00:46 asn: yes mostly and I would also like to help you out for stess testing if you need anything, I've played with that quite a bit lately 16:00:53 dgoulet: yes i will need your help. 16:00:56 ok 16:00:59 and karsten? 16:01:06 that ticket 16:01:10 you will be lookin at #15513 and talking to me over IRC. 16:01:13 ok 16:01:15 awesome 16:01:16 yep 16:01:16 that seems reasonable. 16:01:22 asn: wait 16:01:35 asn: is the DoS performacne issue also something you are intersted in? 16:01:42 btw, with this and that and the DoS stuff, next week seems quite intense and I also have a plane to catch. 16:01:43 asn: that fits in SponsorR 16:01:45 dgoulet: yes 16:01:51 i will try to look into that too. 16:01:58 i will do stuff best-effort and try to be useful. 16:02:02 asn: cool, no rush, just fun stuff I think :) 16:02:14 so, meet next tue or fri? 16:02:18 (as usual, lemmie know if y'all need more help) 16:02:25 next tuesday is not very convenient for me. 16:02:27 Yawning: you are the ace in the hole for R! :P 16:02:40 because i will just have arrived to a different location. 16:02:47 do other people also prefer friday? 16:02:50 heh 16:02:53 no problem for me on Friday 16:03:00 at 16:00utc? 16:03:03 sure 16:03:04 works for me 16:03:11 we talking about next friday or this friday? next, right? 16:03:16 10 16:03:17 april 10th 16:03:18 neyt 16:03:19 yes 16:03:20 next 16:03:21 ok great 16:03:26 i'm fine with it. 16:03:31 ok 16:03:40 isabela: does our plan make sense? 16:03:44 isabela: or? 16:04:13 or would you like to resolve the top-down situation in a different manner? 16:05:46 #endmeeting