=========================================================================== FOCI '16 Review #1A --------------------------------------------------------------------------- Paper #1: DNS-sly: Avoiding Censorship through Network Complexity --------------------------------------------------------------------------- Overall merit: 3. Weak accept Reviewer expertise: 3. Knowledgeable ===== Paper summary ===== This paper proposes a covert channel that leverages DNS to transmit covert data. The key idea is to code data in the order that IP addresses are returned for a given domain. I thought the idea is interesting and might expose some interesting questions about designing a covert channel in this space. The paper will likely spur interesting discussions at the workshop. The paper could be improved by more rigorously showing how a censor could not join the covert channel in order to detect which DNS servers support the covert channel. The discussion around how the system would survive DNS injectors could have been more complete. Finally, the bandwidth numbers presented in bytes/click are hard to compare with other covert channel proposals. ===== Comments for author ===== o The argument that 600 Bytes of data per Web page click is sufficient to run a covert Web proxy should be demonstrated more concretely in the paper. The claim is made in the abstract and after reading the paper I’m not convinced it holds. o The paper makes very strong claims about deniability of the platform. These hinge on the censor not being able to identify DNS-sly responders. As a result, I would have liked to see more rigorous discussion about how the system would defend against active probing attacks. o I liked the characterization in section 2 but it could be more precise in places. E.g., “top 25% of domains” are referred to often, but it isn’t clear what they are in the top 25% of. o The argument about many IPs cycling enabling higher data rates (end of S. 2) is subject to the amount of queries the client will make for a given domain in a given Web session (since you do not chaff in the downstream direction). o I would have liked to see more intuition about the encoding used in 3.3 . Illustrating the encoding with a small figure would help make it more clear. Also, why is this encoding chosen and not some other encoding? Can you state something about the efficiency of this method? o I didn’t buy the argument against discovery attacks in 4.1. It sounds like the OOB exchange of the user profile happens after the user connects to and interacts with the server for some time. Thus a scanner could perform the DNS-sly initiation against many servers and log which ones attempt to send the profile OOB. o I like the statistical indistinguishability of the passive attacks, but wonder if DNS-sly requires lengthening Web browsing sessions to transfer sufficient data? Is this enough to skew DNS-sly Web traffic from regular user Web traffic? o The argument against DNS tampering implies that the censor would need to operate at the scale of Akamai’s CDN DNS server. However, they actually only need to act on the DNS traffic in their local ISP/national network. o The discussion of resilience to DNS injection is also lacking. o Performance numbers are given in bytes per click which is hard to translate into bytes per second for comparison with other covert channels. It would also be interesting to know how many bytes of covert information is transmitted for a given amount of cover traffic to measure efficiency. o The behind a firewall results would have been more convincing if they were done behind a firewall that implements DNS-based filtering/injection. =========================================================================== FOCI '16 Review #1B --------------------------------------------------------------------------- Paper #1: DNS-sly: Avoiding Censorship through Network Complexity --------------------------------------------------------------------------- Overall merit: 2. Weak reject Reviewer expertise: 3. Knowledgeable ===== Paper summary ===== This paper presents a way to steganographically tunnel data through DNS, by using the order and set of A records from a participating server to encode data. ===== Comments for author ===== This is an interesting idea, but I'm curious if there are easy ways to detect this by the censor. For example, some DNS servers/providers use round-robin DNS. In this, each request that comes in gives the same list, circularly shifted each time. For example, yahoo.com uses this, and returns 3 IP addresses {A, B, C}. On the subsequent request, it returns {B, C, A}, and then {C, A, B}, and then finally back to {A, B, C}. It never returns {C, B, A} or {B, A, C} or any permutation that isn't a circularly shifted version of the original. Of course, not all DNS-providers do this, but it is a fairly popular configuration/simple load-balancing trick. If this trick is common among servers, it will severely cut down on the bandwidth one can transfer over DNS-sly without detection. I encourage the authors to see how many domains have this behavior, and wonder if there are other subtle behaviors that are detectable in a similar way. The authors claim that the censor could defend against this by running their own DNS caching servers, but it is claimed this would be cost-prohibitive for them. However, this is exactly what DNS-sly must do in order to operate; why is it cost-prohibitive for the censor, but not DNS-sly? The censor only has to do this for servers that are known (or strongly suspected) to be DNS-sly servers. The paper discusses DNS-sly as a bi-directional channel, but I don't see any description of the upstream direction. There is some hand-waving in the Communication subsection that says it uses the user profile map, but no details are provided. Perhaps they mean "upstream communication" as in "intent to use DNS-sly", rather than bi-directional communication with the DNS-sly server. But then how does a client request a website, for example? This lack of detail makes me question the practicality and usefulness of this system. The authors also claim a fairly high "bytes per click" rate, but I wonder if they are ignoring the TTLs and caching effects. Besides TTLs, browsers will actually cache for up to several minutes to prevent DNS-rebinding attacks, meaning that the TTL value may be overridden by the browser. In practice, this means that the effective bandwidth a client can receive may be significantly less: Not every click that a client makes will generate enough DNS requests to allow for transferring data. Worse, these clicks will likely be related (clicks on facebook.com will likely lead to facebook.com), making this number even less. It would be nice if the authors found a way to measure this for users in practice, either through using the system themselves over a long period, or performing a user study to measure normal-user traffic. The paper also seems to suggest that it would be difficult for a censor to discover DNS-sly servers, but this is the classic chicken-egg problem for censorship circumvention systems: If it is hard for the censor to discover these servers, how is it easy for normal users to discover it? If this is meant to be a widely-used system, I would expect that the censor can easily discover all of the DNS-sly servers through testing/trying to use them. The paper addresses this by saying that there must be an out-of-band communication between requester and respondor, but I'm not convinced that will prevent a censor from using this system; it may serve to make it harder only for legitimate users who do not have the resources of a government censor. =========================================================================== FOCI '16 Review #1C --------------------------------------------------------------------------- Paper #1: DNS-sly: Avoiding Censorship through Network Complexity --------------------------------------------------------------------------- Overall merit: 4. Accept Reviewer expertise: 4. Expert ===== Paper summary ===== The paper presents a censorship circumvention system be constructing a covert channel between the DNS client and server. In the upstream direction, the client issues DNS that mimick normal client behavior. In the downstream direction, it uses CDN-related DNS responses to embed data, achieving covertness by mimicking the statistical properties of CDNs. The authors implement DNS-sly in a known censorship environment to demonstrate its real-world usability. ===== Comments for author ===== The paper's main observation is that the proliferation of CDNs creates an opportunity to embed hidden information in the CDN-like behavior, allowing about 600 bytes of information to be hidden for a particular set of user Web requests (a "click"). The system is modeled roughly after Infranet (Figure 1) even uses a figure that is quite similar to the original Infranet paper. The paper performs an analysis to explore the variability in DNS requests and responses, and observes that (1) adding a few upstream DNS requests; (2) changing the set of IP addresses in DNS responses can result in a reasonable covert channel. The paper then proceeds to evaluate the throughput of this covert channel. This is a nice paper, effectively using similar ideas as Infranet (dictionaries for encoding, etc.) to embed a covert channel in DNS. Section 4.1 gives a fairly straightforward, though thoughtful, evaluation of the security attacks on the system; Section 4.2 gives a preliminary but promising performance evaluation. (It would be have been nice to see this evaluation for a "normal" user web trace, for example, as opposed to just the Alexa Top 500. A normal trace would have a different mix, and it would also contain ads, trackers, etc., which might *help* the evaluation.) Overall, this is a small but solid piece of work. It would be nice if the authors would (1) release the system; (2) attempt to deploy it in a setting where it could have some real impact (e.g., Tor pluggable transports).