16:00:32 <phw> #startmeeting anti-censorship meeting
16:00:32 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:38 <arma2> also i am here too :) (reading the obfs4 analysis pdf in parallel)
16:00:40 <phw> hi all, here's our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
16:00:41 <cohosh> hi!
16:00:48 <HashikD> Hii
16:00:53 <hanneloresx> hi!
16:02:04 <phw> one announcement for today: snowflake cost us $0.01 in july. does anyone want to elaborate on that?
16:02:22 <agix> hi
16:03:12 <phw> crickets means no
16:03:42 <cohosh> is dcf1 here?
16:03:46 <dcf1> I'm here
16:04:25 <phw> our next discussion item says that tor browser's next stable deadline is scheduled for early september
16:04:41 <cohosh> yep, i talked to sysrqb about this just now in #tor-dev
16:05:01 <cohosh> we have about the same number of users as the last time we had this discussion
16:05:23 <cohosh> so i think we're going to push the stable release back to winter/spring for a few reasons
16:05:46 <cohosh> 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 <cohosh> 2) this pesky nat problem still hasn't been fixed
16:06:18 <cohosh> 3) there's more performance improvements we can make
16:06:30 <cohosh> how does this sound?
16:07:13 <phw> i think it sounds good. these sound like good reasons
16:07:32 <dcf1> yeah
16:07:52 <phw> 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 <phw> 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 <phw> next is babatunde's research, which is antonela's item i believe. i still owe you a review of that :/
16:09:58 <antonela> yes, sorry for adding another thing in your plate folks
16:10:08 <antonela> if someone can give a quick reading on that this week, will be really appreciated!
16:10:25 <phw> i will do it later today
16:10:30 <antonela> we are closing this next week, as the program ends so any input is good for us :)
16:10:31 <cohosh> yup, i have that on my todo list by the end of this week :)
16:10:33 <antonela> thank you so much
16:10:42 <antonela> and sorry for the short notice
16:11:21 <phw> antonela: i'm the one who should make excuses for being late, not you :P
16:11:24 <cohosh> thanks to tunde for doing this work
16:11:35 <antonela> i mean, was a year work! but things got crazy at the end
16:12:22 <phw> 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 <phw> "snowflake bridge stops at 10% bootstrape on alpha version(68.11.0) of android"
16:12:42 <dcf1> I'm not sure what to do about this
16:13:00 <cohosh> yeah it seems like they probably ahve a restrictive NAT
16:13:00 <dcf1> 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 <dcf1> I agree, cohosh
16:13:25 <cohosh> since this is a known issue, do we comment on the pad?
16:13:32 <dcf1> We can maybe leave a note in the pad and see if they check it again, but
16:13:42 <dcf1> otherwise we don't have a way to ask questions back
16:13:43 <cohosh> or we could open a ticket for it to communicate that we got the message
16:14:40 <dcf1> "sometimes it does connect tho" yeah I think this is nothing we don't know about yet
16:15:01 <dcf1> cohosh: you mean open a ticket, mark it as duplicate right away?
16:15:16 <dcf1> that would make sense
16:15:48 <cohosh> 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 <cohosh> i'm not sure how these users are engaging with the pad and issue trackers >.<
16:16:55 <phw> 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 <dcf1> 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 <cohosh> great
16:20:01 <phw> and finally, a semi-announcement: the next privchat iteration will take place tomorrow and cohosh will be part of it!
16:20:04 <phw> https://www.torproject.org/privchat/
16:20:14 <antonela> |o/
16:20:21 <phw> \o|
16:21:08 <cohosh> :)
16:21:12 <hanneloresx> i'll be watching!
16:21:16 <agix> same here :)
16:21:32 <phw> let's move on to the 'needs help with section'
16:21:54 <phw> 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 <cohosh> yeah, it's been 2 weeks
16:22:17 <cohosh> this is a bit longer than i'd like to have to wait for snowflake reviews in general
16:22:25 <cohosh> i'm not sure how we want to handle this
16:22:29 <dcf1> sorry, this case is my fault
16:24:19 <cohosh> my plan is be more aggressive in the future
16:24:25 <phw> 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 <cohosh> sounds reasonable to me
16:24:54 <cohosh> dcf1: i know you have other things going on other than tor, so i don't want to overstep here
16:25:14 <dcf1> it was a mistake for me to claim reviewing for this one
16:25:37 <cohosh> i can wait some number of days (depending on how blocking the ticket is) and then ask phw
16:25:40 <dcf1> 2-3 days is reasonable, the assigned reviewer should give it up after that
16:25:46 <cohosh> alright cool
16:27:12 <phw> 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 <cohosh> eh it's not bad to ping people
16:28:49 <cohosh> 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 <phw> that's fair
16:29:05 <cohosh> i like what we've come up with
16:29:19 <phw> anything else before we move on to the reading group?
16:29:24 <cohosh> oh yeah
16:29:29 <cohosh> just a note
16:29:45 <cohosh> i'm probably going to be away for most of september recovering from carpal tunnel
16:30:02 <cohosh> i'll check email and signal occasionally but i'm really trying to cut down on typing so i can heal
16:30:10 <phw> all the best with that :(
16:30:36 <agix> get well soon cohosh
16:30:41 <cohosh> thanks!
16:31:34 <phw> let's move on to our reading group
16:31:56 <phw> today's paper is turbo tunnel: https://www.bamsoftware.com/papers/turbotunnel/turbotunnel.pdf
16:32:07 <phw> and we are lucky enough to have the author, dcf1, with us today
16:32:54 <phw> i didn't prepare a summary of the paper, so i suggest we jump straight into the discussion
16:35:03 <phw> 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 <dcf1> I don't understand? Do you mean some metadata about the contents being transmitted?
16:37:19 <dcf1> There is some degree of isolation between the two layers that makes some things awkward, for example
16:37:39 <phw> 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 <dcf1> 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 <dcf1> 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 <dcf1> https://lists.torproject.org/pipermail/anti-censorship-team/2020-February/000066.html
16:39:41 <dcf1> If you don't need anything like the ExtORPort accounting, then there's very little meta communication needed between the layers
16:40:11 <dcf1> see https://www.bamsoftware.com/papers/turbotunnel/example/#server
16:40:59 <phw> (i love that visualisation of necessary changes)
16:41:07 <dcf1> 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 <dcf1> In this case the PacketConn implementation is https://www.bamsoftware.com/papers/turbotunnel/example/#listenerpacketconn.go
16:42:16 <dcf1> 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 <phw> right, thanks for that explanation
16:44:08 <cohosh> this work is really cool
16:44:11 <dcf1> Another piece of cross-layer communication that would be helpful is listed in https://www.bamsoftware.com/papers/turbotunnel/#sec:library
16:44:55 <dcf1> 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 <phw> 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 <dcf1> 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 <phw> 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 <dcf1> I don't know. I've avoided using dnstt too much myself for that reason.
16:48:53 <dcf1> 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 <cohosh> sounds like a good way to handle it to start
16:50:01 <dcf1> Well, yes, but it's only useful against a naive censor
16:50:06 <cohosh> yup
16:50:07 <arma2> until they block by IP, right
16:50:49 <dcf1> 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 <cohosh> 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 <cohosh> reaching out to friendly institutions
16:51:35 <cohosh> who are willing to participate in circumvention efforts
16:52:01 <dcf1> yeah
16:52:27 <dcf1> though with a cooperating institution it's much, much more efficient to do an HTTPS-protected HTTP proxy instead.
16:52:39 <cohosh> yeah that's a good point
16:52:42 <dcf1> Even meek is more efficient than a DoH tunnel.
16:53:16 <dcf1> But as a method of bootstrapping / prototyping a deployment, yes, I get you.
16:54:38 <phw> any more questions?
16:54:41 <cohosh> there are a few future research directions of turbo tunnel i'm interested in
16:55:15 <cohosh> 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 <cohosh> (is there a measurement paper that shows this happening to obfs4?)
16:56:00 <cohosh> i'm curious about how it stands up from a usability perspective
16:56:29 <cohosh> turbotunnel can recover the session
16:56:36 <cohosh> but what does this actually look like for page loads
16:56:57 <cohosh> obviously better than before, but is it still too painful to use?
16:56:58 <dcf1> There are a lot of parameters to consider that I didn't really look at
16:57:21 <cohosh> yeah i suppose type of tool is a factor
16:57:29 <dcf1> For example, what's the policy for reconnecting (do it only on failure, or keep a pre-warmed fresh connection)
16:57:46 <dcf1> What's the policy for giving up when a reconnection fails
16:58:28 <cohosh> 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 <dcf1> 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 <dcf1> You could also do something like
16:59:25 <dcf1> 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 <dcf1> stagger two connections and multiplex on both of them
17:00:26 <dcf1> 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 <cohosh> ah ok
17:01:00 <dcf1> These days IP blocking (even temporary, like the Iran protocol filter or the China ESNI block) would be more likely
17:01:04 <cohosh> yeah i've heard of it but couldn't track down a paper
17:01:44 <cohosh> i've also talked with some undergrads at waterloo who are doing a research project looking at traffic patterns of dnstt
17:01:44 <dcf1> 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 <dcf1> Yes I am talking to them
17:01:55 <cohosh> some of which may be more generally applying to turbotunnel
17:01:59 <cohosh> cool :)
17:02:22 <cohosh> yeah they mentioned they reached out to you
17:02:30 <cohosh> 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 <phw> let's wrap up today's reading group. thanks a lot for answering questions, dcf1!
17:07:37 <phw> does anyone want to suggest our next reading "assignment"?
17:08:47 <phw> anyway, let's decide on it some other time. i'm ending the meeting now
17:08:49 <phw> #endmeeting