FOCI26 Paper #20 Reviews and Comments =========================================================================== Paper #20 Fountain codes in censorship circumvention rendezvous Review #20A =========================================================================== Overall merit ------------- 4. Accept Reviewer expertise ------------------ 2. Some familiarity Paper summary ------------- The submission describes the use of fountain codes to facilitate censorship circumvention rendezvous over low rate, unreliable protocols. In particular encrypted DNS is looked at in some detail. Comments for authors -------------------- This is a nice paper. It introduces a clever novel use of a mechanism (fountain codes) to address an important aspect of censorship circumvention. It is acknowledged that other means of addressing rendezvous (in the sense used in the paper), but it is also argued convincingly that the introduced mechanism should be practical and useful. When I had a question, I generally found the authors addressed or at least acknowledged it at some point. For example, I wrote down on page 1 a question if this system might be vulnerable to DoS without making the censor DoS all encrypted DNS, which was noted briefly at the end of page 4. They also spell out enough detail about encoding DNS queries to make their analysis of what is practical convincing. The paper is clearly written. Despite being short it gives enough background (clearly presented) on the censorship environments to which they apply and on fountain codes, with pointers to where to look for more information. Comparisons to related work clearly explain the relation and novelty of the current work versus prior. It is nice that if the receiver sends a response and continues to get queries, it can infer after a reasonable number/time that the response was not received and send again. Similarly, if the sender fails to get a response. Although both should have some threshold for declaring broader failure and breaking off a particular rendezvous attempt. A few small comments: ll. 63-ff. "Our focus in this paper is rendezvous over fragmented or unreliable network protocols: ones with the capacity to transfer an entire rendezvous message all at once, or in which delivery is not guaranteed." I think you meant _without_ the capacity? ll. 256-ff. You might discuss a tradeoff if space permits: Since it can detect unusual queries, if the recursive NS collaborates with the censor it can either disrupt the identifier or tell the censor. If the censor has a choice wrt DNS resolvers, it could block encrypted traffic to resolvers that don't cooperate and permit to those that do cooperate. Are there environments where that if feasible? Review #20B =========================================================================== Overall merit ------------- 4. Accept Reviewer expertise ------------------ 3. Knowledgeable Paper summary ------------- The paper proposes using fountain codes, rateless erasure codes, with encrypted DNS for the preliminary handshake or rendezvous step of censorship circumvention protocols. Fountain codes are employed to address the key issues of rendezvous over encrypted DNS: the messages that are longer than a DNS query and that DNS is unordered and unreliable. Fountain codes allow a message to be split into many small encoded symbols, any sufficient subset of which can reconstruct the original message. The paper buildspresents a preliminary UDP-based implementation that points to a concrete encrypted DNS-based rendezvous design while surfacesacknowledging several open engineering problems. Comments for authors -------------------- The paper identifies a real engineering pain point in circumvention rendezvous: small, unreliable, or unordered covert channels may be attractive for blocking resistance but awkward for transmitting rendezvous messages of a few kilobytes. The proposal to use fountain codes for this layer is sensible and explained well. The RaptorQ Payload ID optimizations for bounded rendezvous messages are modestly novel. Some concerns : * the prototype currently only uses simplistic UDP implementation , the authors claim "this is practical for encrypted-DNS rendezvous" , but an encrypted-DNS implementation is not actually tested. They sketch the DNS design, including recursive resolvers, QNAME encoding, TXT responses, padding, and session identifiers, but it is not evaluated against real resolver behavior, with latency, loss, caching, rate limits, detectability, or censor behavior. * The paper should be careful with the claim such as “one hop of encryption is sufficient.” This is true only under the stated assumption that the recursive resolver is outside the censor’s network and that the censor cannot observe the resolver-authoritative leg. If that assumption changes, the security argument changes. * No threat model is stated. What censor capabilities are assumed? Passive inspection of encrypted DNS metadata? Active probing of the authoritative server? * No quantitative comparison with the alternatives the paper itself raises. Although, the plausibility can be considered convincing enough and will probably become emperically clearer when first concern is addressed. * The paper provides enough parameters to infer the approximate query count for the Snowflake example, but it would be helpful to state this explicitly and discuss how the count changes under loss or traffic-shaping choices Review #20C =========================================================================== Overall merit ------------- 4. Accept Reviewer expertise ------------------ 3. Knowledgeable Paper summary ------------- This paper proposes the use of fountain codes to transfer small messages across a censoring firewall so that the invovled parties can establish a rendezvous channel. The paper describes an encrypted DNS-based rendezvous protocol, where a client can assemble a fountain coded message (broken into multiple chunks, as applicable), encode the into TXT queries, and send them via a recursive name server to the receiver. The receiver can reconstruct the original message once it receives enough chunks, and reply back to the client in TXT records. The protocol supports some degree of traffic shaping to combat censorship mechanisms based on pattern-matching, and the authors discuss limitations and future enhacements to the presented prototype. Comments for authors -------------------- This work tackles an important problem in the anti-censorship domain, and proposes a clever design for an encrypted DNS-based rendezvous mechanism. The paper reads well and I found the presentation to be clear. The manuscript also details the apparent limitations of the approach, which helps with the framing. I appreciated the details on positioning the work not against, but rather as a lightweight alternative, to more well-established options such as TurboTunnel or Raceboat. I also welcomed the technicalities on Section 4.1, where the engineering effort to quantify the usable space in DNS queries is well presented. The effort to come up with a way for enabling traffic shaping is commendable. At this point, this is pretty much a required characteristic for any protocol aiming at circumvention. Overall, this feels like a solid piece of work for FOCI. If anything, it would have been interesting to see some (even if preliminary) evaluation of the prototype -- for instance, what throughput/latency/overhead would one be expecting when establishing a rendezvous channel between sender/receiver placed in different continents? If time allows, this could perhaps be a rather straightforward addition to a final version of the paper.