15:58:36 #startmeeting 15:58:36 Meeting started Tue Jan 26 15:58:36 2016 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:58:36 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:58:41 We're here to talk about prop#250! 15:58:52 :) 15:58:53 who else is around for this? 15:59:03 lurking 15:59:12 still sick 15:59:43 nickm: how would you like to do this? 15:59:46 we could do it Q&A style? 15:59:59 or we could do it "summarize proposal" style 16:00:03 or not sure. 16:00:36 how about I try to summarize, and you can correct/expand? 16:00:41 yes 16:01:19 ioerror_: that sort of HS is really easy to make 16:01:43 okay. So, there are 3 steps as I understand it. Step 1: every authority includes a commitment in their votes. In subsequent voting rounds, they include everybody else's commitments too (as far as they know). 16:02:07 Yawning: yes, i know - onionshare is insanely complicafted bcasue it isn't built into a client like ricochet or coyim 16:02:12 Step 2: every authority includes all the commitments they know about from step 1, and also includes all the reveals they know about, including their own reveal. This goes on for a few rounds too 16:02:25 great so far 16:03:04 Step 3: For one single vote, everybody does the "compute SRV calculation" on the values from step 2, and includes that in their votes. 16:03:17 Everybody includes the last two srvs in their votes. 16:03:25 The last two srvs go into the consensus 16:03:40 And SRV is shared random value, not https://en.wikipedia.org/wiki/SRV_record 16:03:45 have I got it? 16:03:54 yes you got it 16:03:58 bingo! 16:04:23 anybody else have questions before I start peppering with lots of questions and suggestions 16:04:24 nickm: so what would you say is in the votes the moment the SRV is created? 16:04:25 ? 16:04:47 The new srv and the one before and all the commits and reveals from the last round. 16:04:50 ? 16:04:57 Or maybe the commits for the next day 16:05:02 indeed the latter 16:05:11 because the SRV is computed at 00:00. the first commit round. 16:05:11 ok 16:05:20 so the votes contain the generated SRV, the previous one, and the new commitments. 16:05:28 nickm: feel free to start the peppers. 16:05:36 so, let me start with trivial questions for things to change or patch, and move to harder ones? 16:05:40 ok 16:05:45 SUGGESTION: SHA256->Keccak. 16:05:58 SUGGESTION: Base32->Base64 16:06:11 QUESTION: What's the format for "TIMESTAMP" in this proposal? 16:06:40 tsk, I told y'all to use sha3 ;_; 16:06:51 (I'm using tags like that so that it's easy to grep the meeting log) 16:07:00 OK, we can do SHA256->Keccak. Seems like lots of people like it. 16:07:04 #item SHA256->Keccak 16:07:14 Base32->Base64. Where do we use base32? i thought it was full on base64 16:07:38 * isabela is lurking 16:07:39 commit and reveals value are in base32 in the proposal 16:07:50 oh 16:07:54 they are b64 in the code, no? 16:08:07 yeah 16:08:10 ok 16:08:13 great; that's a proposal fix then. 16:08:16 #item fix base32 commits in proposal 16:08:23 good question about timestamp 16:08:28 it's time_t format 16:08:34 time_t of what? 16:08:36 which time_t ? 16:08:39 8 bytes? 4 bytes? 16:08:42 encoded how? 16:08:45 this is why we added tor_htonll/ntohll 16:08:58 yawning ioerror_: we are building onionshare into orbot with the ephemeral HS stuff, but we'll need to think about if that could cause any issues with Orbot itself. i guess i will write a spec and then ask for feedback. 16:09:01 The spec needs to say 16:09:02 set_uint64(buf + offset, tor_htonll((uint64_t) commit->commit_ts)); 16:09:03 nickm: set_uint64(buf, tor_htonll((uint64_t) commit->commit_ts)); 16:09:05 indeed 16:09:06 :) 16:09:10 #item specify timestamp better in spec 16:09:15 8 bytes, network-endian, time_t. 16:09:20 n8fr8: i can help, sure 16:09:30 And is it the timestamp of the start of the day, or the timestamp when the commit/reveal was generated, or what? 16:09:31 nickm: right! 16:09:34 n8fr8: basically, we should spec it out as a torspec - so various apps can do it right 16:09:37 (that should get documented too) 16:09:43 n8fr8: really, ideally, tor should just have a way to share a file 16:09:44 nickm: another great question! 16:10:00 n8fr8: eg: generate a random onion, serve a single GET request (or many) and done 16:10:22 nickm: it's actually the valid-after timestamp of the consensus we are aiming to make. 16:10:22 currently with CameraV we tell Orbot we want a hidden service, it replies back (via interapp intent) with the HS onion and port, and then we run a tiny web server in Java inside of CameraV 16:10:37 nickm: so if we are voting for the 19:00 consensus. the timestamp will be 19:00 time_t network-endian 8 bytes 16:10:47 ioerror_: sounds good 16:11:16 but we aonly generate one commit/reveal, right? In 4.1.1, what's the timestamp there? 16:11:58 nickm: one TS yes, it's put in the commit construciton then in the reveal and both are matched at the reveal phase 16:12:07 n8fr8: drop me an email? 16:12:23 nickm: if the auth was up on the voting stage at 00:00 , the timestamp should be 00:00 since that's the first commit phase where commitments are generated 16:12:30 ok 16:12:39 nickm: if the auth happens to wake up at 02:30 from eternal sleep, it will put 03:00 as the timestamp 16:12:48 QUESTION: Why does REVEAL put the TS first and COMMIT puts it last? (Still on 4.1.1) 16:12:49 if it ends up voting first time in the third commit round 16:13:00 nickm: i agree this is not elegant. 16:13:05 nickm: i've been thinking of changing it 16:13:15 nickm: but that would move code that has been stable for months 16:13:19 nickm: you don't like it either eh? 16:13:21 nickm: i can change it. 16:13:27 it doesn't make a lot of sense 16:13:28 minimal code change tbh 16:13:33 ack we will do it. 16:13:38 #item Why does REVEAL put the TS first and COMMIT puts it last? (Still on 4.1.1) 16:14:10 QUESTION: On 3.1.1., wrt the XXX question: why include previous_SRV at all? 16:14:53 SUGGESTION: On 3.1.1, wouldn't it just be easier to sort the R_b in ascending order and use them in HASHED_REVEALS? 16:15:27 hrm isn,t the case? 16:15:28 To maintain consistent ordering, ID_a | R_a pairs are ordered based on the 16:15:29 base64 encoded SR key of the authority in ascending order. 16:15:43 ah you mean _only_ R values? 16:15:53 yeah; sort the R; ignore the ID. 16:16:30 why not? 16:16:36 should be lots simpler, right? 16:16:43 16:14 QUESTION: On 3.1.1., wrt the XXX question: why include previous_SRV at all? 16:17:30 nickm: we added it because of the questionable "put everything and the kitchen sink inside a hash value if you can" paradigm 16:17:30 nickm: fun fact, we actually sort them by ID in the code... 16:17:41 nickm: as ian goldberg said, to break the symmetry between the days 16:17:52 nickm: not sure if it adds any concrete security properties 16:18:07 nickm: however the partioning part of the XXX is not an issue anymore 16:18:26 To avoid symmetry, wouldn't it be easier to include the date of the consensus in the hash? 16:18:27 nickm: because now authorities will first vote on the generated SRVs, and only ones that achieve majority will be transcribed to the consensus 16:18:43 nickm: true. 16:19:10 nickm: i'm trying to remember why the NIST beacon was chaining random value N into random value N+1... 16:19:23 QUESTION: when no previous-srv, what happens instead? 16:19:33 that's empty. 16:19:44 if (previous_srv != NULL) { 16:19:47 memcpy(msg + offset, previous_srv->value, sizeof(previous_srv->value)); 16:19:48 } 16:20:25 wait not empty. more like it's "\x00"*DIGEST256_LEN 16:20:30 ok, spec must say. 16:20:36 this will happen on the very first bootstrap run. 16:20:39 nickm: agreed!!! 16:20:52 #item specify what happens during SRV generation when therei s no previoous__SRV 16:20:53 the srv is the only thing that goes into the consensus, right? 16:20:58 yes 16:21:30 #item fix spec in "SUGGESTION: On 3.1.1, wouldn't it just be easier to sort the R_b in ascending order and use them in HASHED_REVEALS?" 16:21:47 asn_: hrm... we should fix code also and use R I think 16:21:54 ah thought the code was doing the right thing. 16:21:57 ack. 16:22:38 asn_: if one dirauth changes ID, and 6 uses it and 3 don't, could break srv creation 16:23:23 QUESTION: What exactly happens when SRV creation fails? IOW, what goes into the consensus, what do clients use, etc 16:23:59 nickm: riight. 16:24:00 #item remove the XXX in 3.1.1 since it's taken care of 16:24:12 nickm: if SRV creation fails nothing goes in the consensus, 16:24:22 clients should have some sort of disaster procedure that they do when there is no SRV 16:24:41 fallback to deterministic hsdir locaiton yeah 16:24:42 i imagine it's going to look like the SRV generation formula but with no reveal values. just the date or sth. 16:24:57 and clients will have to do this for 24 hours till the next one is created. 16:25:25 this needs to get specified too 16:25:48 suggestion: H(date, consensus) ? 16:26:18 nickm: that could be an issue though if HS has different consensus from client no? 16:26:45 yeah, need to figure out something there. 16:26:47 nickm: i did it here: https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=prop250_final_v1&id=0e3af7a31a073f69a9bd537eebc1cc64216d2ca0 16:27:07 SRV = HMAC("shared-random-disaster", TIME_PERIOD_NUM) 16:27:08 okay, that's probably good enough. 16:28:12 the big problem nickm 16:28:19 SUGGESTION: Fun fact: The current hour-based directory schedule is not in fact hardcoded. We need to be aware of that. So how about instead of "at 00:00" we say "the first consenus of the day" ? 16:28:24 is when SRV fails in the middle of the protocol run 16:28:43 so like at 14:00 most of our SRV supporting diruaths drop dead. and the resulting consensus method does not support SRV. so there is no srv in the consensus. 16:29:04 this is a big reachability issue for clients, since some clients will have the 13:00 consensus with an SRV, and some others iwll have the 14:00 consensus with no SRV. 16:29:15 and that's why we have introduced the AuthDirNumSRVAgreements mechanic. 16:29:54 i can explain this to you if you'd like. 16:30:04 16:29 SUGGESTION: Fun fact: The current hour-based directory schedule is not in fact hardcoded. We need to be aware of that. So how about instead of "at 00:00" we say "the first cons 16:30:15 hmm we could do that. we use 00:00 in a few places. that might be annoying. 16:30:33 well, it would break as soon as we go to a 45-minute cycle 16:30:36 or something 16:30:42 not that we're planning to do so 16:31:01 we use voting interval actually 16:31:03 and we align to that 16:31:13 okay, so document that? :) 16:31:14 return get_options()->V3AuthVotingInterval; 16:31:21 yes the code is slightly smoother than the proposal in this case 16:31:55 basically any consensus between 00:00 and 12:00 is commit phase. and any consensus between 12:00 and 00:00 (not inclusive) is reveal phase 16:32:16 so it can handle any sort of non-one-hour consensus 16:32:21 and if we ever went to a 13-hour cycle, we'd be screwed. 16:32:27 not that we're planning to do that 16:32:34 heh yes 16:32:51 I don,t think so how the code is done 16:32:52 #item document better the phase determination logic 16:32:58 but to fix spec though 16:35:25 QUESTION: Why the "MUST" in the second paragraph of 3.1.2? 16:35:33 what harm would it do? 16:35:41 that's not true. 16:35:45 we MUST remove it. 16:35:48 SHOULD 16:35:56 #item remove MUST from 3.1.2 16:35:56 should remove it, I mean :) 16:36:04 :) 16:36:29 oh yeah artefact... it had meaning in a long distant pre-pre-pre-pre proposal 16:36:44 QUESTION: If we say that the items in the hmac are sorted by R_i, not ID_i, then do we need 4.1.6 at all any more? I don't see the ID keys used for anything else 16:36:56 or any ed key for that matter 16:37:02 QUESTION: Do we use Ed keys in this? 16:37:59 we don't really. 16:38:16 we just use them for referencing dirauths. and then we translate them to their RSA keys. 16:38:37 i'm not sure if this makes sense, but it kind of seemed like a transition step. 16:38:58 hrm we kept it in the code so we could transition easily I think 16:38:59 where in the future when the RSA keys get ditched, we can just remove the code that translated to RSA keys, and keep the ed keys. 16:39:07 ^ that 16:39:12 but we don't need the keys at all here, right? 16:39:24 since nothing is actually signed except the votes and the consensus? 16:39:25 yup we could do without them 16:39:26 yes we could do without them. 16:39:31 dgoulet: ... 16:39:31 that would make stuff simpler :) 16:39:33 nickm: yes 16:39:59 nickm: you think we should ditch them? 16:40:32 SUGGESTION: Ditch all mention of identity keys and ed keys :) 16:40:37 unless we turn out to need them 16:40:46 which brings me to my last queued-up question 16:40:51 hm wait 16:40:58 when we say "ed keys" we mean "ed identity keys" 16:41:12 there is only one kind of ed keys in the proposal and that's the ed identity key. 16:41:40 we can ditch that, and then we keep only the RSA identity key as a way to reference. 16:41:47 that's what you meant right? 16:42:00 yeah 16:42:04 ok great 16:44:07 (do you want all these changes as commits on top of our current to-review branch, or should we make a new rebased branch?) 16:44:16 (i guess the latter, right? except if you are have already started looking at code) 16:45:10 i haven't started looking at code; and since some of this will remove things, a new rebased branch would be ok with me 16:45:18 and if you rebase to head, you get keccak, I think 16:45:29 (yes) 16:45:30 we already have keccak in there :) 16:45:33 ah 16:45:38 great 16:45:44 didn't know what your starting point was 16:45:45 that is code in branch we just don,t use it, sorry 16:46:00 last q on my list 16:47:00 ioerror_: done 16:47:06 QUESTION: There are no signatures here except the signatures on the votes and on the consensus. That means that if you want to prove that an authority was lying about a commitment or a reveal, you need to show the votes where it lied. Are we sure those are well-enough archived for us to debug any problems and thwart any evil there? 16:47:48 we plan to modify doctor to do this. 16:48:02 it should fetch votes every hour, check for issues, and archive them. 16:48:16 we need to make sure we're getting everybody's view of everybody else's votes too. 16:48:20 that should be plausible. 16:48:29 from Alice it should also fetch Bob's, Charlie's, Dave's votes. 16:48:38 okay, I'm out of questions/suggestions. anybody else got anything? 16:49:09 we will try to fix the issues you raised soon, and put it back on needs_review 16:49:17 thanks for the questions. very useful. 16:49:25 indeed ^ ++ 16:49:44 great! 16:49:46 #endmeeting