16:07:43 <dcf1> #startmeeting tor anti-censorship meeting
16:07:43 <MeetBot> Meeting started Thu Apr  8 16:07:43 2021 UTC.  The chair is dcf1. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:07:43 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:07:54 <dcf1> gettings everyone
16:08:00 <dcf1> here is the meeting pad
16:08:02 <dcf1> https://pad.riseup.net/p/tor-anti-censorship-keep
16:08:14 <dcf1> cohosh is afk this week
16:08:36 <dcf1> there are no discussion points on the agenda
16:09:00 <gaba> :)
16:09:01 <dcf1> in interesting links news, Censored Planet published a report of last month's Twitter throtting in Russia
16:09:07 <dcf1> https://censoredplanet.org/throttling
16:09:37 <dcf1> cohosh is still looking for review of snowflake!31, which I plan to do in the upcoming week
16:10:14 * anarcat too
16:10:22 <dcf1> now I'll leave it open for about 10 minutes in case there's a need for any spontaneous discussion
16:10:30 <arma2> yeah, making snowflake support the v2 spec will be great
16:10:53 <arma2> i've got a thing that maybe people already know the answer to:
16:11:15 <arma2> if you had some dpi experts looking at snowflake, what questions would you pose to them, in the "does this blend in well" sense?
16:11:19 <anarcat> oh wait, no i'm planning on reviewing MR 32
16:11:34 <arma2> that is, ideally our webrtc looks like "real" webrtc, but probably there are some differences
16:11:51 <arma2> are there particular things you'd especially want feedback about?
16:12:47 <arma2> and... are there any other parts of the various snowflake protocols where a dpi person looking at them would be helpful. (not that i know of, because the broker interaction uses domain fronting, and the websocket part is supposed to be hidden from the censor)
16:13:26 <dcf1> arma2: there are a couple of short papers
16:13:29 <dcf1> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/wikis/Fingerprinting
16:13:32 <dcf1> https://arxiv.org/abs/1605.08805
16:13:41 <dcf1> https://arxiv.org/abs/2008.03254
16:13:44 <arma2> oh right! prateek (and his student)'s thing!
16:13:45 <arma2> awesome
16:14:02 <dcf1> A few random points I can think of right now are
16:14:10 <dcf1> * choice of STUN server
16:14:20 <dcf1> * STUN implementation fingerprint
16:14:44 <dcf1> * DTLS fingerprint (ciphersuites, extensions, etc.)
16:15:02 <dcf1> * presence or absence of known signaling
16:15:35 <dcf1> The thing is, there's no single "real" webrtc. Basically all applications using it build themselves out of parts.
16:16:14 <dcf1> They configure what STUN servers they will use, for example, and applications are responsible for figuring out their own "signaling", which is the preliminary step where the peers exchange rendezvous information.
16:16:50 <dcf1> Signaling may be done using HTTPS to a central server, for example, or WebSocket, some custom protocol, whatever. In Snowflake the broker has the additional responsibility of being a signaling server.
16:16:53 <arma2> ah so if we manage to hide our signaling, that is itself weird
16:17:32 <dcf1> Yes, if you want to imitate webrtc application X precisely, you have to at least fake doing whatever kind of signaling X does
16:17:46 <arma2> so i guess "category one, do any of these components, individually, look weird"
16:17:46 <dcf1> But also, DPi to detect that would have to be pretty stateful
16:17:53 <arma2> and then "category two, does the combination of them together look weird"
16:17:59 <dcf1> Yes, I think that's a good way to look at it.
16:18:04 <arma2> because yeah, category two is more work / state / false positive / etc
16:19:15 <arma2> and not just stateful, but complete, in the sense that if you aren't sure whether you saw the signaling, it's much harder to declare that it's missing and therefore that's the distinguisher
16:19:56 <arma2> ok great. that list is exactly the granularity that i had in mind. let me know if there are any more bullet points on it that come to mind. :)
16:20:20 <dcf1> great
16:21:46 * arma2 lets dcf1's 10 minutes proceed
16:24:49 <dcf1> one other bullet point
16:24:57 <dcf1> * Media stream vs. data stream
16:25:39 <dcf1> webrtc offers unreliable MediaChannels (datagram-oriented, like UDP) and reliable DataChannels (stream-oriented, like TCP)
16:25:56 <dcf1> they are externally distinguishable because they use different crypto, at least the last time I checked
16:26:17 <dcf1> Snowflake uses DataChannels, while most audio/video apps will use MediaChannels
16:29:21 <dcf1> until next time
16:29:24 <dcf1> #endmeeting