13:29:57 <nickm> #startmeeting
13:29:57 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:30:00 <nickm> good turnout today!
13:30:15 <nickm> we'll go with the usual pattern: quick updates, then discussion
13:30:18 <nickm> who wants to go first?
13:30:48 <asn_> i can go first
13:30:51 <nickm> go for it!
13:30:53 <asn_> our main progress the past week
13:31:10 <asn_> was to finalize the prop250 code and put it in needs_review (#16943)
13:31:39 <asn_> we also sent an email to tor-dev
13:31:46 <asn_> to attract more people looking at the design & code
13:31:55 <asn_> apart from that I took a look at a few trac tickets
13:32:06 <asn_> and I also accumulated a big backlog of emails and tickets to reply to.
13:32:20 <asn_> that's that from me on the little-t-tor front I think :)
13:32:35 <asn_> i'm here to play the review trade game btw :)
13:33:02 <asn_> so please give me a ticket to review, and maybe take a look at the prop250 code :)
13:33:17 <nickm> cool. I'll go next?
13:33:20 <asn_> sure
13:33:39 <nickm> 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 <nickm> 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 <nickm> 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 <nickm> everything is behind schedule. :)
13:35:07 <nickm> next?
13:35:17 <Yawning> worked on obfs5
13:35:24 <Yawning> ignored email
13:35:40 <Yawning> plan are to continue doing so, and figure out my real life move situation
13:35:57 <Yawning> also dust off that multithreaded link crypto branch and get it merged
13:36:13 <Yawning> someone proposed a maybe-usable ring-lwe based signature scheme
13:36:31 <nickm> 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 <Yawning> though I have some issues with their parameter choices
13:36:38 <Yawning> no
13:36:43 <Yawning> it's a mess of code
13:36:56 <Yawning> it'll have something that will work but will probably change shorlt
13:37:04 <nickm> ok
13:37:15 <nickm> then I'll keep them on my list of "contact when the protocol is documented"
13:37:16 <Yawning> if I should re-proprtize lemmie know
13:37:21 <nickm> no hurry
13:37:42 <Yawning> apart from this, uh, trying to avoid getting swallowed by existential angst and despiar, and failing. >.>
13:37:46 <Yawning> oh well, fun times
13:37:49 <Yawning> im done
13:37:57 * dgoulet can go next
13:38:26 <nickm> go ahead
13:38:27 <dgoulet> 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 <dgoulet> done
13:38:35 <nickm> Yawning: good luck w the angst
13:39:18 <mikeperry> I'm ready
13:39:28 <mikeperry> 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 <mikeperry> 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 <mikeperry> 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 <mikeperry> 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 <mikeperry> 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 <mikeperry> 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 <mikeperry> 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 <mikeperry> (sorry for the double-paste in there.. ssh lag)
13:40:35 <Yawning> how many things do you need to add
13:40:49 <Yawning> we need to bump the link protocol for the crypto changes anyway
13:41:11 <nickm> wrt your question: I think advertising in descriptors/microdescriptors via the protocol versions proposal I wrote would be  a clever idea
13:41:28 <nickm> 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 <mikeperry> 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 <nickm> how good is the evidence that this will actually make traffic analysis harder?
13:42:40 <mikeperry> nickm: prop#264 you mean?
13:42:52 <nickm> that's the one
13:43:53 <Yawning> the adapting padding stuff
13:43:55 <Yawning> is fairly good
13:44:00 <mikeperry> 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 <mikeperry> the padding stuff showed very good results in experimentation: http://arxiv.org/abs/1512.00524
13:44:38 <nickm> ok by me
13:44:55 <Yawning> since when did arxiv hate tor
13:45:07 <nickm> I just want to be sure we're not moving without analysis.  (That way lies a huge pile of bad designs)
13:45:10 <mikeperry> hrmm. it loaded for me
13:45:13 <dgoulet> Yawning: it loves me
13:45:16 <Yawning> I had to new circuit
13:45:25 <nickm> but this sounds like decent plans for me.
13:46:08 <Yawning> also I've been trying to get a copy of this paper for a while
13:46:10 <Yawning> nice to finally see it
13:46:11 <nickm> does this all have design writeups in tor, or is prop#254 what we've got?
13:46:12 <Yawning> >.>
13:46:52 <nickm> err I mean, are there still proposals to write for this stuff?
13:47:15 <mikeperry> well, getting the primitives in is one thing. that arxiv paper shows that they are worthwhile
13:47:24 <mikeperry> tuning them optimally is more work
13:47:59 <nickm> what should I read to become convinced that these are the right primitives?
13:48:04 <mikeperry> but the stuff in prop#254 is flexible enough to be tuned, though
13:48:11 <nickm> (is the relay_end thing documented?)
13:48:16 <Yawning> the paper has a decent overview
13:48:24 <mikeperry> no, the relay_end thing I discovered last night.
13:49:46 <nickm> ok.  I'll see a proposal soon I bet.
13:49:51 <Yawning> the primitives they evaulated along with wtf-pad are the ones I'd have looked at
13:49:53 <mikeperry> 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 <Yawning> but I'm biased from having talked to mjuarez a lot
13:51:55 <nickm> ok, anybody else?
13:51:57 <mikeperry> oh, do we need cannibalization still, btw?
13:52:04 <Yawning> nickm: fwiw this padding stuff is the gsoc project from our last official gsoc round paying off
13:52:24 <Yawning> which makes me happy
13:52:26 <asn_> mikeperry: i guess it depends on what kind of performance win cannbalization gives us?
13:52:32 <nickm> Yawning: oh btw, is "clean up and finalize consensus diffs" still on our list?
13:52:37 <Yawning> yes
13:52:41 <nickm> great
13:52:42 <Yawning> it should happen in 0.2.8
13:53:01 <Yawning> my review/revise queue looks like
13:53:10 <Yawning> the threading stuff, your rng branch, then the consesus diff stuff
13:53:36 <Yawning> holding off on ring-lwe for tor since you told me to wait a bit >.>
13:53:56 <Yawning> though the ntru people ammended their proposal with most of my requests IIRC
13:53:59 <nickm> mikeperry, asn_: Analyzing the performance win would be a good start
13:54:36 <nickm> finding that there was very little win would make the choice easy
13:54:55 <nickm> if there's nobody else to check in, then let's acknowledge that we've moved on to discussion?
13:55:22 <nickm> 1: Here's everything tagged for January. https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~TorCoreTeam201601
13:55:28 <nickm> Nearly all of it is assigned to somebody!
13:55:46 <nickm> 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 <Yawning> https://eprint.iacr.org/2016/030
13:57:27 <Yawning> appears "almost like something we could use"
13:57:35 <nickm> 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 <Yawning> beyond the usual "oh god, lattices" caveats
13:58:15 <dgoulet> 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 <dgoulet> (no that accurate but gives us an idea ..)
13:58:29 <nickm> "Lattices: It is possible they are secure, and they are definitely affordable!"
13:58:46 <nickm> for #17269, here's what I propose, and I would like feedback.
13:58:47 <dgoulet> asn_, mikeperry: (well we should do more I should says instead of "not accurate")
13:59:11 <Yawning> ~3kib public keys, ~1.3kib signatures
13:59:30 <Yawning> easier to implement securely than BLISS-B
13:59:38 <nickm> 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 <nickm> 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 <nickm> I'm thinking at least one session like that per week for a while until we hae less backlog.
14:00:53 <nickm> *have
14:00:56 <Yawning> 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 <nickm> what do folks think about that?
14:01:44 <dgoulet> 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 <dgoulet> nickm: most of them need prior knowledge of the subsystem
14:02:09 <nickm> we can start with 1, and see how much energy it takes?
14:02:34 <nickm> We can also maybe try to divide them by complexity; some are more straightforward than others
14:02:41 <mikeperry> dgoulet: what is the "number of RPs" axis measuring exactly? concurrent requests?
14:03:02 <mikeperry> (on your cannibalize graph)
14:03:06 <nickm> Yawning, mikeperry: Does this idea seem sane to you?
14:03:14 <dgoulet> mikeperry: no it's the number of RPs established in the whole experiment
14:03:19 <Yawning> think so
14:03:22 <dgoulet> nickm: sounds good to me
14:03:54 <mikeperry> dgoulet: so cannibalized circs are slower unless you are a heavy hidden service user? is that the gist?
14:04:04 <nickm> 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 <mikeperry> 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 <nickm> "Draft" or "Open".
14:05:37 <nickm> 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 <dgoulet> 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 <nickm> what do you mean by "any preference on priority?"
14:06:39 <mikeperry> as in should we aim for reviewing Open before Draft before mailinglist? or the reverse?
14:06:58 <nickm> none of those orders IMO.
14:07:47 <nickm> 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 <nickm> IMO we should just start with "nominate something you think we should talk about that you didn't write" :)
14:09:32 <nickm> does that seem reasonable?
14:10:04 <mikeperry> ok
14:10:19 <dgoulet> how do we proceed for nomination? :)
14:10:27 <dgoulet> right here right now? :)
14:11:57 <nickm> Sure!
14:12:23 <nickm> We can let others chime in later on.
14:12:27 <nickm> I'll send a tor-dev email.
14:12:53 <nickm> I'll also do the scheduling, unless somebody is worried about my dictatorial powerz.
14:12:58 <mikeperry> I will review prop#264, since I need it anyway :)
14:13:41 <mikeperry> lso prop#261
14:13:46 <nickm> I nominate prop#250 and prop#251 .
14:14:20 <nickm> 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 <dgoulet> can we re-pick one that has been taken above? :)
14:14:32 <nickm> nope
14:14:47 <mikeperry> prop#259 and prop#241 are also interesting to me
14:15:07 <nickm> #action nickm sends mail about #17269 process.
14:15:08 <mikeperry> dgoulet: we can swap maybe. I am picking too many anyway
14:15:13 <nickm> #action nickm schedules reviews.
14:15:40 <dgoulet> I wanted padding or 259
14:16:42 <nickm> 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 <nickm> (I am out of slots for nominating.)
14:17:13 <dgoulet> I,m way to familiar with them :S
14:17:33 <dgoulet> I can go prop#257 and prop#258 (I alreayd reviewed the code of 258)
14:17:40 <nickm> 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 <nickm> ok, any more nominations?  If not we can move on to next topic, if any
14:19:18 <mikeperry> I have some comments about prop#246
14:19:29 <mikeperry> and would like to think about it in the context of traffic analysis things anyway
14:19:50 <dgoulet> 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 <mikeperry> ok. well I have 4. maybe I will do that one last or something
14:22:15 <nickm> well, we're nominating-for-discussion, not taking sole role of facilitating.
14:22:33 <nickm> though probably if you nominate something you should come having read it and be prepared to explain it :)
14:22:43 <nickm> any more?
14:23:40 <dgoulet> ah I do have something yes
14:24:12 <nickm> go for it
14:24:18 <dgoulet> are we trying to NOT make new code for src/tools and everything goes with tor cmdline ?
14:24:29 <dgoulet> asking for 224 and offline HS key generation
14:25:14 <dgoulet> tor --keygen is great but will need much more love for batching creation of blinded keys for a timeframe
14:26:27 <nickm> Either way is okay with me.   If there should be a separate tor-hs-keygen, then let's go for it.
14:26:46 <dgoulet> that answers my question, thanks
14:29:46 <nickm> 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 <dgoulet> good here
14:32:34 <nickm> #endmeeting