Re: [Pearg] draft-irtf-pearg-censorship review

Christopher Wood <caw@heapingbits.net> Thu, 30 April 2020 23:00 UTC

Return-Path: <caw@heapingbits.net>
X-Original-To: pearg@ietfa.amsl.com
Delivered-To: pearg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850603A159C for <pearg@ietfa.amsl.com>; Thu, 30 Apr 2020 16:00:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=c3KoxS0y; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DILoE+NM
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQee4aheGe5d for <pearg@ietfa.amsl.com>; Thu, 30 Apr 2020 16:00:33 -0700 (PDT)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0A13A1551 for <pearg@irtf.org>; Thu, 30 Apr 2020 16:00:27 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id AD49A751 for <pearg@irtf.org>; Thu, 30 Apr 2020 19:00:26 -0400 (EDT)
Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Thu, 30 Apr 2020 19:00:26 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=LX6sS iFQHftlhg5ER+fIDiv4CrZpyi4Szo+cr6m4xK8=; b=c3KoxS0yywYlKUKoZn4hn v1Ni0gI1d9De9Zn6npxOIdi8mSVy5sqXtKQkVJ1vpxOFby3AT0O0ME6kqk6nDxn6 Xuf2ZRSIwL72gTDLusJAEUOCOkdeiN9Gp05G28FV7jhswSe9CSLtZqPtpo+QwAbz EnPcRIuSlAVKPA8bGDAqfrEgMRWwIBS7/7xNDmhSVsH82LS6Miqn5Vx32pb8NWHW sZkZCs2MzIuLpMZTnveQfc39c/YRGGsk4AmVY4zc6UzpDQbiuksJkXgExfzVN23u sWEth7wjShSBKhi240pmmyiWJmMmivRKDp5zD8tJlVD/X9WzcLprcv7PYaNcjS+e g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=LX6sSiFQHftlhg5ER+fIDiv4CrZpyi4Szo+cr6m4x K8=; b=DILoE+NMNZWE+XM2gmpdfHwhUAJVGWkfo0HfPjTReDqUPtLSSI1FTl6PM qHegAxCjubz6DX9XjDWD6dKs/Y8G2wOaDVfK5HZndNQ6g7l9B5wjjOE+lZ9urros zPPyjdJGVccWzxmA796eDmFWSLJu/voWxYoiMfE532s3x8CCPyW2NFciCExv/6vz yj5hyRe8Ebg4XP41DPDQjAAExaY2pmrteeto+pwJTqmmPJrJSlJq624q5gh6tqmr SyED/yxrS9/noKDBr3JYZRTtBDaWVHDqLqIBUVrds2AwbAsceZWMg8z8K14Z0hvo En6Jpx5bk/CPIc7WrhyUEctGw+NkQ==
X-ME-Sender: <xms:iVirXrI7F0sMHPNNQGlfCfTlJBsO9O30zQbtqTjzQa2yWJwq79Iuhw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrieeigdduhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucggtffrrghtthgvrhhnpedvieekjefhje eufffhgfehtdetfeeuieeuteekueevueduieduiefgtdetuefgudenucffohhmrghinhep uhhsvghnihigrdhorhhgpdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght
X-ME-Proxy: <xmx:iVirXjZMw904K53hKkwlt3BXibn96d5XiC-Wbdo64dSMic8hVUwoKg> <xmx:iVirXuvjErqDv1SFok0PSKvZFt6QVgJf4NHKh1VOvc1TJ-KoMM3cig> <xmx:iVirXos2cyjV0zKRtNatTnWSapIFtjaWrbS83IG5Nczi8DzM6z-7wA> <xmx:ilirXrikDnN00-Kgj3cx1bGYfApLYC99um5HKGjB5sATV1ZqAdOKnw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id CD9933C00A1; Thu, 30 Apr 2020 19:00:25 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1
Mime-Version: 1.0
Message-Id: <317d061c-1fdd-4c95-a24b-b9cc56fececf@www.fastmail.com>
In-Reply-To: <BY5PR06MB6451E16F6DDCE49B3444ECCFB1DC0@BY5PR06MB6451.namprd06.prod.outlook.com>
References: <fbf66d2f-cebc-4978-ad1d-26ccea08687b@www.fastmail.com> <BY5PR06MB6451E16F6DDCE49B3444ECCFB1DC0@BY5PR06MB6451.namprd06.prod.outlook.com>
Date: Thu, 30 Apr 2020 16:00:05 -0700
From: Christopher Wood <caw@heapingbits.net>
To: pearg@irtf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/pearg/WPnszpJSs-fKayjorMXpdvPiBLo>
Subject: Re: [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: Thu, 30 Apr 2020 23:00:56 -0000

On Sun, Apr 12, 2020, at 11:25 AM, Joseph Lorenzo Hall wrote:
> (also in the github issues)
> 
> > > Comments:
> > > 
> > > * 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."
> 
> Looks like you did this in PR #53, thanks!
> 
> > > * Section 3.2.4.1. 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.
> 
> Ah, we do cite Chai 2019 a bit later but I will elevate that... and 
> have just made changes to highlight ESNI and remove the SSL fallback 
> bit.
> 
> > > * 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.
> 
> Done.
> 
> > > * Section 3.3.2: Is it worth mentioning Pluggable Transports here, especially in the context of blocking Tor?
> 
> Done.
> 
> > > * 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).
> 
> Done.
> 
> > > * 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."
> 
> Done.
> 
> > > * Section 4.2.2: Is packet dropping not a form of filtering? I was surprised to see it in the interference section.
> 
> You may be hung up on the terminology we use where Identification is 
> doing the technical matching against a set of things one wants to 
> censor and then Interference is actually performing the technincal 
> action to accomplish the censorship or filtering, from the Terminology 
> section:
> 
> > Prescription is the process by which censors determine what types of material they should block, i.e., deciding to block a list of pornographic websites. Identification is the process by which censors classify specific traffic to be blocked or impaired, i.e., blocking or impairing all webpages containing “sex” in the title or traffic to www.sex.example. Interference is the process by which censors intercede in communication and prevents access to censored materials by blocking access or impairing the connection.
> 
> Do we need to make this more clear?

Not unless others were also confused! :-)

> > > * 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.
> 
> (That off-path paper is awesome! Had not seen that.)
> 
> Cool, that makes sense about QUIC. I don't have a good feel for what to 
> write here. How does this feel, "Note, the increasingly popular QUIC 
> protocol is based on UDP, a connection-less transport protocol, so 
> cannot be attacked using TCP RST packet injection."
> 
> That seems a bit weird... but it sounds like there may be more under 
> the surface to your comment so please suggest how that text above could 
> be better cleaned up?

I'd probably just say something like, "QUIC is not vulnerable to these types of injection attacks. See {{quic-draft}} for more details."

> > > * 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?
> 
> That is a monster, and something I'm looking forward to digging into 
> more. I'll drop a reference and add an Issue to read and integrate it.

Sounds good!

> 
> > > Nits:
> > > 
> > > * Section 2: SmartFilter is missing a reference.
> 
> Done.
> 
> > > * Section 3.1: "Internet Service Providers have until now been the most frequently exploited point of control" probably also warrants a reference, if possible.
> 
> Changed to "Internet Service Providers are frequently exploited points 
> of control."
> 
> > > * Section 3.2.1: The [Verkamp-2012] reference seems broken.
> 
> Hmmm, I don't see this. The link works ( 
> https://www.usenix.org/system/files/conference/foci12/foci12-final1.pdf 
> ) and the reference is rendering correctly. 

Oh, sorry, the link is working, it's the reference in the document (the forward pointer to the references section) that's broken (not clickable):

   https://tools.ietf.org/html/draft-irtf-pearg-censorship-02#section-3.2.1

Please let me know if you need help with these issues. I'm happy to lend a hand!

Best,
Chris