Re: [Pearg] descriptive censorship work: draft-hall-censorship-tech

Joseph Lorenzo Hall <> Tue, 23 July 2019 23:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ADF0112096F for <>; Tue, 23 Jul 2019 16:31:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T1zZBooLnCbF for <>; Tue, 23 Jul 2019 16:31:35 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 41D491201B5 for <>; Tue, 23 Jul 2019 16:31:35 -0700 (PDT)
Received: by with SMTP id s7so85470750iob.11 for <>; Tue, 23 Jul 2019 16:31:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8ClYS2wNhUHq7oWKBZlIU7SaQwgv93MM4tuvIDd0W8s=; b=j4lMgFCvqeWIrGNR1gKzUSNX4J4CdAvnShV0x3Aljt0VxX0fgR908oDOpiF1AXzHBe bV94Sob/UtQ134oClJz5fFRggc1dMCGlNLiKK/AxuMbmJ5tYCDpGu42zEaouy6svwavs QfTy3qjmtqJOwR1nSPCZhlBNva1Nj9N8OPsZI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8ClYS2wNhUHq7oWKBZlIU7SaQwgv93MM4tuvIDd0W8s=; b=DtdpIbuRt2ODH9KjX70ntWIQQaolflSu2/1SnSxQub6vaMl13a8l/hO/tG6qnME3B3 HMANhS6ck4fSLgodonQQdjsBC/9Y/m6azWdGaRK9As0NWPszOU/Hou15GfO4v3L+lFgl hBHJz1N5i0vMPTf6aWTjCs84Unoiw9tGjGfq9iu99zo4sCa2MB/dfb4ZRUOkXGDLT+il W07hkubkwLmExaPsQ5GcR9tbHGkJzX2+C/FTnN86S3SJTEHz7svd6f5ValLh9ML9pONm wCk+FUwN6IMY1x2ZxzFOexkDL2K1CeHD0pTPWyygBB1rzQqZpnw1zLwFJ+V1PJazdbyK GC8A==
X-Gm-Message-State: APjAAAWRM7U/mFuyXqiQrVWiHFO+BIJVS1X1Zx+2NbbIxNRdvZRCcsfw wTv8edBle6Zh06pGeGVmTvdTsmnESmRlFFVpJTtl/w==
X-Google-Smtp-Source: APXvYqxw2DhPKBXO3+MVQo+Gy1uXylr543B30G53Gxvc1KkRS5JMMdjF63UAUcS2OyrhEVhxvYj2QLkz7Z5j9Wi5aoM=
X-Received: by 2002:a5e:d507:: with SMTP id e7mr1827954iom.284.1563924694139; Tue, 23 Jul 2019 16:31:34 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Joseph Lorenzo Hall <>
Date: Tue, 23 Jul 2019 19:31:22 -0400
Message-ID: <>
To: Shivan Sahib <>
Cc: Stephen Farrell <>, Stan Adams <>, Nick Feamster <>,
Content-Type: multipart/alternative; boundary="000000000000d99f23058e6197da"
Archived-At: <>
Subject: Re: [Pearg] descriptive censorship work: draft-hall-censorship-tech
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhancements and Assessment Proposed RG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Jul 2019 23:31:38 -0000

On Fri, May 17, 2019 at 5:00 PM Shivan Sahib <> wrote:

> Hi Stephen,
> On Fri, May 17, 2019 at 12:58 AM Stephen Farrell <
>> wrote:
>> ...
>> -1 to extending the scope. That could be done in other
>> documents, each of which would likely take some time. FWIW,
>> personally, I'd recommend just getting this one to the
>> RFC editor queue, pocketing the progress, and then the RG
>> can move on to new documents documenting other mechanisms
>> for and countering censorship.
>> Cheers,
>> S.
> The suggestion to include censorship-countering techniques came up because
> of the concern that as the draft stands, it would not fall under PEARG's
> charter. Happy to hear disagreements about that though.

Heya Shivan,

I'd love to hear more elaboration here tomorrow about this (or on the list
if you have time before then).

I looked at the Charter and like Stephen I'm not necessarily seeing where
it would require a descriptive draft about techniques also talk about
mitigations. I suspect that RFC 6973's structure of "privacy threats" and
"threat mitigations" is where the linking between threats and mitigations
might come from in your mind? (So it's an implicit part of the Charter by
reference to 6973?) Or maybe I'm missing a more direct link in the Charter

I can take a look at the text and see how heavy of a lift that would be to
add mitigations... but my initial sense is that a quick addition to each
technique subsection that listed mitigations -- instead of a new big
section divorced from the specific techniques -- that have been known to
work might not be so hard. E.g., "Configuring different DNS endpoints
manually can get around some basic forms of DNS-based censorship".

What I do worry about is that mitigations change faster than censorship
techniques themselves (do people agree?), so this might be a place where
there could be a lot of cruft (if we keep things) or document churn (if we
remove outdated things)... for example, how should this document talk about
domain fronting now that that's increasingly not a thing? Should it talk
about it as an effective mitigation at one time? Or since it's not so
effective anymore, should it drop discussion of fronting altogether?

(of course, some of this is wrapped up in how often this kind of document
might need to be updated...)