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