18:29:30 <nickm> #startmeeting 18:29:30 <MeetBot> Meeting started Wed Nov 25 18:29:30 2015 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:29:30 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 18:29:44 <nickm> I'm here. And I'll start with a check-in 18:30:13 <nickm> Over the last week or so I've been scrambling to review and merge more stuff and put 0.2.7.5 out. I've also been consumed by administrative stuff! 18:30:46 <nickm> I have 5 days left in november. 1 is a holiday; 1 I am going to spend travelling and doing a guest-lecture for an MIT class 18:31:04 <nickm> that leaves three days which I'm going to spend with my family; I might get hacking/review/merging done then too. 18:31:25 <nickm> If I do, I'm going to see if I can review something hefty. Or finish #15055 at last. 18:31:32 <nickm> Anybody else around to check in? 18:31:37 <Yawning> hi? 18:31:57 <nickm> hi! 18:31:58 <Yawning> I reviewd your random branch 18:32:08 <Yawning> writing the pq link handshake proposal now 18:32:14 <nickm> cool 18:32:18 <Yawning> I don't have holidays for the turkey 18:32:28 <Yawning> but my weekend is shot due to having to travel to freedomland 18:32:32 <Yawning> to addend that meeting 18:32:35 <Yawning> *attend 18:33:10 <Yawning> I filed anohter bug about our crypto_strongest rand usage 18:33:12 <nickm> sorry there; I'm not thrilled about it either, but sometimes this stuff happens 18:33:35 <nickm> speaking of crypto... any ideas how to turn my aez ideas into something great? Rogaway et al haven't gotten back to me yet 18:33:47 <nickm> I wonder if I need to start coding and benchmarking 18:33:52 <Yawning> hm 18:33:59 <Yawning> dunno, I thought what you had was ok 18:34:00 <dgoulet> hi meeting 18:34:04 <isis> hey hey 18:34:05 <nickm> hi dgoulet ! 18:34:08 <nickm> hi isis! 18:34:16 <Yawning> I'm currently leaning towards changing our KDF 18:34:27 <isis> why? 18:34:28 <nickm> Yawning: I don't think I solved the forward secrecy issue or the chaining issue yet. 18:34:31 <Yawning> from HKDF-SHA256 to SHAKE128 18:35:02 <Yawning> and also just using SHA3-256(tweak | sekrit) 18:35:07 <Yawning> instead of hmac 18:35:28 <Yawning> I guess we can argue about this when the proposal is out 18:35:44 <Yawning> (and yes, doing that is safe, since SHA3 is immune to length extension attacks) 18:36:01 <nickm> for the AEZ proposal? Yeah, shake128 is seeming like a decent option there... 18:36:14 <Yawning> well I assume we'll deploy aez + ringlwe 18:36:37 <nickm> sounds good, except IMO we should not make either block on the other 18:36:40 <Yawning> we could go up to SHAKE256, but I don't see a point 18:36:42 <Yawning> yah 18:37:48 <Yawning> unless people think 128 bit collision, preimage, 2nd preimage resistance is insufficient 18:38:05 <nickm> assuming that stands up to quantum stuff like the rest of what we're trying to do, then sure let's go for it 18:38:10 <Yawning> yeah it does 18:38:43 <Yawning> they're all dependent on how much output you use 18:38:52 <Yawning> but we'll use at least 256 bits so, it's fine 18:39:25 <nickm> aight 18:40:10 <asn> hello there 18:40:13 <nickm> hi asn! 18:40:19 <asn> last week i worked on the prop250 implementation 18:40:25 <asn> figured out a few more edge cases and various ways to solve them 18:40:51 <asn> i also found a bug that might be causing #16702 18:41:01 <asn> and did a short review of #17254 18:41:28 <asn> my review queue is now almost empty (still waiting for revision of #17254) 18:41:39 <asn> so if you have something for me to review this week shoot 18:41:40 <Yawning> review the random thing 18:41:52 <Yawning> #17686 18:41:53 <nickm> there's lots of stuff in needs_review if you're interested. :) 18:41:58 <Yawning> it'll take like 5 mins 18:41:59 <nickm> some big, some small 18:42:13 <asn> nickm: i can do a medium one! 18:42:18 <Yawning> if you trust nick, teor and my analysis of the impact 18:42:30 <asn> Yawning: ack will check #17686 18:43:32 <nickm> #8195 should be an easy review at this point 18:43:57 <nickm> (if you can't review the capabilities code, just review the rest) 18:44:04 <nickm> also there are a bunch of other cool things in needs_review 18:45:06 <asn> ok will take a look at #8195 18:45:19 <asn> yeah i've noticed how many things are in needs_review! cypherpunks write code! 18:45:23 <TvdW> still working on #17254, the code is almost done (found a few minor issues), next up is the spec change, then tests, and hopefully then merge it in time for 0.2.8 :) 18:47:13 <dgoulet> been mostly working on prop250 code, since we hit a roadblock last week, the code had to be changed to address it, I'm in heavy testing mode with chutney right now. Few tickets here and there, one I would like your opinion on is: #17688 (asn already commented) 18:47:19 <nickm> asn: you might also like a look at #14828 18:47:29 <Yawning> that should be easy 18:47:36 <Yawning> I should review that since I filed it 18:47:39 <nickm> #17688 seems simple to fix 18:48:02 <nickm> Yawning: one thing to make sure is that we validate those fields and they aren't forgeable. I am forgetting what is derived from what how. 18:48:25 <nickm> wrt the prop250 stuff: I am starting to get scared of the code review. This sounds like an absolutely huge thing 18:48:56 <dgoulet> nickm: not that huge and most of it is self contained 18:49:07 <dgoulet> nickm: we also plan to cover it with unit test anyway (already there are some) 18:49:17 <dgoulet> nickm: but I need to talk to you about what part 18:49:29 <nickm> sounds good. Is the proposal really done now or is it still getting revised a lot? 18:49:56 <dgoulet> nickm: mostly done, we need to adjust couple things (after that roadblock from last week...) 18:50:19 <nickm> is the latest version in tor-spec? 18:51:04 <dgoulet> nickm: it is yes, the changes I'm talking about are not yet in torspec though but they won't impact the whole thing to the point it's a new proposal 18:51:12 <nickm> ok. 18:51:13 <Yawning> oh hey coverity 18:51:15 <nickm> what's the question btw? 18:51:21 <dgoulet> nickm: discussion phase? 18:51:24 <nickm> (I won't have time to fix any of those coverity issues today.) 18:51:26 <nickm> dgoulet: ok 18:51:34 <nickm> who else has a checkin to check-in? isis? 18:51:41 <nickm> athena? 18:53:09 <nickm> ok, on to the discussion phase! 18:53:16 <nickm> Feel free to jump in with more status updates as we go ahead 18:53:16 <dgoulet> :) 18:53:42 <dgoulet> (asn feel free to jump in here, but we need to resolve with nick this ed vs rsa dirauth key) 18:54:16 <dgoulet> nickm: so right now our code uses RSA fingerprint for dirauth since the ed shared random key can rotate in the middle of a protocol run which makes it not super fun to track 18:55:16 <dgoulet> nickm: now we probably don,t want that since well we want ed keys :) but they aren't hardcoded so this causes the problem of reicinving a vote and ultimately the only way we know it's _that_ dirauth is the RSA key 18:55:43 <dgoulet> nickm: I would like to know your take on what should we do that doesn't require us to add a zillion lines and two new proposals 18:56:22 <nickm> option 1: Decide that RSA2048 is good enough for now. 18:56:47 <nickm> how would that be? It seems like the least complex option if you can't make ed work 18:57:46 <dgoulet> nickm: we still use the special ed SR key to sign/verify commits but we track which commits is which with RSA (that's the current code) 18:58:13 <dgoulet> so SR key can change, that's fine since it's ultimately tied to RSA key 18:59:03 <nickm> so why can't you tie an ed key to the rsa key? 19:00:36 <dgoulet> nickm: we do but we still need the RSA in the end :) 19:00:40 <nickm> that's fine 19:00:54 <nickm> the identity of the authority is currently its master RSA key 19:00:57 <nickm> that's fine 19:00:58 <dgoulet> oh ah! ok I was under the impression to just move away lol 19:01:02 <dgoulet> nickm: ah well no brainer 19:02:27 <nickm> anything else for today? 19:03:00 <dgoulet> I'm good that was my blocker (which was not really one :P) 19:03:45 <nickm> so, who remembers this ... https://trac.torproject.org/projects/tor/query?status=accepted&status=assigned&status=needs_information&status=needs_review&status=needs_revision&status=new&status=reopened&keywords=~TorCoreTeam201511&order=summary 19:04:00 <nickm> I don't think i'm on track for november. :) 19:04:26 <dgoulet> I do have one on that list! 19:04:29 <nickm> I can knock a few of my things off though 19:05:14 <nickm> I bet I will have #15055 coded, #5460 done-ish, and #15233 done-ish. 19:05:16 <nickm> maybe 19:05:21 <nickm> 30 nov is actually pretty soon 19:05:36 <dgoulet> I'll review #12538 in a jiffy 19:05:42 <nickm> cool 19:07:28 <dgoulet> hrm #17178 is a bit big for Novemebr 19:07:35 <nickm> yeah at this point 19:07:36 <dgoulet> I see 5 child tickets! 19:09:15 <nickm> I think I need some help thinking about #15233 -- I have an in-progess proposal, but I'm thinking it wouldn't really work. 19:09:23 <nickm> or maybe it would 19:09:54 <dgoulet> this #17269 might not totally be a "process" issue tbh, it's in large part a resource and "too many jobs/hat" problem :S 19:10:38 <nickm> http://paste.debian.net/336079/ is my draft -- but I could use feedback on whether this kind of proposal might work at all 19:11:06 <nickm> I think for #17269 maybe we should schedule discussion-time for open proposals, and all chat about them over meetbot or something? 19:11:22 <nickm> This would require people to read them first 19:12:11 <dgoulet> hrm 19:13:18 <dgoulet> nickm: proposal review on IRC can be ... quite insane, they are often quite big, requires quite of bit of concentration and also understanding of the whole problem space 19:13:26 <dgoulet> and we can't all know all part of tor :S 19:13:49 <nickm> yeah, but maybe getting a few people for each one would make sense? 19:13:54 <nickm> or assigning reviewers to proposals? 19:15:18 <dgoulet> nickm: yeah this comes down again to "sub-maintainers" question imo, I mean apart from you (and armadev) I don't see anyone that can take on every proposal 19:16:11 <dgoulet> nickm: so a new/draft/open proposal could be assign to a "sub-maintainer" of that subsystems (or knows relatively enough that subsystem) thus falls under his/her responsability to peer review it, basically make sure the train is moving 19:16:53 <nickm> I think that maybe we could even do it on an ad-hoc basis. 19:16:56 <dgoulet> divide to conquer 19:17:53 <nickm> like for example, the thing I just linked to (http://paste.debian.net/336079/) doesn't require deep understanding of Tor's protocols; but it _does_ require understanding of what-would-be-too-much-traffic 19:19:18 <dgoulet> right 19:20:13 <dgoulet> nickm: we can probably improve the "get things reviewed and done" situation, not sure we are going to fully fix it though, the rate of tickets and new features is getting through the roof lately :S 19:21:00 <dgoulet> "make all devs review tickets for X hours during the week" or else be shamed publicly :P 19:21:20 <nickm> or "friday/monday/whatever is review day" 19:21:27 <nickm> or something 19:21:39 <dgoulet> nickm: yeah one day a week, you only review stuff 19:21:44 <dgoulet> nickm: we could gamify it with swag :P 19:22:33 <nickm> only if folks enjoy that 19:22:43 <nickm> wouldn't want to make things horrible by trying to make them "fun" 19:23:46 <nickm> any other topics for today? getting close to the 60 minute mark and I'm going to have to head to visit my family soon 19:23:51 <dgoulet> sure, let's not impose horrible things but at some point it becomes more of responsability thing imo else _you_ do all the maintainer work and we only do features ;) 19:24:58 <dgoulet> nickm: this whole thing is probably something we could discuss among devs in an email thread (since well we are spread over all timezones :) 19:25:49 <nickm> good point. could I ask you to either kick off that thread, or summarize this discussion on the ticket, or both? :) 19:26:10 <dgoulet> nickm: sure, that will go later today if I can (worst case tomorrow) :) 19:26:23 <nickm> no hurry; very grateful 19:26:26 <dgoulet> np 19:26:28 <nickm> any other topics or do I #endmeeting? 19:26:35 <dgoulet> end! :) 19:27:23 <nickm> #endmeeting