15:03:05 <asn> #startmeeting prop224 meeting
15:03:05 <MeetBot> Meeting started Wed Mar 16 15:03:05 2016 UTC.  The chair is asn. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:05 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:03:15 <asn> hello friends
15:03:18 <asn> who is here?
15:03:21 <asn> dgoulet, nickm
15:03:21 <special> hello chair
15:03:22 <asn> maybe special?
15:03:25 <asn> ok great.
15:03:30 <asn> not teor unfortunately.
15:03:48 <asn> so, small briefing, mainly for nickm's enjoyment
15:04:11 <asn> we've recently finished coding prop250. it's now in needs_review. likely to be merged early in 0.2.9.x.
15:04:22 <asn> after finishing prop250, we started focusing on prop224
15:04:29 <asn> (which was the original goal)_
15:04:42 <asn> we made up some sort of implementation plan
15:05:00 <asn> (sec)
15:05:09 <asn> which involves the following steps:
15:05:12 <asn> (roughly)
15:05:32 <asn> - Coding the HSDir side -- how descriptors are encoded/parsed. descriptor upload/download, etc.
15:05:49 <asn> - Coding the relay side -- IP cells, RP cells, etc.
15:06:11 <asn> - Coding the HS client side -- cells, key blinding, etc.
15:06:26 <asn> - Coding the service side -- more cells, desc uploads, time periods, etc.
15:06:35 <asn> - And finally wrapping all these things together.
15:06:46 <asn> So these are 5 steps. With lots of complexity hidden on the 5th step.
15:07:08 <asn> dgoulet, special and teor are currently working on the first task (the HSDir side)
15:07:16 <asn> i think dgoulet has done fair progress here!
15:07:21 * rjunior slaps iapazmino around a bit with a large fishbot
15:07:51 <dgoulet> descriptor encoding is basically done
15:08:02 <asn> i've been working on finalizing the second task (the relay/cells side), so that we can move there directly after we finish the first task.
15:08:13 <special> I would enjoy having some code to write for it
15:08:21 <special> but that's a separate topic
15:08:24 <asn> so this is the current state of affairs kind of.
15:08:37 <nickm> ack
15:08:59 <asn> nickm: any questions maybe? otherwise, we can proced to the HSDir implementation, where maybe dgoulet/special want to discuss somnething.
15:09:22 <dgoulet> I basically want to discuss what's in your email
15:09:35 <asn> ack
15:09:58 <dgoulet> (the changes on the descriptor format don't need much discussion, we just need to update the proposal with them)
15:09:59 <asn> special: what do you mean "having some code to write for it"? you want some task to be assigned to you?
15:10:38 <nickm> dgoulet: is there  a  patch for me on that?
15:10:53 <nickm> are the proposed changes to the cells all contained in asn's email?
15:10:57 <dgoulet> nickm: asn has all the fixes in some branch but we need to figure out the latest open questiosn
15:11:26 <asn> i have some small mainly-cosmetic fixes on a branch, but I'm waiting for the big design decisions that are on my email.~
15:12:11 <asn> (The small fixes I have so far are stuff like: Make more cells extensible, Kill TAP, Replace sha256 with sha3 and KDF with SHAKE, etc.)
15:12:17 <dgoulet> 1) Backward compat. Yes or No :)
15:13:34 <asn> 2) Do IPs really need to know the intro point encryption key? Should we just forget about UPDATE-KEYS-SUBCMD?
15:13:47 <asn> these are basically two big topics right now.
15:14:40 <dgoulet> I did post my "potentially mistaken" analysis and opinion on those two ^, I'm happy to debate
15:14:42 <special> I'm leaning against backwards compatibility. The argument about already partitioning at the HSDirs is a solid one, although it's possible that we'll ship relay-side support a version later than hsdir
15:15:07 <nickm> so, compability with old HSDirs just can't happen with this design.
15:15:18 <special> correct
15:15:19 <dgoulet> correct
15:15:19 <nickm> Are there any issues around compatibility with old RPs?
15:15:22 <special> no
15:15:49 <nickm> So it's all whether new-style HSs should be able to introduce at existing relays?
15:16:01 <asn> also RPs backwards compatibility is an issue, no?
15:16:13 <asn> why is it not an issue?
15:16:15 <dgoulet> asn: it's not, payload doesn,t change
15:16:36 <dgoulet> 4.3. Using legacy hosts as rendezvous points
15:17:11 <asn> there were some TODO items about making those cells extensible etc.
15:17:18 <asn> which they are not  currently
15:17:19 <asn> but OK
15:17:28 <dgoulet> [TODO: make this extensible]
15:17:29 <dgoulet> :)
15:17:30 <asn> the payload is indeed the same.
15:17:51 <dgoulet> nickm: so yes it's really at the IP side here the compat
15:18:20 <nickm> we _should_ make sure that when the relay crypto format changes, HSs and clients will able to adapt.  But that's a separate issue I hope.
15:19:36 <nickm> now, LEGACY_EST_INTRO and LEGACY_INTRODUCE1 aren't actually new cells, right?  They are just the old ESTABLISH_INTRO and INTRODUCE1 cells, as used by new clients and servers.
15:20:11 <dgoulet> no new cell for those
15:20:59 <asn> they are not new cells yes, but we will need to write code and logic to fit the new info into the old cell format.
15:21:47 <asn> and also to parse this new info on the HS side.
15:22:56 <dgoulet> asn: are you still for or against backward compat or undecided?
15:22:57 <nickm> one option is, as you suggest, to try to get the HSDir stuff into early 0.2.9, and see where we are at when we get the cells to a point where we'd turn on relay support for them.
15:23:35 <nickm> If everybody's supporting the new HSDir stuff, then backward compat might make sense.
15:23:38 <asn> dgoulet: undecided. I'm trying to first understand _exactly_ how much effort it will be.
15:23:49 <dgoulet> nickm: wait
15:24:03 <dgoulet> nickm: hsdir support _has_ backward compat stuff in the descriptor for instance
15:24:10 <dgoulet> so we need to decide prior to that being shipped
15:24:16 <nickm> ah :(
15:24:48 <nickm> my thought is: the tor network is big, and a lot of it updates slowly.  Backward compat isn't that hard.  IMO it's a good idea.
15:24:49 <dgoulet> imo we should aim at relay and hsdir support in 029 (big goal but I think doable with the dev power we have)
15:25:12 <special> the implementation doesn't seem too hard
15:25:22 <dgoulet> trunnel will help us a lot for relay cell
15:25:23 <asn> yes i think i'm lining up with nickm in the backwards compat front.
15:25:41 <special> testing it well is a bit difficult, and it's a lot of ugly risky logic to keep
15:26:18 <asn> i feel that trying to coordinate a bug-free incremental deployment, will be much more stressful than coding the backwards compatibility stuff.
15:26:30 <Mattx> Hey guys!
15:26:31 <asn> which don't seem that much right now to me.
15:26:42 <dgoulet> are we worried of "an attacker" holds up on a bunch of relay tor version so to force IP being old crypto... hrm
15:26:50 <special> how would you feel about a consensus parameter to turn off the legacy IP support?
15:26:55 <dgoulet> asn: we have to do that for hsdir anyway :S
15:27:10 <Mattx> I've been trying to config tor with a single node + the exit node. But I haven't found any recent article explaining how to do so. Do you have a resource for me to read?
15:27:25 <dgoulet> Mattx: please ask this in #tor, thx
15:27:34 <Mattx> ok, np
15:27:44 <asn> dgoulet: hm true
15:28:26 <nickm> A consensus paremeter for "don't pick or use legacy IPs" would be fine.
15:28:34 <nickm> IMO
15:28:37 <asn> when would we use that?
15:28:50 <special> when we feel like enough have upgraded and don't want that code in use anymore
15:28:58 <asn> ack
15:29:01 <special> and then we can rip it out without worry about old services
15:29:04 <nickm> once X% of the network has upgraded, we can turn on that switch, and remove support for legacy IPs from hidserv and client side.
15:29:09 <asn> right
15:29:12 <asn> i'm fine with this
15:29:14 <dgoulet> I would be ok with that
15:30:03 <nickm> +1
15:30:14 <dgoulet> so backward compat it is + consensus param switch
15:30:17 <asn> i feel that the backwards compatibility support will require like 8 new functions of medium-complexity.
15:30:32 <dgoulet> won't be that crazy just annoying :)
15:30:35 <asn> and some strategically placed if clauses.
15:30:42 <asn> it will be annoying agreed. also testing it will be painful.
15:30:49 <dgoulet> yup testing...
15:30:50 <Yawning> hi
15:30:57 <special> remind me, do we have a reliable way to tell if a relay supports being a 224-style IP?
15:31:10 <dgoulet> special: 0.2.xx+ ? :)
15:31:11 <asn> special: if (relay_version >= X) { ... }
15:31:19 <asn> i guess...
15:31:47 <asn> #action do backwards compatibility + consensus parameter to switch it off when network has upgraded
15:31:47 <dgoulet> that's going to be fun with services with different views of the network :)
15:31:52 <asn> (amidoingitright)
15:32:15 <dgoulet> we go to 2) ?
15:32:22 <asn> im ok with going to 2).
15:32:25 <special> agreed
15:32:45 <asn> nickm: any thoughts on (2)?
15:32:59 <special> I read the mailing list thread and then re-read those parts of the spec, and I agree with all of the conclusions.
15:33:22 <special> (so, IPs don't need to know the encryption key, and MAINT_INTRO isn't useful)
15:33:28 <dgoulet> special: which one, asn's, mine or an intersection of both? :)
15:33:31 <asn> nickm: basically, why do we go to all that length to pass the intro point encryption keys to the intro point.
15:33:50 <nickm> So, the idea was that the encryption keys can change.
15:33:53 <asn> nickm: and also add a new cell type to be able to dynamically update the encryption key.
15:34:05 <nickm> And the reason for doing that was so that we can limit the size of the replay cache.
15:35:39 <asn> i see
15:35:46 <asn> interesting reason.
15:36:14 <asn> nickm: do you still think it's worth doing?
15:36:23 <nickm> it -is- more complexity.
15:36:26 <asn> are the replay caches ready to bust in IPs?
15:36:33 <dgoulet> well we can still control that where whenn the replay cache is filled up, we can rotate IP keys, update descriptor
15:36:48 <nickm> Maybe check with fb to see how the replay caches are holding up in practice with them?
15:36:50 <dgoulet> client will have to refetch
15:36:53 <asn> dgoulet: then clients will need to refetch the desc, but that's not tooo bad.
15:36:56 <special> dgoulet: this also involves tearing down the circuit and building a new one
15:37:15 <dgoulet> yes but I argue that it's less complex and little load then this update key mechanism
15:37:17 <asn> nickm: interesting :)
15:37:24 <asn> dgoulet: i think so too right now.
15:37:39 <special> I dislike the two-state ESTABLISH_INTRO and then set the encryption key
15:37:53 <special> even more than I dislike having MAINT_INTRO
15:38:00 <dgoulet> I'm  also worried on how it's going to work on the client side... caching enc_keys temporarily? ...
15:39:00 <asn> my intuition right now tells me:
15:39:18 <asn> - Get some figures on replay caches. Are they actually ready to bust? (when not DDoSed)
15:39:37 <asn> - If replay caches are not a huge priority, simplify the design to the most minimal thing. So no enc keys reach the IPs.
15:39:39 <nickm> well, maybe think about dos too
15:39:47 <asn> nickm: :)
15:39:50 <asn> nickm: :)
15:39:53 <asn> nickm: :(
15:39:58 <asn> but yes i read you.
15:39:59 <dgoulet> lots of emotion
15:40:08 <nickm> tor developers care!
15:40:09 <nickm> ;)
15:40:32 <nickm> also maybe look at how often a client tries to talk to a HS, and fails because it has an old descriptor and the intro point or key has changed?
15:40:35 <dgoulet> we do control that with a limit of introduce now, which is not super optimal and easy for an attacker to make the HS rotate IPs
15:41:05 <nickm> I thought we used same IP, new key.
15:41:16 <Yawning> (is the replay cache issue a capacity thing?)
15:41:58 <Yawning> (Am I going to need to merge my A2 bloom filter code?)
15:41:58 <nickm> Yawning: I think so.
15:42:07 <nickm> bloom filters are only so good. :/
15:42:14 <dgoulet> nickm: I would have to confirm but we rotate IPs if that limit is reached, and I think there is an open ticket saying we should reconsider our old IPs we just throw out in the next round robin choice
15:42:23 <Yawning> well this is the double buffered one
15:42:26 <Yawning> for moving datasets
15:42:47 <nickm> I just had an idea for another design but maybe it sucks.
15:43:04 <Yawning> a 1 MiB filter (technically 2 MiB) would hold more than enough at an acceptable false postivie rate I think
15:43:24 <dgoulet> but the question is what do we do when that limit is reached
15:43:25 <nickm> keep the encryption keys constant, but have an epoch counter that has to appear in the encrypted and unencrypted parts of the introduce.  It has to match in both.  It starts at 0.
15:43:30 <asn> Yawning: worth thinking about i think.
15:43:34 <nickm> If the counter is too low, the intro says "nope, current counter is N."
15:43:44 <nickm> (or too high)
15:44:01 <nickm> when the hs wants to, it increments its counter, tells the IP, and throws away its replay cache.
15:44:21 <nickm> If the HS gets something with a bad counter, it tosses it
15:44:27 <nickm> not sure whether this is actually ok.
15:45:07 <special> is there any way for a client to guess at the current epoch counter value, or does it have to assume 0 to start?
15:45:24 <nickm> assume 0 I guess.
15:45:37 <nickm> I don't much like this design either, mind you
15:45:40 <Yawning> asn: https://home.kookmin.ac.kr/~mkyoon/publications/2010TKDE.pdf
15:45:41 <special> so that will add a client/IP round trip :/
15:45:50 <special> any time the counter has rotated
15:46:09 <nickm> Yup.  Though you could upload a new HSDesc.
15:46:12 <nickm> and put it in there I guess
15:46:29 <dgoulet> basically the revision-counter at that point for the desc.
15:46:42 <asn> kind of yes
15:46:55 <nickm> another option is to put back in a timestamp of some low granularity, and convince ourselves that we have figured out how to do it in a 100% safe way.
15:47:00 <special> this also leaks popularity, I guess, depending on the algorithm for when to increase the counter
15:47:00 <nickm> But that seems unlikely and hard
15:47:09 <special> maybe we're already leaking that by updating the descriptor, though
15:47:29 <dgoulet> popularity or dos, yeah
15:48:05 <asn> hmmm seems like we've hit a design issue here...
15:48:14 <asn> some good ideas floating around though.
15:49:06 <dgoulet> if we drop the update enc. keys, we need to handle the replay cache filling up differently, one way is to inform the IP/client and the other is to upload new desc with new keys and re-circuit to the IPs
15:49:07 <special> maybe we just need to make the replay cache more efficient, and convince ourselves it's good enough
15:49:09 <dgoulet> choose our poison :)
15:49:25 <Yawning> special: I linked an efficient desing :P read the paper
15:49:40 <asn> are we very afraid of INTRODUCE1 replay attacks?
15:49:43 <Yawning> catch is, it has false positives, but not false negatives
15:49:50 <special> Yawning: yeah, bloom filters are the super efficient way
15:49:53 <asn> what can the attacker do?
15:50:12 <Yawning> special: plus can be made stable
15:50:16 <Yawning> even for dyanmic data
15:50:25 <nickm> if you can replay an introduce1 cell, you can make the HS open a zillion connections to the RP, I guess.
15:50:26 <asn> and even if the attacker fills our cache, and we clean it up, and he manages to sneak in a replay, what does the attacker get?
15:50:41 <nickm> oh interesting.
15:50:50 <nickm> so maybe we'd only try to rate-limit replays?  Scary.
15:50:53 <nickm> But maybe safe.
15:50:53 <asn> because if we clean it up, he can only sneak in a single replay, before we put him in the cache again.
15:51:00 <nickm> Better get roger involved with that one.
15:51:10 <asn> better get this rogered.
15:51:27 <asn> (i have to leave in 9 mins unfortunately!!)
15:51:52 <dgoulet> asn: email back your thread with an armadev in cc?
15:51:54 <asn> i can read the logs here, and write some minutes on tor-dev, to move this forward
15:51:56 <asn> yes
15:52:01 <nickm> ok.  I think our answer for #3 and #2 is going to be similar then.
15:52:04 <asn> yes yes
15:52:08 <dgoulet> cool
15:52:33 <asn> alright
15:52:37 <asn> we did some progress here i feel
15:52:47 <nickm> One more design: add a way for IPoints to give different replies for "HS disappeared" and "HS moved", and let the latter be a signed thing, and have the HS give the IP one of those when it closes the circuit on purpose ot open another.
15:53:05 <Yawning> (also oops, sorry I slept through the meeting)
15:53:34 <nickm> were we using meetbot this time or did we forget?
15:53:37 <asn> we did.
15:53:44 <asn> anything else to discuss before The End?
15:53:49 <nickm> not afaik
15:54:15 <special> (we could make replaycache much more memory efficient than it currently is, even with less than bloom filtering)
15:54:16 <asn> wrt prop224, there is still a big deisgn issue of "What encoding for the onions? Should we fit in the onion adderss a checksum, a version field, and some emojis?" etc.
15:54:21 <nickm> somebody put the meetbot link on the wiki at https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/MeetingSchedule ?
15:54:26 <asn> nickm: will do
15:54:31 <special> asn: I have much thinking on that front
15:54:39 <special> nothing groundbreaking unfortunately :/
15:54:44 <nickm> asn: The bikeshed should be painted like the TARDIS. :)
15:54:46 <dgoulet> we could schedule another meeting for that question
15:54:50 <asn> nickm: special: ack
15:54:56 <asn> i think this is a question that can be handledf in the end.
15:54:57 <special> but I can at least write a mail to start the conversation
15:54:59 <dgoulet> but that will be needed before the service side is implemented
15:55:06 <nickm> let's start by everybody writing up their favorite ideas
15:55:38 <asn> :)
15:55:52 <nickm> somebody endmeeting so I can eat lunch? :)
15:55:57 <asn> #endmeeting