22:00:08 <nickm> #startmeeting
22:00:08 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
22:00:12 <nickm> hello meetbot
22:00:18 <nickm> hello my comrades
22:00:33 <teor> We're here to discuss prop#252, prop#260, and prop#255
22:00:36 <zerosion> nickm: Ok, thanks. (I got confused about "remaning" xD)
22:00:43 <nickm> we're going to talk about hidden service ideas today/etc/ok
22:00:48 <nickm> teor said the important bits
22:00:55 <DonnchaC> hi there
22:01:23 * asn_ around
22:01:27 <nickm> So, could some informed person summarize the consensus, and the open questions?
22:01:31 * dgoulet here
22:01:34 <teor> (With reference to existing load-balancing techniques like OnionBalance)
22:02:37 <teor> 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 <teor> 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 <teor> 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 <teor> So there are proposals to have onion (hidden) services stop hiding their location for those sites, and connect directly,
22:06:03 <teor> (prop#252 and prop#260)
22:06:21 * asn_ follows
22:06:34 <nickm> please other folks keep talking; I am on the phone, so sorry
22:06:37 <teor> 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 <teor> And in the words of Pratchett: "Then it gets a bit technical."
22:07:27 <teor> (End summary)
22:07:42 <ww> briefly, what is the difference between 252 and 260?
22:08:17 <teor> 252 has the onion service open an ORPort and accept extend requests from clients who have built a 3-hop path
22:08:52 <teor> 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 <armadev> are they complementary or at odds with each other?
22:09:31 <teor> They address different use cases:
22:09:59 <teor> 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 <teor> 260 is slightly slower to initiate, but doesn't need an open port, and can load balance using 255 or OnionBalance
22:11:19 <teor> They are at odds with each other because they split the anonymity set
22:11:34 <mikeperry> prop#252 can load balance by just listing very many of these special non-relay intro points, yes?
22:11:35 <armadev> and because we will probably pick one to build first, leaving the other one not built first
22:12:12 <teor> mikeperry: yes, prop#252 can balance that way, but the scaling factor is smaller
22:12:27 <armadev> 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 <armadev> 252 is also compatible with the "publish different descriptors to different hsdirs" trick
22:13:04 <teor> 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 <mikeperry> 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 <mikeperry> I can see obvious service-side anonymity set splitting, but I don't see obvious client-side anonymity set splitting
22:14:46 <teor> The connection latency is likely to be observably different between 4-5 hops and 6-8 hops
22:15:26 <teor> 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 <teor> The bad part is that hidden services stick out more
22:15:46 <armadev> (is teor defining hop as something other than 'relay'?)
22:16:14 <teor> armadev: I was thinking "connection"
22:16:32 <armadev> right. psiphon uses this metric but it will confuse other people because of fencepost counting issues.
22:16:47 <armadev> (normal tor circuits are three hops: entry, middle, exit.)
22:18:01 <mikeperry> 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 <teor> mikeperry: yes, it looks very much like an exit connection
22:18:23 <DonnchaC> 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 <armadev> 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 <mikeperry> teor: an exit connection with an extra extend RTT. so maybe different. one extra cell RTT in every usage
22:19:21 <teor> Yes, unfortunately
22:19:56 <armadev> 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 <mikeperry> actually, two RTTs. first the intro fetch, and then the extend, and then normal application session
22:20:24 <armadev> 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 <armadev> mikeperry: by "intro fetch" you mean "hsdesc fetch"?
22:21:01 <DonnchaC> 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 <mikeperry> err yeah, the hsdir fetch to get the special intro lines. sorry
22:21:13 <ww> 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 <teor> armadev: opinions range from "let's get it done 6 months ago" to "I'm not sure about the implications"
22:21:41 <armadev> ww: 252 is designed for a world where big sites, like facebook, might as well run relays to help the world
22:22:06 <armadev> teor: in terms of the people who are going to build it, which one do they want to build?
22:22:17 <armadev> (it seems like 260 is super easy, right?)
22:22:38 <mikeperry> ww: and also the need to take reflection-based portscanning into account
22:22:55 <mikeperry> prop#252 does not require anyone to run any public relays. it just says it might be nice if they did
22:23:04 <armadev> yep
22:23:11 <teor> 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 <mikeperry> 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 <mikeperry> and keep them close to your infrastructure
22:24:18 <mikeperry> and they would have to be public, in that case
22:24:25 <mikeperry> I like those incentives much more :)
22:24:25 <teor> mikeperry: choosing set introduction points isn't a feature I've implemented yet
22:24:42 <armadev> mikeperry: for your chosen IP. you, the service, don't pick the RP.
22:24:43 <teor> (or had considered)
22:24:52 <asn_> DonnchaC: will try to review https://github.com/DonnchaC/onionbalance/pull/29 soon.
22:25:46 <mikeperry> armadev: ah, hrm. not as good. (also, sorry for the braindamage. I am slightly distracted and low on sleep :/)
22:25:48 <DonnchaC> 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 <teor> mikeperry: chosen Intro Points lead to a denial of service risk, but that's implicit in the proposal anyway
22:26:21 <dgoulet> (so sorry, I have an emergency I need to take care of, will read the logs once I come back)
22:26:30 <armadev> 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 <armadev> 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 <armadev> i feel terrible being the one talking here, since i haven't read the proposals in months. please somebody else talk. :)
22:27:42 <teor> 252 and 260 both have 3 relays between client and onion service
22:28:00 <teor> 252 avoids the entire intro-rendezvous protocol
22:28:07 <teor> so setup latency is faster
22:28:36 <armadev> so basically one of them does nat punching and the other doesn't need to
22:28:40 <teor> mikeperry: #18284
22:28:45 <teor> armadev: yes
22:29:32 <armadev> and in a world where we build both, what happens?
22:30:10 <armadev> 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 <armadev> b) we spend some time implementing a thing that is maybe only incrementally useful
22:31:04 <armadev> 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 <armadev> s/are/can be configured to be/
22:31:23 <ww> 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 <ww> because they look so much like normal exits...
22:33:02 <mikeperry> I guess we could allow out-of-band descriptor delivery by accepting hsdescs via the control port..
22:33:11 <armadev> 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 <teor> armadev: I think building both just works, because Facebook (and some other sites) have enclaves where opening a port is hard
22:33:31 <mikeperry> but onion keys are supposed to rotate often. like once every 2 weeks, I think?
22:33:32 <teor> And others will just want to open a port and have it work
22:33:40 <armadev> teor: oh! so alec would actually have trouble using 252!
22:33:50 <mikeperry> (and prop#252 lists the onion key in its hs descriptor)
22:34:06 <teor> armadev: yeah, it's much harder for him
22:34:18 <armadev> well, screw 252 then :)
22:34:53 <armadev> (i still find 252 more elegant)
22:35:07 <armadev> but it is more work because it involves teaching clients how to handle a new thing
22:35:12 <teor> 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 <Yawning> *glances at scrollback*
22:35:22 <mikeperry> 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 <Yawning> gotta pack
22:35:28 <teor> If it doesn't, it will be 252 and 224, I guess
22:35:46 <Yawning> (I think 260 is fine)
22:36:29 <armadev> ok, so we lost nickm and dgoulet. anybody else here going to be involved in picking or building any of these?
22:36:36 <teor> mikeperry: I flipped back and forth on that, and ended up at "anonymity loves company"
22:36:50 <asn_> i've been reviewing prop260
22:37:09 <armadev> 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 <asn_> i've also doen some review for prop255 but i don't know what's the current state tbh
22:37:16 <mikeperry> teor: yeah, I agree.
22:37:27 <teor> I hope TvdW (not here) will finish unit tests for 255 and I will review it
22:37:31 <asn_> ah yes unit tests
22:38:07 <teor> armadev: the NRL is interested in research on 252 (and to a lesser extent 260, 255, OnionBalance)
22:38:18 <isis> 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 <teor> isis: yes, they are distinguishable
22:38:52 * ww nods
22:38:55 <armadev> 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 <armadev> (modulo "they have one, that doesn't mean a second is free" responses)
22:39:29 <teor> 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 <mikeperry> 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 <mikeperry> prop#247 too
22:40:20 <teor> armadev: that would be nice to have an easy set-up via lets encrypt
22:40:45 <armadev> forbidden? i think it's just that nobody ever wrote down a plan in enough detail.
22:40:52 <mikeperry> I see a port scanning attack against prop#252, but prop#260 is all outbound connections. how does that work?
22:40:53 <teor> mikeperry: I don't know. Now we have ephemeral hidden services over the control port, it makes sense
22:41:16 <armadev> mikeperry: maybe you tell the onion service the scan target as your rend point
22:41:24 <teor> mikeperry: client sends rendezvous cell with 127.0.0.1 as the address, watches for error or response latency
22:41:39 <teor> ugh, intro cell with 127.0.0.1 as rend address
22:41:54 <teor> then rinse, lather, and repeat per port / address
22:42:18 <mikeperry> heh, we don't check rend dests against the consensus already? that seems scary
22:42:46 <armadev> 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 <teor> mikeperry: we weren't even checking rend or extend connections against private addresses until after the TLS connect
22:43:04 <armadev> mikeperry: no, and we can't, because not every tor has the same view of the network as every tor
22:43:47 <teor> isis: that's good, because prop#260 is ready in #17178, and prop#252 is awaiting funding before it starts
22:44:08 <mikeperry> under what circumstances is it valid to be a public relay that cannot be reached on its official orport?
22:44:23 <mikeperry> don't the dirauths reject such relays as unreachable?
22:44:36 <teor> mikeperry: eventually
22:45:10 <teor> but extend requests can go to any address, not just public relays
22:45:15 <isis> i'm not really understanding what benefit prop#252 would have for sites like facebook over prop#260…
22:45:37 <armadev> isis: one fewer interaction during the set-up phase.
22:45:46 <asn_> speeeed
22:45:51 <armadev> in exchange for requiring the service to be reachable
22:46:11 <isis> but we lose NAT punching and ease-of-configuration
22:46:16 <teor> yes, we do
22:46:36 <armadev> well, we don't lose it. the people who can't do it don't do it. :)
22:46:55 <teor> isis: prop#252 is a non-starter for Facebook itself, because they use an enclave without external ports
22:47:05 <mikeperry> are we sure facebook doesn't want prop#252 because they effectively need NAT punching?
22:47:10 <ww> 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 <asn_> 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 <teor> alecmuffett has been very clear they want prop#260, and preferably in 0.2.6 :-)
22:47:43 <isis> teor: right
22:47:47 <armadev> asn: ooh, science! bring it!
22:48:17 <teor> asn: actual facts and figures. Someone had to do it eventually...
22:48:39 <mikeperry> then I think I agree that we should not distract ourselves with prop#252.
22:49:13 <mikeperry> 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 <mikeperry> from the client side
22:49:24 <asn_> i agree as well about prop252. at least for the short-term.
22:49:49 <asn_> i mean, if NRL has funding to do prop252-esque research, that's great.
22:50:14 <armadev> 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 <teor> I have heard that's the case. But any research would also involve 260, 224, and maybe 255 and OnionBalance.
22:50:38 <armadev> 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 <teor> armadev: I agree, and it gets us 90% of the desired functionality at 20% of the cost.
22:53:11 <armadev> 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 <armadev> 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 <mikeperry> 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 <teor> armadev: we talked about it and I think we decided that a per-tor-instance option was sufficient.
22:54:07 <mikeperry> 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 <teor> Not sure about undoing the tor2web ifdef
22:54:37 <teor> mikeperry: we put 246 into needs-research, too many open questions
22:54:44 <teor> but yes, that is an option
22:55:16 <teor> 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 <armadev> 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 <armadev> (making things rigid in exactly the wrong places)
22:56:07 <nickm> re
22:56:10 <nickm> so sorry.
22:56:27 <nickm> telephone call of urgentness that you would not belive, but of which I assure you.
22:56:29 <mikeperry> 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 <nickm> What conclusions do we have?
22:56:49 <mikeperry> and avoid an extra intro circuit build
22:57:09 <teor> We like the idea of finishing prop#260
22:57:28 <teor> And I like the idea of finishing prop#255
22:57:36 * nickm nods sagely, as if he knew
22:57:51 <teor> We wonder if anything more will be be a distraction from prop#224
22:58:12 <teor> Unless, of course, it comes with funding attached (which is possible for prop#252)
22:58:15 <armadev> to put it more strongly, we suggested that "but that would delay prop224" is a good argument for not doing things
22:59:35 <armadev> 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 <mikeperry> 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 <armadev> also, if there is prop252 funding, we should use it to implement 224 faster :)
23:00:30 <nickm> 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 <teor> armadev: I'll see what I can do
23:01:48 <armadev> 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 <armadev> i guess that is something we would get from more research on 252. and should not delay finishing 260.
23:02:23 <teor> armadev: not really, and yes, actual figures will require research / implementation
23:03:10 <mikeperry> 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 <teor> sections 2 and 6 are about as good as it gets right now
23:04:03 <mikeperry> 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 <teor> mikeperry: that depends on the funders. But we do have some flexibility.
23:05:36 <armadev> 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 <nickm> 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 <armadev> 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 <teor> armadev: I think section 2 of prop#260 is what you're asking for. How could I make it better?
23:09:40 <armadev> i found "Connection latency is higher" to be an ambiguous phrase
23:09:49 <armadev> i didn't realize the first three times that you meant the rendezvous handshake
23:09:54 <nickm> when I read all the backlog, what conclusion should I reach?
23:10:13 <teor> Tor good, spying bad?
23:10:18 <smudkavi> 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 <nickm> well sure
23:10:36 <nickm> smudkavi: oh wow, it's kind of complicated!
23:11:03 <nickm> There is this old thing from 2003 http://www.onion-router.net/Publications/tor-design.pdf
23:11:04 <armadev> 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 <nickm> but a lto of time has passed since 2003
23:11:19 <smudkavi> 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 <armadev> smudkavi: be sure to track down the tor blog posts on "what changed since the 2004 paper".
23:12:07 <mikeperry> smudkavi: and then of course https://gitweb.torproject.org/torspec.git/tree/
23:12:26 <nickm> 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 <sixmonths> is there a mininium amount of bandwidth that is needed for 0.2.7.6?
23:13:00 <smudkavi> Oh wow, that’s a lot of information haha, thanks a lot! I’m going to dig into all of these
23:13:08 <nickm> okay, so what is the difference between the different "onion but not hidden" proposals?
23:13:20 <nickm> or should I stfu and #endmeeting?
23:13:57 <armadev> nickm: 252 is faster for the handshake, but requires you to be reachable from the outside
23:14:18 <teor> 260 only requires changes on the service side
23:14:19 <armadev> essentially, the difference is that one does nat punching for you, at the cost of more steps in the protocol
23:14:31 <armadev> also, yes, 260 is a much less intrusive change
23:15:35 <teor> and 255 is in here because it's about scaling, but it can be used on hidden or non-hidden services
23:16:03 <teor> it's a neat way of passing an intro response through the controller to another tor instance
23:17:08 <armadev> at the cost, i assume, of even more latency in the handshake phase?
23:17:39 <teor> armadev: unfortunately, depending on the load of the introducing tor instance
23:18:02 <teor> If the introducing tor instance is heavily loaded, passing off the rendezvous might just be faster
23:18:15 <nickm> hrmnmnm.
23:18:27 <nickm> So first, since time has passed, my apologies and
23:18:28 <nickm> #endmeeting