[Pearg] draft-irtf-pearg-censorship review

Christopher Wood <caw@heapingbits.net> Sat, 11 April 2020 02:48 UTC

Return-Path: <caw@heapingbits.net>
X-Original-To: pearg@ietfa.amsl.com
Delivered-To: pearg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 189DB3A15D0 for <pearg@ietfa.amsl.com>; Fri, 10 Apr 2020 19:48:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=glG1rjfq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=1XD2Y1ks
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 2Ui8kY6nxJ1S for <pearg@ietfa.amsl.com>; Fri, 10 Apr 2020 19:48:43 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4A813A15CE for <pearg@irtf.org>; Fri, 10 Apr 2020 19:48:43 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 3A97B487 for <pearg@irtf.org>; Fri, 10 Apr 2020 22:48:43 -0400 (EDT)
Received: from imap4 ([]) by compute1.internal (MEProxy); Fri, 10 Apr 2020 22:48:43 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm1; bh=L+CAwZE4qYe4Qpm6JjMwUCKN46K7s7yQDQ+BkpZJOas=; b=glG1rjfq +8J+rRX6AVwNIh5cVlMs8T4VKDHZDvZ5tHqC37MLoVGXzxnrjLYL5lCTVpUqlIFx /Q/aEOpFQxpvZqhCbSNATOoMQvhoiCIV8H/GfwK4YuYfSULOvtXgKeDobty2AIiW NWBBeQJBMzEhtCKhgLHO3eHvNYSEimHjJYKeGZm/lRu8umwhZVjT5TvnVSk6eCDL GDpmjmekIWzyc3i62xY+iUk0zrv4hQ8JTsFO/hRmU1MG2mdEmQg9e8HUWFZ/hgox crkhDRmVjsIijCLopMQfVLvc/UvKIz9UatbZ1HQvWrcDb0Ep3gyX485RXbdJGvGn IB0i84Q+5/6lhA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=L+CAwZE4qYe4Qpm6JjMwUCKN46K7s 7yQDQ+BkpZJOas=; b=1XD2Y1ksztYc+58RomPCl91cvyP4oGZY0YYCzpzV2uQiR kwbrqlLpN8g1nYDKx9CuwtQK36fyoxrxk0thgEjYL5ujjtSJOv7B8unOfvpQYgda Cyh1jZJ1e7b6oSCFvDlIo21mEWovwzA3MJeX5WI7fV6voJR8ygYd5yh8Ec6if3Hc stB0c6SIzK0YW5b3zbM3xQoQJa4GLUsNAE+NGqZRkYITwHOz2vh9ubmEOxeNPT1j RJHjWYr9JSVlNQmjnLFa+ggUAU81mlIWfilwqaI0e4hwWvffiyBxgcqBINIM5Tlh rNbyh4dVATKR2tnZ0Np+VW16aOnDgFhwO44BMrWCg==
X-ME-Sender: <xms:CjCRXiOrsz7ZdLga5cNh9X9qLSHhEjSe4UJDa8ygm6CnlejMpScO0g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrvdefgdehkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtredtre ertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfieshhgv rghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghdpghhith hhuhgsrdgtohhmpdhushgvnhhigidrohhrghdpihhrthhfrdhorhhgpdhumhgurdgvughu necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheptggrfi eshhgvrghpihhnghgsihhtshdrnhgvth
X-ME-Proxy: <xmx:CjCRXtv5z9kNSQ01tlWjRXho8WZBW29CJK52eVXbIAvZPkZAplxI-A> <xmx:CjCRXj2kgDL93xp0fDVAzTO4vmvb7aX_mehCkySL1jtTR0KyrbD8Hw> <xmx:CjCRXl92jm7UsYKifn_9Mixn7-GFOA98Rh3ckbZUoUVcq6AIxRn3ew> <xmx:CjCRXvaiyreV0QnsgHeewqM7zggtFHcKD6nF3z2ObT6zTSmpcHNUTQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 55D153C00A1; Fri, 10 Apr 2020 22:48:42 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-1104-g203475c-fmstable-20200408v2
Mime-Version: 1.0
Message-Id: <fbf66d2f-cebc-4978-ad1d-26ccea08687b@www.fastmail.com>
Date: Fri, 10 Apr 2020 19:48:22 -0700
From: "Christopher Wood" <caw@heapingbits.net>
To: pearg@irtf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/pearg/SVyIg4T9KdHufT3FKtHD5eMMCrI>
Subject: [Pearg] draft-irtf-pearg-censorship review
X-BeenThere: pearg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhancements and Assessment Proposed RG <pearg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/pearg>, <mailto:pearg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pearg/>
List-Post: <mailto:pearg@irtf.org>
List-Help: <mailto:pearg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/pearg>, <mailto:pearg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Apr 2020 02:48:46 -0000

Document: draft-irtf-pearg-censorship-02 [https://tools.ietf.org/html/draft-irtf-pearg-censorship-02]

Assessment: Almost ready

Thanks for your work on this document! It has a lot of very useful information. I think it's nearly ready to go with some cleanup and additional references.

Below is my review of its contents (with no hat on). I prepared an editorial PR --- aiming towards format consistency -- against the draft repository [0]. I hope it's useful! 


- Section 3.2.1: This section describes common ways in which censors use HTTP fields for filtering with a pile of references at the bottom. Upon first read, it seemed to lack relevant citations. (For example, the sentence

   As such, "method" and "host" are the two fields used most often for ubiquitous censorship.

seemed like it could stand to use a reference. However, this seems to be covered by one of the empirical examples at the end of this section. Perhaps Section 3.2 could note this structure for each of its subsections? Perhaps:

   "The following subsections describe properties and tradeoffs of common ways in which censors filter using application-layer information. Each subsection includes empirical examples describing these common behaviors for further reference."

- Section should probably reference draft-ietf-tls-sni-encryption or draft-ietf-tls-esni. (I'm happy to help word-smith that text, if you want or need assistance!) Also, the bit about fallback to SSL (pre TLS 1.0) seems a bit outdated. Most TLS stacks no longer implement SSLv3 at all, for example. I might remove this bit. I might also include a reference to [1] as further SNI-based blocking reading. 
- Section 3.3.1: Assuming that IP address filtering is efficient, it might be worth citing [2] given that it studies the (often unique) relationship between address and domain. It might also be worth mentioning DoH(443) and noting the challenges it raises for blocking parties. 
- Section 3.3.2: Is it worth mentioning Pluggable Transports here, especially in the context of blocking Tor?
- Section 3.3: I was surprised to see no mention of QUIC in this section. Perhaps we could replace "TCP/IP header" references with "transport header references"? The information about network addresses and ports equally applies to TCP and QUIC, and including both seems prudent so as to not give the wrong impression about what QUIC exposes (or doesn't).
- Section 4.4.1: There's no mention of encrypted DNS here. While it's true that "DNS lying" and other examples are not completely mitigated with stub-to-resolver encryption, it does change the threat model slightly. Maybe DoH/DoT are worth including? It might also be worth noting limited client support for DNSSEC, perhaps after this sentence: 

   "Additionally, the above mechanisms rely on DNSSEC not being deployed or DNSSEC validation not being active on the client or recursive resolver."

- Section 4.2.2: Is packet dropping not a form of filtering? I was surprised to see it in the interference section. 
- Section 4.2.3: It's probably worth mentioning QUIC here, especially as it complicates this type of attack. It might also be worth citing recent research [3] on off-path TCP attacks, noting that the censor need not be on-path to interfere with service.
- I was surprised to see this recent SoK paper [4] missing from the references. It has a lot of additional information, particularly in Tables V and VI, about different types of filtration mechanisms and how they impact users (by under or over blocking). That said, integrating this paper will be a chore. So, given that the landscape of relevant research and empirical evidence will undoubtedly continue changing, perhaps we can simply drop a reference somewhere?


- Section 2: SmartFilter is missing a reference.
- Section 3.1: "Internet Service Providers have until now been the most frequently exploited point of control" probably also warrants a reference, if possible.
- Section 3.2.1: The [Verkamp-2012] reference seems broken.

[0] https://github.com/josephlhall/rfc-censorship-tech/pull/53
[1] https://www.usenix.org/system/files/foci19-paper_chai_update.pdf
[2] https://irtf.org/anrw/2019/anrw2019-final44-acmpaginated.pdf
[3] https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_cao.pdf
[4] http://www.cs.umd.edu/class/fall2018/cmsc818O/papers/sok-censorship.pdf