13:29:57 #startmeeting 13:29:57 Meeting started Wed Jan 13 13:29:57 2016 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:29:57 Useful Commands: #action #agreed #help #info #idea #link #topic. 13:30:00 good turnout today! 13:30:15 we'll go with the usual pattern: quick updates, then discussion 13:30:18 who wants to go first? 13:30:48 i can go first 13:30:51 go for it! 13:30:53 our main progress the past week 13:31:10 was to finalize the prop250 code and put it in needs_review (#16943) 13:31:39 we also sent an email to tor-dev 13:31:46 to attract more people looking at the design & code 13:31:55 apart from that I took a look at a few trac tickets 13:32:06 and I also accumulated a big backlog of emails and tickets to reply to. 13:32:20 that's that from me on the little-t-tor front I think :) 13:32:35 i'm here to play the review trade game btw :) 13:33:02 so please give me a ticket to review, and maybe take a look at the prop250 code :) 13:33:17 cool. I'll go next? 13:33:20 sure 13:33:39 I've been to HACS and RWC. Didn't find the solution to everything in life there, but got a bunch of folks interested in our problems and pet theories. 13:34:04 I'm slowly-but-surely working through my review backlog. Once I've reviewed mikeperry's big patch set, I'll get back to hacking some myself. 13:34:53 My biggest hacking priorities will be bugfixing on the authority ed25519 situation, & finally getting ed25519 link protocol done, & getting some modularization/sandboxing plots advanced 13:34:58 everything is behind schedule. :) 13:35:07 next? 13:35:17 worked on obfs5 13:35:24 ignored email 13:35:40 plan are to continue doing so, and figure out my real life move situation 13:35:57 also dust off that multithreaded link crypto branch and get it merged 13:36:13 someone proposed a maybe-usable ring-lwe based signature scheme 13:36:31 Is the obfs5 protocol specified with an up-to-date spec? I talked to a few people who were curious about how I was describing it 13:36:32 though I have some issues with their parameter choices 13:36:38 no 13:36:43 it's a mess of code 13:36:56 it'll have something that will work but will probably change shorlt 13:37:04 ok 13:37:15 then I'll keep them on my list of "contact when the protocol is documented" 13:37:16 if I should re-proprtize lemmie know 13:37:21 no hurry 13:37:42 apart from this, uh, trying to avoid getting swallowed by existential angst and despiar, and failing. >.> 13:37:46 oh well, fun times 13:37:49 im done 13:37:57 * dgoulet can go next 13:38:26 go ahead 13:38:27 As asn said, prop250 is finally in needs_review after some polishing last week. I've worked on breaking down step 1 of prop#224 which is the HS keys management and API/ABI for it. I've set up also a server for Rob/Aaron PrivEx experiment which will be running all week. Finally, worked too little on the instrumentation branch for KIST that Rob's really want, I'm hoping this mont 13:38:34 done 13:38:35 Yawning: good luck w the angst 13:39:18 I'm ready 13:39:28 After recovering from CCC, I spent the last week or so working on a proposal for load balancing with padding overhead (https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals/xxx-load-balancing-with-overhead.txt?h=load_balancing-squashed). 13:39:36 Basically, the idea there is to simplify the load balancing equations from dir-spec.txt 3.8.3 add overhead parameters for overhead at guard and middle nodes. Teor points out that the equations still don't account for cannibalization.. 13:39:44 For the later discussion portion: I'm now wondering if now that we have ntor, we still need cannibalization? It's bothered me at several points while making tor performance and path selection changes in the past. Does it provide any security over fresh circuits? Can we kill it? 13:39:50 I then turned my attention to traffic analysis issues. I am in need of the ability to add a couple new relay command cell types. 13:39:57 I then turned my attention to traffic analysis issues. I am in need of the ability to add a couple new relay command cell types. 13:40:10 For discussion: What is the best way to detect/negotiate support for that without risking being targeted/fragmenting anonymity sets by nodes selectively reporting capabilities? 13:40:16 Finally, I scanned the needs_review and needs_revision tickets, but I'm not sure what to pick. I can pick wildly, but maybe some suggestions/requests would be helpful, too. 13:40:29 (sorry for the double-paste in there.. ssh lag) 13:40:35 how many things do you need to add 13:40:49 we need to bump the link protocol for the crypto changes anyway 13:41:11 wrt your question: I think advertising in descriptors/microdescriptors via the protocol versions proposal I wrote would be a clever idea 13:41:28 that's our general solution for "you can't tell some people you have an ability and other people you don't." 13:41:37 I want to add an ack for RELAY_END, and I want to add a couple of padding primitives. Probably first one will be RELAY_COMMAND_SCHEDULE from prop#254 13:42:19 how good is the evidence that this will actually make traffic analysis harder? 13:42:40 nickm: prop#264 you mean? 13:42:52 that's the one 13:43:53 the adapting padding stuff 13:43:55 is fairly good 13:44:00 the RELAY_END ack will allow us to eliminate/drastically reduce a bunch of side channels are worrying enough that I'm not sure I should go into detail publicly 13:44:19 the padding stuff showed very good results in experimentation: http://arxiv.org/abs/1512.00524 13:44:38 ok by me 13:44:55 since when did arxiv hate tor 13:45:07 I just want to be sure we're not moving without analysis. (That way lies a huge pile of bad designs) 13:45:10 hrmm. it loaded for me 13:45:13 Yawning: it loves me 13:45:16 I had to new circuit 13:45:25 but this sounds like decent plans for me. 13:46:08 also I've been trying to get a copy of this paper for a while 13:46:10 nice to finally see it 13:46:11 does this all have design writeups in tor, or is prop#254 what we've got? 13:46:12 >.> 13:46:52 err I mean, are there still proposals to write for this stuff? 13:47:15 well, getting the primitives in is one thing. that arxiv paper shows that they are worthwhile 13:47:24 tuning them optimally is more work 13:47:59 what should I read to become convinced that these are the right primitives? 13:48:04 but the stuff in prop#254 is flexible enough to be tuned, though 13:48:11 (is the relay_end thing documented?) 13:48:16 the paper has a decent overview 13:48:24 no, the relay_end thing I discovered last night. 13:49:46 ok. I'll see a proposal soon I bet. 13:49:51 the primitives they evaulated along with wtf-pad are the ones I'd have looked at 13:49:53 but the root side channels it fixes have been brought up in private discussion with aaron johnson, isis, and myself, who basically all went "oh fuck" independently and simultaneously a month or two back 13:50:09 but I'm biased from having talked to mjuarez a lot 13:51:55 ok, anybody else? 13:51:57 oh, do we need cannibalization still, btw? 13:52:04 nickm: fwiw this padding stuff is the gsoc project from our last official gsoc round paying off 13:52:24 which makes me happy 13:52:26 mikeperry: i guess it depends on what kind of performance win cannbalization gives us? 13:52:32 Yawning: oh btw, is "clean up and finalize consensus diffs" still on our list? 13:52:37 yes 13:52:41 great 13:52:42 it should happen in 0.2.8 13:53:01 my review/revise queue looks like 13:53:10 the threading stuff, your rng branch, then the consesus diff stuff 13:53:36 holding off on ring-lwe for tor since you told me to wait a bit >.> 13:53:56 though the ntru people ammended their proposal with most of my requests IIRC 13:53:59 mikeperry, asn_: Analyzing the performance win would be a good start 13:54:36 finding that there was very little win would make the choice easy 13:54:55 if there's nobody else to check in, then let's acknowledge that we've moved on to discussion? 13:55:22 1: Here's everything tagged for January. https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~TorCoreTeam201601 13:55:28 Nearly all of it is assigned to somebody! 13:55:46 If there's anything there that's assigned to you and you're not going to get it done in Jan, please defer earlier rather than later. 13:57:06 https://eprint.iacr.org/2016/030 13:57:27 appears "almost like something we could use" 13:57:35 2: There was a little off-list traffic about #17269. I think it's worthwhile for us to try to get a plan into place for that 13:58:00 beyond the usual "oh god, lattices" caveats 13:58:15 mikeperry, asn_: this is something I did a while back with instrumentaiton in tor and chutney (so no latency): https://people.torproject.org/~dgoulet/hs/rp-025.png 13:58:22 (no that accurate but gives us an idea ..) 13:58:29 "Lattices: It is possible they are secure, and they are definitely affordable!" 13:58:46 for #17269, here's what I propose, and I would like feedback. 13:58:47 asn_, mikeperry: (well we should do more I should says instead of "not accurate") 13:59:11 ~3kib public keys, ~1.3kib signatures 13:59:30 easier to implement securely than BLISS-B 13:59:38 I suggest that everybody takes their two or three favorite proposals that they didn't write, and nominates them, and we have some proposal discussion sessions with meetbot on IRC where everybody shows up having read the propsal and ready to talk about it, trying to move it towards "Rejected" or "Accepted". 14:00:13 we should explicitly send links to these sessions to tor-dev for others to comment on, since proposal transparency is really important. 14:00:50 I'm thinking at least one session like that per week for a while until we hae less backlog. 14:00:53 *have 14:00:56 there also was a code based scheme paper but "oh god designing it with known attacks in mind" bloats ciphertext/key sizes to the point of hilarity :/ 14:00:59 what do folks think about that? 14:01:44 nickm: reading two or three proposals in a week and being able to comment on it will take most of my week tbh :S, can we make 1 proposal per week maybe? 14:02:08 nickm: most of them need prior knowledge of the subsystem 14:02:09 we can start with 1, and see how much energy it takes? 14:02:34 We can also maybe try to divide them by complexity; some are more straightforward than others 14:02:41 dgoulet: what is the "number of RPs" axis measuring exactly? concurrent requests? 14:03:02 (on your cannibalize graph) 14:03:06 Yawning, mikeperry: Does this idea seem sane to you? 14:03:14 mikeperry: no it's the number of RPs established in the whole experiment 14:03:19 think so 14:03:22 nickm: sounds good to me 14:03:54 dgoulet: so cannibalized circs are slower unless you are a heavy hidden service user? is that the gist? 14:04:04 ok. Is "Immediately after the wednesday meeting" a good time to schedule these for? Or should we go with "nominator suggests a time" ? :) 14:04:44 nickm: is this taking proposal in the repo that are in "Draft" still, or mailinglist ones, or both? any preference on priorty? 14:05:02 "Draft" or "Open". 14:05:37 If it's been to the mailing list and it hasn't been to the repo, the next step is probably to encourage the proponent to get it into the repo, if it belongs there 14:05:44 mikeperry: basically yes but this is 025, we should make sure to reproduce on at least 027 and maybe outside of chutney 14:05:51 what do you mean by "any preference on priority?" 14:06:39 as in should we aim for reviewing Open before Draft before mailinglist? or the reverse? 14:06:58 none of those orders IMO. 14:07:47 I think we should aim at reviewing whatever is most important to review: like, stuff that needs to get implemented and merged soon and hasn't gotten much review. Or, ideas that have been proposed and are now kinda stalled waiting on folks to decide "is this a good idea" 14:08:16 IMO we should just start with "nominate something you think we should talk about that you didn't write" :) 14:09:32 does that seem reasonable? 14:10:04 ok 14:10:19 how do we proceed for nomination? :) 14:10:27 right here right now? :) 14:11:57 Sure! 14:12:23 We can let others chime in later on. 14:12:27 I'll send a tor-dev email. 14:12:53 I'll also do the scheduling, unless somebody is worried about my dictatorial powerz. 14:12:58 I will review prop#264, since I need it anyway :) 14:13:41 lso prop#261 14:13:46 I nominate prop#250 and prop#251 . 14:14:20 mikeperry: okay, but I'll be deferring prop#261 a bit since I expect a better proposal to come along in a week or two 14:14:27 can we re-pick one that has been taken above? :) 14:14:32 nope 14:14:47 prop#259 and prop#241 are also interesting to me 14:15:07 #action nickm sends mail about #17269 process. 14:15:08 dgoulet: we can swap maybe. I am picking too many anyway 14:15:13 #action nickm schedules reviews. 14:15:40 I wanted padding or 259 14:16:42 Does anybody want to nominate prop#252 or prop#260 ? We have open patches there and not a lot of review on the proposals. 14:16:55 (I am out of slots for nominating.) 14:17:13 I,m way to familiar with them :S 14:17:33 I can go prop#257 and prop#258 (I alreayd reviewed the code of 258) 14:17:40 maybe we need to find a faster schedule and just assume not everybody has to be in every group? Otherwise, it might be hard to catch up in time to merge things. :( 14:18:34 ok, any more nominations? If not we can move on to next topic, if any 14:19:18 I have some comments about prop#246 14:19:29 and would like to think about it in the context of traffic analysis things anyway 14:19:50 mikeperry: I think asn_ wanted to revive this thread since we are at the point where we need to decide on it because we are starting 224 14:21:25 ok. well I have 4. maybe I will do that one last or something 14:22:15 well, we're nominating-for-discussion, not taking sole role of facilitating. 14:22:33 though probably if you nominate something you should come having read it and be prepared to explain it :) 14:22:43 any more? 14:23:40 ah I do have something yes 14:24:12 go for it 14:24:18 are we trying to NOT make new code for src/tools and everything goes with tor cmdline ? 14:24:29 asking for 224 and offline HS key generation 14:25:14 tor --keygen is great but will need much more love for batching creation of blinded keys for a timeframe 14:26:27 Either way is okay with me. If there should be a separate tor-hs-keygen, then let's go for it. 14:26:46 that answers my question, thanks 14:29:46 any futher topics? Otherwise I will endmeeting, hang out for a few minutes, then shovel some snow and get ready for my next phone meeting in 90 min 14:30:44 good here 14:32:34 #endmeeting