16:00:32 #startmeeting anti-censorship meeting 16:00:32 Meeting started Thu Aug 27 16:00:32 2020 UTC. The chair is phw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:32 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:00:38 also i am here too :) (reading the obfs4 analysis pdf in parallel) 16:00:40 hi all, here's our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 16:00:41 hi! 16:00:48 Hii 16:00:53 hi! 16:02:04 one announcement for today: snowflake cost us $0.01 in july. does anyone want to elaborate on that? 16:02:22 hi 16:03:12 crickets means no 16:03:42 is dcf1 here? 16:03:46 I'm here 16:04:25 our next discussion item says that tor browser's next stable deadline is scheduled for early september 16:04:41 yep, i talked to sysrqb about this just now in #tor-dev 16:05:01 we have about the same number of users as the last time we had this discussion 16:05:23 so i think we're going to push the stable release back to winter/spring for a few reasons 16:05:46 1) to get more users and alpha testers which we have a plan to make a call for at the next alpha release 16:06:00 2) this pesky nat problem still hasn't been fixed 16:06:18 3) there's more performance improvements we can make 16:06:30 how does this sound? 16:07:13 i think it sounds good. these sound like good reasons 16:07:32 yeah 16:07:52 should we make the next stable release a hard deadline? and move snowflake into stable even if we aren't 100% satisfied with our fixes of the above issues? 16:08:25 we don't have to decide now. we should just keep in mind that the perfect can sometimes be the enemy of the good 16:09:46 next is babatunde's research, which is antonela's item i believe. i still owe you a review of that :/ 16:09:58 yes, sorry for adding another thing in your plate folks 16:10:08 if someone can give a quick reading on that this week, will be really appreciated! 16:10:25 i will do it later today 16:10:30 we are closing this next week, as the program ends so any input is good for us :) 16:10:31 yup, i have that on my todo list by the end of this week :) 16:10:33 thank you so much 16:10:42 and sorry for the short notice 16:11:21 antonela: i'm the one who should make excuses for being late, not you :P 16:11:24 thanks to tunde for doing this work 16:11:35 i mean, was a year work! but things got crazy at the end 16:12:22 oh, and we now have a report in our snowflake bug report pad: https://pad.riseup.net/p/tor-anti-censorship-bugs-keep 16:12:40 "snowflake bridge stops at 10% bootstrape on alpha version(68.11.0) of android" 16:12:42 I'm not sure what to do about this 16:13:00 yeah it seems like they probably ahve a restrictive NAT 16:13:00 My thinking was that we transcribe these reports into tickets, but in this case I don't know that it would help 16:13:14 I agree, cohosh 16:13:25 since this is a known issue, do we comment on the pad? 16:13:32 We can maybe leave a note in the pad and see if they check it again, but 16:13:42 otherwise we don't have a way to ask questions back 16:13:43 or we could open a ticket for it to communicate that we got the message 16:14:40 "sometimes it does connect tho" yeah I think this is nothing we don't know about yet 16:15:01 cohosh: you mean open a ticket, mark it as duplicate right away? 16:15:16 that would make sense 16:15:48 yeah i think the question here is more how to do we show we're accountable for issues people bring to us 16:16:29 i'm not sure how these users are engaging with the pad and issue trackers >.< 16:16:55 either way, we should probably leave a note in the pad. if i was the user, i would check it again if i expected action. 16:17:17 Okay what I will do is transcribe the report into a new ticket, close it with reference to the NAT ticket, and leave a reference to the issue number in the pad 16:17:24 great 16:20:01 and finally, a semi-announcement: the next privchat iteration will take place tomorrow and cohosh will be part of it! 16:20:04 https://www.torproject.org/privchat/ 16:20:14 |o/ 16:20:21 \o| 16:21:08 :) 16:21:12 i'll be watching! 16:21:16 same here :) 16:21:32 let's move on to the 'needs help with section' 16:21:54 cohosh still needs snowflake#21314, which is now on my plate. i'm sorry that i haven't managed to review it yet. i'll get to it today 16:22:03 yeah, it's been 2 weeks 16:22:17 this is a bit longer than i'd like to have to wait for snowflake reviews in general 16:22:25 i'm not sure how we want to handle this 16:22:29 sorry, this case is my fault 16:24:19 my plan is be more aggressive in the future 16:24:25 is it reasonable to expect a review within, say, two or three days? and if it doesn't happen by then, switch reviewers? or ping the original reviewer? 16:24:40 sounds reasonable to me 16:24:54 dcf1: i know you have other things going on other than tor, so i don't want to overstep here 16:25:14 it was a mistake for me to claim reviewing for this one 16:25:37 i can wait some number of days (depending on how blocking the ticket is) and then ask phw 16:25:40 2-3 days is reasonable, the assigned reviewer should give it up after that 16:25:46 alright cool 16:27:12 i'm not sure how to formalise the process further so that the code author doesn't have to ping reviewers regularly :/ 16:28:00 eh it's not bad to ping people 16:28:49 i mostly wanted to know where dcf was at since i don't want to lean to heavily on non tpo ppl who have other things going on to do code review 16:29:01 that's fair 16:29:05 i like what we've come up with 16:29:19 anything else before we move on to the reading group? 16:29:24 oh yeah 16:29:29 just a note 16:29:45 i'm probably going to be away for most of september recovering from carpal tunnel 16:30:02 i'll check email and signal occasionally but i'm really trying to cut down on typing so i can heal 16:30:10 all the best with that :( 16:30:36 get well soon cohosh 16:30:41 thanks! 16:31:34 let's move on to our reading group 16:31:56 today's paper is turbo tunnel: https://www.bamsoftware.com/papers/turbotunnel/turbotunnel.pdf 16:32:07 and we are lucky enough to have the author, dcf1, with us today 16:32:54 i didn't prepare a summary of the paper, so i suggest we jump straight into the discussion 16:35:03 let me start with a question: you experimented with several compositions and i wonder where you felt that the session layer and the obfuscation layer should communicate about more than just the tunnel network traffic? 16:35:52 I don't understand? Do you mean some metadata about the contents being transmitted? 16:37:19 There is some degree of isolation between the two layers that makes some things awkward, for example 16:37:39 yes. i was reminded of the "fog" pluggable transport and was wondering what meta data the obfuscation layer may need to know 16:37:59 the obfuscation layer knows about the remote peer's IP address (if it's the kind of obfuscation that has a stable remote IP address), but that information is lost when the packets it contains get forwarded into the session layer 16:38:40 In Snowflake there's a somewhat cumbersome workaround to remember the IP address until it is needed, for the purpose of ExtORPort accounting 16:39:08 https://lists.torproject.org/pipermail/anti-censorship-team/2020-February/000066.html 16:39:41 If you don't need anything like the ExtORPort accounting, then there's very little meta communication needed between the layers 16:40:11 see https://www.bamsoftware.com/papers/turbotunnel/example/#server 16:40:59 (i love that visualisation of necessary changes) 16:41:07 You have a loop of acceptSessions/acceptStreams/handleStream at the session layer, which is driven by packets received by the PacketConn interface. But it doesn't know or care where the packets come from at all. 16:41:49 In this case the PacketConn implementation is https://www.bamsoftware.com/papers/turbotunnel/example/#listenerpacketconn.go 16:42:16 But it's pluggable to a high degree, again, if you don't need extra details that only the obfuscation layer knows 16:42:40 right, thanks for that explanation 16:44:08 this work is really cool 16:44:11 Another piece of cross-layer communication that would be helpful is listed in https://www.bamsoftware.com/papers/turbotunnel/#sec:library 16:44:55 Namely "A variable maximum size per packet". kcp-go and quic-go assume a global MTU and they craft packets to fit in it. But the obfuscation layer may need a different maximum packet size at different times. 16:46:08 this goes slightly beyond turbo tunnel but i find the economics of deployment of dnstt interesting. unlike domain fronting, there are (or will be) many dns servers that one could use but i suspect that the respective operators may not be too happy about that 16:46:59 Like in DNS, you may set an MTU of 100 bytes to fit into a query. If the session layer gives you a packet of 30 bytes, you sill have 60 bytes that could hold more packets, but the session layer doesn't know that, and it may give you a packet of 100 bytes next, which you then have to remember and defer until you have an opportunity to send another DNS message. 16:47:06 so if we would use dnstt and are good internet citizens, what would deployment look like? pick a few dozen servers and load-balance users across them? ask for forgiveness rather than permission? 16:47:58 I don't know. I've avoided using dnstt too much myself for that reason. 16:48:53 ValdikSS made a VM lately for access in Belarus which included dnstt, but as far as I know it wasn't configured to use DoH/DoT nor even a recursive resolver, just a direct DNS-resembling connection to a fixed proxy. 16:49:44 sounds like a good way to handle it to start 16:50:01 Well, yes, but it's only useful against a naive censor 16:50:06 yup 16:50:07 until they block by IP, right 16:50:49 Not only that, even with a recursive resolver, with plaintext DNS the domain name of the proxy is revealed in the DNS message. That's how the recursive resolve knows where to forward the message. 16:50:51 the university of waterloo runs a DoH server now (it's just ian running it from the crysp url), that might be a good place to start 16:51:00 reaching out to friendly institutions 16:51:35 who are willing to participate in circumvention efforts 16:52:01 yeah 16:52:27 though with a cooperating institution it's much, much more efficient to do an HTTPS-protected HTTP proxy instead. 16:52:39 yeah that's a good point 16:52:42 Even meek is more efficient than a DoH tunnel. 16:53:16 But as a method of bootstrapping / prototyping a deployment, yes, I get you. 16:54:38 any more questions? 16:54:41 there are a few future research directions of turbo tunnel i'm interested in 16:55:15 i like the point made in the paper about how it can defend against the censor attacks where a tcp connection is terminated after some time 16:55:46 (is there a measurement paper that shows this happening to obfs4?) 16:56:00 i'm curious about how it stands up from a usability perspective 16:56:29 turbotunnel can recover the session 16:56:36 but what does this actually look like for page loads 16:56:57 obviously better than before, but is it still too painful to use? 16:56:58 There are a lot of parameters to consider that I didn't really look at 16:57:21 yeah i suppose type of tool is a factor 16:57:29 For example, what's the policy for reconnecting (do it only on failure, or keep a pre-warmed fresh connection) 16:57:46 What's the policy for giving up when a reconnection fails 16:58:28 i suppose we're trying to answer some of these in snowflake, which is a bit of an extreme edge case of turbotunnel 16:58:33 In the obfs4 model where you can assume TCP as a substrate and reconnection is fast and reliable, I think you would not even notice if your connection was terminated every 60 seconds or whatever. 16:58:51 You could also do something like 16:59:25 start conn A, wait 30 seconds, start conn B, 30 seconds later A is terminated so start conn C, 30 seconds later B is terminated so start D... 16:59:41 stagger two connections and multiplex on both of them 17:00:26 About your question of whether this has ever happened with obfs4, no, I don't know of any cases. It's just those couple of old reports from Iran that do not have a ton of supporting evidence. 17:00:39 ah ok 17:01:00 These days IP blocking (even temporary, like the Iran protocol filter or the China ESNI block) would be more likely 17:01:04 yeah i've heard of it but couldn't track down a paper 17:01:44 i've also talked with some undergrads at waterloo who are doing a research project looking at traffic patterns of dnstt 17:01:44 The main idea is more general, though, you have a session that's independent of a network connectionn, so you have do things like let the connection be interrupted, or use two different kinds of channel. 17:01:54 Yes I am talking to them 17:01:55 some of which may be more generally applying to turbotunnel 17:01:59 cool :) 17:02:22 yeah they mentioned they reached out to you 17:02:30 maybe we can get them to share their findings here eventually 17:04:26 * phw waits for two minutes to see if there are more questions 17:07:03 let's wrap up today's reading group. thanks a lot for answering questions, dcf1! 17:07:37 does anyone want to suggest our next reading "assignment"? 17:08:47 anyway, let's decide on it some other time. i'm ending the meeting now 17:08:49 #endmeeting