22:00:08 #startmeeting 22:00:08 Meeting started Mon Feb 8 22:00:08 2016 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:00:08 Useful Commands: #action #agreed #help #info #idea #link #topic. 22:00:12 hello meetbot 22:00:18 hello my comrades 22:00:33 We're here to discuss prop#252, prop#260, and prop#255 22:00:36 nickm: Ok, thanks. (I got confused about "remaning" xD) 22:00:43 we're going to talk about hidden service ideas today/etc/ok 22:00:48 teor said the important bits 22:00:55 hi there 22:01:23 * asn_ around 22:01:27 So, could some informed person summarize the consensus, and the open questions? 22:01:31 * dgoulet here 22:01:34 (With reference to existing load-balancing techniques like OnionBalance) 22:02:37 The consensus is that tor hidden services are high-latency and high-overhead, and (at least until 2015) have been hard to scale. 22:03:18 We've made some efficiency changes in the tor code, and tools like OnionBalance allow multiple tor instances to handle a single .onion address. 22:04:32 But for many clearnet sites looking to add a .onion, location anonymity is useless, and latency and speed are vital. 22:04:42 * isabela is lurking 22:05:26 So there are proposals to have onion (hidden) services stop hiding their location for those sites, and connect directly, 22:06:03 (prop#252 and prop#260) 22:06:21 * asn_ follows 22:06:34 please other folks keep talking; I am on the phone, so sorry 22:06:37 There's also a proposal to have hidden or onion services handoff the rendezvous part of the protocol to another tor instance (prop#255) 22:06:52 And in the words of Pratchett: "Then it gets a bit technical." 22:07:27 (End summary) 22:07:42 briefly, what is the difference between 252 and 260? 22:08:17 252 has the onion service open an ORPort and accept extend requests from clients who have built a 3-hop path 22:08:52 260 has the onion service do the full rendezvous protocol, but connect directly to the introduction and rendezvous points, rather than making a 3-hop path 22:09:09 are they complementary or at odds with each other? 22:09:31 They address different use cases: 22:09:59 252 is good if you can expose a port on a public IPv4, and want high speed, but is harder to load-balance 22:10:51 260 is slightly slower to initiate, but doesn't need an open port, and can load balance using 255 or OnionBalance 22:11:19 They are at odds with each other because they split the anonymity set 22:11:34 prop#252 can load balance by just listing very many of these special non-relay intro points, yes? 22:11:35 and because we will probably pick one to build first, leaving the other one not built first 22:12:12 mikeperry: yes, prop#252 can balance that way, but the scaling factor is smaller 22:12:27 mikeperry: i think you'd cap out at..however many we want to fit in an hsdesc. ten or twenty or something. 22:13:02 252 is also compatible with the "publish different descriptors to different hsdirs" trick 22:13:04 The client anonymity set is somewhat split, but the hidden service anonymity set is more of a concern, because it's smaller 22:13:54 so prop#260 also has a section about splitting the anonymity set. are there any obvious vectors to do this? it doesn't seem to list any 22:14:31 I can see obvious service-side anonymity set splitting, but I don't see obvious client-side anonymity set splitting 22:14:46 The connection latency is likely to be observably different between 4-5 hops and 6-8 hops 22:15:26 The good part is that exit latency is also 4-5 hops, so 252 and 260 hide in there on the client side 22:15:35 The bad part is that hidden services stick out more 22:15:46 (is teor defining hop as something other than 'relay'?) 22:16:14 armadev: I was thinking "connection" 22:16:32 right. psiphon uses this metric but it will confuse other people because of fencepost counting issues. 22:16:47 (normal tor circuits are three hops: entry, middle, exit.) 22:18:01 circuit use is very different for prop#252 though, since it omits the rend circuit. so it is more than just RTT latency there 22:18:22 mikeperry: yes, it looks very much like an exit connection 22:18:23 armadev: FYI I merged the "publish different descriptors to different HSDirs trick into onionbalance", but it's not released yet https://github.com/DonnchaC/onionbalance/pull/29 22:19:03 donnchac: exciting! is there one design doc i should read for onionbalance, when i get time to do all these actually fun things? last i checked you had to sort of piece it together yourself. 22:19:08 teor: an exit connection with an extra extend RTT. so maybe different. one extra cell RTT in every usage 22:19:21 Yes, unfortunately 22:19:56 mikeperry: though if you run a fast relay for your single onion service, it likely has those tls connections open already. so you save some there, sometimes but not always. 22:20:17 actually, two RTTs. first the intro fetch, and then the extend, and then normal application session 22:20:24 teor: so, we seem to have lost our nickm. do you have a handle on who has opinions about these various proposals? 22:20:55 mikeperry: by "intro fetch" you mean "hsdesc fetch"? 22:21:01 armadev: Your in luck! There's a design doc which should be mostly up to date http://onionbalance.readthedocs.org/en/latest/design.html 22:21:09 err yeah, the hsdir fetch to get the special intro lines. sorry 22:21:13 252 makes me a bit nervous - protocols that say "negotiate a port to open and then connect there" can be error prone. consider, for example, firewall rules that need to be (dynamically?) tweaked to allow connection to that orport 22:21:28 armadev: opinions range from "let's get it done 6 months ago" to "I'm not sure about the implications" 22:21:41 ww: 252 is designed for a world where big sites, like facebook, might as well run relays to help the world 22:22:06 teor: in terms of the people who are going to build it, which one do they want to build? 22:22:17 (it seems like 260 is super easy, right?) 22:22:38 ww: and also the need to take reflection-based portscanning into account 22:22:55 prop#252 does not require anyone to run any public relays. it just says it might be nice if they did 22:23:04 yep 22:23:11 260 is essentially done in #17178. It looked easy on the surface, but there were some assumptions in the source we needed to fix. 22:23:16 * isis apologises for being late and reads scrollback… 22:23:33 where as in prop#260, you probably get the best performance if you *do* run your own relays for your chosen IP and RPs 22:23:42 and keep them close to your infrastructure 22:24:18 and they would have to be public, in that case 22:24:25 I like those incentives much more :) 22:24:25 mikeperry: choosing set introduction points isn't a feature I've implemented yet 22:24:42 mikeperry: for your chosen IP. you, the service, don't pick the RP. 22:24:43 (or had considered) 22:24:52 DonnchaC: will try to review https://github.com/DonnchaC/onionbalance/pull/29 soon. 22:25:46 armadev: ah, hrm. not as good. (also, sorry for the braindamage. I am slightly distracted and low on sleep :/) 22:25:48 asn_: It's merged in develop, but a review would be great. It has a few tests, so hopefully isn't completely broken 22:25:49 mikeperry: chosen Intro Points lead to a denial of service risk, but that's implicit in the proposal anyway 22:26:21 (so sorry, I have an emergency I need to take care of, will read the logs once I come back) 22:26:30 teor: so, for 260, we in theory can handle some DoS attempts better, by choosing not to respond to those intro cells, just like we do with normal onion services now 22:26:56 teor: and for 252, it's not just one less hop, it's fewer stops in the rendezvous protocol, right? so a faster handshake *and* a faster resulting circuit? 22:27:39 i feel terrible being the one talking here, since i haven't read the proposals in months. please somebody else talk. :) 22:27:42 252 and 260 both have 3 relays between client and onion service 22:28:00 252 avoids the entire intro-rendezvous protocol 22:28:07 so setup latency is faster 22:28:36 so basically one of them does nat punching and the other doesn't need to 22:28:40 mikeperry: #18284 22:28:45 armadev: yes 22:29:32 and in a world where we build both, what happens? 22:30:10 a) some harm in anonymity to the clients, since maybe an observer of them could guess 'what kind' of onion service they're visiting 22:30:28 b) we spend some time implementing a thing that is maybe only incrementally useful 22:31:04 c) onion services are faster to reach, making them quicker to mainstream for things like facebook, especially if facebook switches 6 figures of users over in a day 22:31:17 s/are/can be configured to be/ 22:31:23 could 252 be made to support something like aliases (a la /etc/hosts) where the client gives a locally meaningful name to what is in effect a fourth relay? (or is that just a bad idea?) 22:31:49 because they look so much like normal exits... 22:33:02 I guess we could allow out-of-band descriptor delivery by accepting hsdescs via the control port.. 22:33:11 oh, and d) we delay getting to the good stuff in prop#224, like the new keys and making it so hsdirs can't be jerks so much 22:33:18 armadev: I think building both just works, because Facebook (and some other sites) have enclaves where opening a port is hard 22:33:31 but onion keys are supposed to rotate often. like once every 2 weeks, I think? 22:33:32 And others will just want to open a port and have it work 22:33:40 teor: oh! so alec would actually have trouble using 252! 22:33:50 (and prop#252 lists the onion key in its hs descriptor) 22:34:06 armadev: yeah, it's much harder for him 22:34:18 well, screw 252 then :) 22:34:53 (i still find 252 more elegant) 22:35:07 but it is more work because it involves teaching clients how to handle a new thing 22:35:12 armadev: if everything goes well with my "getting paid to work on tor" strategy, then it will be 252, 260, and parts of 224 22:35:17 *glances at scrollback* 22:35:22 we will probably see lots of folks who just want NAT traversal to start using prop#260. not sure if that is a plus or a minus 22:35:27 gotta pack 22:35:28 If it doesn't, it will be 252 and 224, I guess 22:35:46 (I think 260 is fine) 22:36:29 ok, so we lost nickm and dgoulet. anybody else here going to be involved in picking or building any of these? 22:36:36 mikeperry: I flipped back and forth on that, and ended up at "anonymity loves company" 22:36:50 i've been reviewing prop260 22:37:09 mikeperry: it is super easy to hack your onion service to make fewer hops. the bag is much too small for the cat. 22:37:13 i've also doen some review for prop255 but i don't know what's the current state tbh 22:37:16 teor: yeah, I agree. 22:37:27 I hope TvdW (not here) will finish unit tests for 255 and I will review it 22:37:31 ah yes unit tests 22:38:07 armadev: the NRL is interested in research on 252 (and to a lesser extent 260, 255, OnionBalance) 22:38:18 to clarify, the prop#252 connections going out from the "exit" node aren't going to look like normal exits, but will most likely look like SOS conns because the client sends an extra EXTEND to tell the exit to connect to the SOS 22:38:41 isis: yes, they are distinguishable 22:38:52 * ww nods 22:38:55 teor: one of the other background ideas in 252 was that let's encrypt would basically ship with it. the let's encrypt users run a webserver already, so they have incoming connections. 22:39:22 (modulo "they have one, that doesn't mean a second is free" responses) 22:39:29 armadev: doing it right is hard, we discovered a few assumptions in the code, and a potential local address/port scanning attack against 260 22:39:32 while looking into a prop@247 prototype, I was deeply frustrated to discover that the tor control protocol is forbidden from building/attaching hidden service circuits. Does/will prop#255's implementation take this into account or fix it? 22:39:42 prop#247 too 22:40:20 armadev: that would be nice to have an easy set-up via lets encrypt 22:40:45 forbidden? i think it's just that nobody ever wrote down a plan in enough detail. 22:40:52 I see a port scanning attack against prop#252, but prop#260 is all outbound connections. how does that work? 22:40:53 mikeperry: I don't know. Now we have ephemeral hidden services over the control port, it makes sense 22:41:16 mikeperry: maybe you tell the onion service the scan target as your rend point 22:41:24 mikeperry: client sends rendezvous cell with 127.0.0.1 as the address, watches for error or response latency 22:41:39 ugh, intro cell with 127.0.0.1 as rend address 22:41:54 then rinse, lather, and repeat per port / address 22:42:18 heh, we don't check rend dests against the consensus already? that seems scary 22:42:46 ok. i saw dgoulet post a list of n steps to finish prop224 earlier. i've seen some tickets about shared randomness. when can we kill this horrible arms race with bad hsdir relays? and is anything more important than that? 22:43:01 * isis likes the prop#260 idea better, if we had to choose one or the other 22:43:01 mikeperry: we weren't even checking rend or extend connections against private addresses until after the TLS connect 22:43:04 mikeperry: no, and we can't, because not every tor has the same view of the network as every tor 22:43:47 isis: that's good, because prop#260 is ready in #17178, and prop#252 is awaiting funding before it starts 22:44:08 under what circumstances is it valid to be a public relay that cannot be reached on its official orport? 22:44:23 don't the dirauths reject such relays as unreachable? 22:44:36 mikeperry: eventually 22:45:10 but extend requests can go to any address, not just public relays 22:45:15 i'm not really understanding what benefit prop#252 would have for sites like facebook over prop#260… 22:45:37 isis: one fewer interaction during the set-up phase. 22:45:46 speeeed 22:45:51 in exchange for requiring the service to be reachable 22:46:11 but we lose NAT punching and ease-of-configuration 22:46:16 yes, we do 22:46:36 well, we don't lose it. the people who can't do it don't do it. :) 22:46:55 isis: prop#252 is a non-starter for Facebook itself, because they use an enclave without external ports 22:47:05 are we sure facebook doesn't want prop#252 because they effectively need NAT punching? 22:47:10 if i were facebook, and i wanted to help tor by running some big relays in addition to my hidden service, i probably would *not* run those relays on the same host/cluster/address/port/whatever 22:47:11 how much speed we win with prop252? maybe we can use http://ec2-54-92-231-52.compute-1.amazonaws.com/substeps.png to find out. 22:47:37 alecmuffett has been very clear they want prop#260, and preferably in 0.2.6 :-) 22:47:43 teor: right 22:47:47 asn: ooh, science! bring it! 22:48:17 asn: actual facts and figures. Someone had to do it eventually... 22:48:39 then I think I agree that we should not distract ourselves with prop#252. 22:49:13 I also like the fact that aside from RTT (which will be highly variable), prop#260 looks a more like full HS usage 22:49:22 from the client side 22:49:24 i agree as well about prop252. at least for the short-term. 22:49:49 i mean, if NRL has funding to do prop252-esque research, that's great. 22:50:14 i would like to read the proposals before claiming i have an opinion, but my current thought is to avoid distractions to let us focus on prop#224 22:50:37 I have heard that's the case. But any research would also involve 260, 224, and maybe 255 and OnionBalance. 22:50:38 it sounds like 252 is a distraction. it sounds like 260 is mostly done so finishing it can't hurt that much. 22:50:59 armadev: I agree, and it gets us 90% of the desired functionality at 20% of the cost. 22:53:11 teor: for the equivalent thing on the client side, in tor2web, nickm really wanted it to be a compile-time ifdef thing 22:53:22 i hope we are not intending to do that for the service side? should we un-do that decision for the client side? 22:53:38 the original meeting on the wiki page mentioned prop#246. are we dropping that one? (also: can it be made into a behavior optimization instead, at a later date, if we keey the crypto the same as the default 224 case but change the client and server logic to re-use the hsdir circuit for an introduce cell, if one of the intro points matches the current hsdir)? 22:54:02 armadev: we talked about it and I think we decided that a per-tor-instance option was sufficient. 22:54:07 if that is possible, it might be one more option for cutting out a circuit build out of prop#260 later, if we really wanted to 22:54:12 Not sure about undoing the tor2web ifdef 22:54:37 mikeperry: we put 246 into needs-research, too many open questions 22:54:44 but yes, that is an option 22:55:16 prop#255 is mostly done, and it gets us rendezvous handoff and rendezvous approver via the control port, both are useful features 22:55:26 i remember finding prop#246 to be sketchy in that it rolled back too much of the modularity in the original hs design 22:55:43 (making things rigid in exactly the wrong places) 22:56:07 re 22:56:10 so sorry. 22:56:27 telephone call of urgentness that you would not belive, but of which I assure you. 22:56:29 yeah. I didn't like that it baked the rigidity into the protocol by changing the crypto. It also didn't explain why it wanted to change the crypto. I don't think it has to, if all it wants to do is cut RTTs 22:56:36 What conclusions do we have? 22:56:49 and avoid an extra intro circuit build 22:57:09 We like the idea of finishing prop#260 22:57:28 And I like the idea of finishing prop#255 22:57:36 * nickm nods sagely, as if he knew 22:57:51 We wonder if anything more will be be a distraction from prop#224 22:58:12 Unless, of course, it comes with funding attached (which is possible for prop#252) 22:58:15 to put it more strongly, we suggested that "but that would delay prop224" is a good argument for not doing things 22:59:35 nickm: also, we noted that prop#252, while giving better speed, would not actually be usable by some of the big onion service providers, because they're unable to receive inbound connections. 23:00:02 money will not make anything happen faster unless it funds a whole new developer for the duration of prop#224. I doubt prop#252 funding will be enough for that 23:00:22 also, if there is prop252 funding, we should use it to implement 224 faster :) 23:00:30 I agree on the proposition that prop#224 is rolling along like a thing rolling slowly and fitfully downhill, which we should not obstruct 23:01:01 armadev: I'll see what I can do 23:01:48 is there anywhere a clear concise comparison of the performance, latency, complexity, etc differences between 252 and 260? i did not find this in the 260 proposal. 23:02:04 i guess that is something we would get from more research on 252. and should not delay finishing 260. 23:02:23 armadev: not really, and yes, actual figures will require research / implementation 23:03:10 teor: declare victory with prop#260? say it counts instead? (maybe offer that it becomes slightly more 252-like if we decide to do 246 for it, but that is also a later optimization? :) 23:03:13 sections 2 and 6 are about as good as it gets right now 23:04:03 I think even strudying prop#252's performance is also a waste. such a person could be studying performance of prop#224 and prop#247 23:04:19 mikeperry: that depends on the funders. But we do have some flexibility. 23:05:36 teor: yeah, i didn't mean actual figures, i meant being very clear about what the design differences are between them. like, exactly what is missing from one or the other. 23:06:00 so sorry for having been away; feeling ashamed! What if anything can I do to help stuff advance here other than "read the backlog" and "be smart" ? 23:06:01 if you're following along closely you can figure it out, but i want to not have to think that much while reading the proposal :) 23:06:55 armadev: I think section 2 of prop#260 is what you're asking for. How could I make it better? 23:09:40 i found "Connection latency is higher" to be an ambiguous phrase 23:09:49 i didn't realize the first three times that you meant the rendezvous handshake 23:09:54 when I read all the backlog, what conclusion should I reach? 23:10:13 Tor good, spying bad? 23:10:18 Hey guys, I’m poking around the source code for tor, is there a design doc out there somewhere like the tor browser’s design doc? 23:10:19 well sure 23:10:36 smudkavi: oh wow, it's kind of complicated! 23:11:03 There is this old thing from 2003 http://www.onion-router.net/Publications/tor-design.pdf 23:11:04 nickm: nickm and dgoulet disappeared at the beginning, and teor and mike and asn and isis and a few others struggled onward. i think you should conclude that prop252 should wait, prop260 is basically done so why not finish it, 255 wasn't objectionable but nobody knew its details, and 246 was vaguely unsettling. 23:11:10 but a lto of time has passed since 2003 23:11:19 Haha, that’s kind of the answer I was expecting, many thanks it’ll give me some sort of direction at least! 23:11:36 smudkavi: be sure to track down the tor blog posts on "what changed since the 2004 paper". 23:12:07 smudkavi: and then of course https://gitweb.torproject.org/torspec.git/tree/ 23:12:26 smudkavi: https://blog.torproject.org/blog/top-changes-tor-2004-design-paper-part-1 https://blog.torproject.org/blog/top-changes-tor-2004-design-paper-part-2 https://blog.torproject.org/blog/top-changes-tor-2004-design-paper-part-3 23:12:48 is there a mininium amount of bandwidth that is needed for 0.2.7.6? 23:13:00 Oh wow, that’s a lot of information haha, thanks a lot! I’m going to dig into all of these 23:13:08 okay, so what is the difference between the different "onion but not hidden" proposals? 23:13:20 or should I stfu and #endmeeting? 23:13:57 nickm: 252 is faster for the handshake, but requires you to be reachable from the outside 23:14:18 260 only requires changes on the service side 23:14:19 essentially, the difference is that one does nat punching for you, at the cost of more steps in the protocol 23:14:31 also, yes, 260 is a much less intrusive change 23:15:35 and 255 is in here because it's about scaling, but it can be used on hidden or non-hidden services 23:16:03 it's a neat way of passing an intro response through the controller to another tor instance 23:17:08 at the cost, i assume, of even more latency in the handshake phase? 23:17:39 armadev: unfortunately, depending on the load of the introducing tor instance 23:18:02 If the introducing tor instance is heavily loaded, passing off the rendezvous might just be faster 23:18:15 hrmnmnm. 23:18:27 So first, since time has passed, my apologies and 23:18:28 #endmeeting