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