From nobody Mon Jun 1 04:14:36 2020 Return-Path: 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 5D5B83A0F4D for ; Mon, 1 Jun 2020 04:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, TRACKER_ID=0.1, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 GsfOnv6oSN3W for ; Mon, 1 Jun 2020 04:14:33 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680065.outbound.protection.outlook.com [40.107.68.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BED13A0062 for ; Mon, 1 Jun 2020 04:14:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XYs4IzM2jCXCu0uGr8hFkxG54pNRFupmtGhwYIVpFwkQixrT2W1fdQHpFKAgg0xTxXbBzFpo6pabKad1c5OhBdEzqkUsLxJyrnXN8+q9jM33rsH75kg95+8eWFR9Ud0UhbcT5nvlT9V+ehNG56vjZ5S5qLVIsxhE0zwoKF3HNQdgkrHDxRjU4laVBH6AJo4M1rUTb0wwg+iy+ewsjKc7ifzHdlzbR7euzjrSj4AOP9yFoBiFiBHFwb0tpMudfEEhcVRxj7RGRRZhVCujkYQj76Ohn6cIe44fRRzrqGGsnoK6nU9njwrzXE+SbeAFCKuJ5LyyVWP45SJ1R7CxWIFXyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VLFPu+c45pVFhOCN068Zs5AIAI61SlCfEwCMFHvRFr4=; b=lP7OBiNeWRaP0qeZpm2p3WU+X1j1YQbeyGakDSOrqGHFPqvUIMT4Mga1grOrcNjdajoDiOfXKMl0uZJYdhdf84FkPiya1BzbF6B+lBc0S7TBtlGgjAC3018ThfCibyrbGgIuMSTiY1ut05d9p3g/UkFWrSpA+d0h9XF5/0qMniPJIgN24dgqMlOWndxT2pMDGQeVPZVwllshLFwSIW81TFDOK3/6iawdC4tzCNAqMQgjVHOBJjxq10FrJTN2HFa4PhQtGETFXDJ88AXC9+bUBFsXMrnW+PQWl7u+293sqdmB2XsqXUikE6piZAz1rZVin6wZF0kRwp+HBgszhDGWqw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VLFPu+c45pVFhOCN068Zs5AIAI61SlCfEwCMFHvRFr4=; b=Ua9KucIh9xcz6DVSm5VVxL1HzhzDJYaROUu1WhtSpzRa5U77axVRDFbIXOw+NoFL1yyE0pPDcYXf3KlWOxzVFwnCY9a3GxkJ5+UXdc9hoFPUVs1NbueG2Tk5ws1Gq/ROl+Csq9IBiadQuoNHC6umpeB4GCaJgUQbdGxUJs3MmeI= Received: from BY5PR06MB6451.namprd06.prod.outlook.com (2603:10b6:a03:21e::20) by BY5PR06MB6660.namprd06.prod.outlook.com (2603:10b6:a03:237::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.17; Mon, 1 Jun 2020 11:14:25 +0000 Received: from BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::b9b7:f0a7:b076:d5d5]) by BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::b9b7:f0a7:b076:d5d5%5]) with mapi id 15.20.3045.024; Mon, 1 Jun 2020 11:14:25 +0000 From: Joseph Lorenzo Hall To: David Oliver , Eliot Lear CC: "pearg@irtf.org" Thread-Topic: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques" Thread-Index: AQHWLsgqnBPhO5w6N0yNNHBtsaHVYqi6K/EAgAB164CABjUtAIAAN6YAgAKeDUk= Date: Mon, 1 Jun 2020 11:14:24 +0000 Message-ID: References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <8D179E05-AFAC-4B93-890E-E2D8A5F4EF03@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: guardianproject.info; dkim=none (message not signed) header.d=none;guardianproject.info; dmarc=none action=none header.from=isoc.org; x-originating-ip: [108.28.51.147] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 58dadd54-ccfd-4ed2-c335-08d8061cf15c x-ms-traffictypediagnostic: BY5PR06MB6660: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0421BF7135 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xmOmHR2x6rVImoImEVe7TQRidSJHqE14IFNaQFijRySPXdm3sOa8Iac7QZnkfLDat/YVHTmYiGD+AliH12Ms0OY4tvSjQUTn6FYMzRAsuQBhaM87NNgTIv4OWsQ3jljZehtYosCyseBk+eWQlgF3/BVsKSWYo8VQbpPHU5iMF5W2mkq6Xm0uKCudW+Hl2GsnMG1gOcAsAayAqrCOe6BzUjNqvOTCLoix3f3QhcVA0yX25hf1bvna7KrAPO/UgFAtrPqyv1z/Y0YgUYKbxTizhu7I/XG9tuu8mGRQLtgs5o9ckb/0Ncy22X5/r/La5vOsd2D45AixpBRT851EIcevTNme787KsrG1As7xkNiZnvyo0lEQpfKAxyjqDHtbf45dIl9/71y2vUqcrwMvH1hHjU/MHqaIVW3sBsXn59Hhh0IGuE8WVQja+Y+BZgu286gP2eXquRkelsDOgdfT15bQfg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR06MB6451.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(366004)(39840400004)(136003)(376002)(346002)(396003)(209900001)(66446008)(64756008)(76116006)(66476007)(66946007)(66556008)(8936002)(966005)(8676002)(83380400001)(478600001)(110136005)(316002)(86362001)(53546011)(6506007)(166002)(71200400001)(2906002)(26005)(186003)(66574014)(9686003)(33656002)(83080400001)(7696005)(5660300002)(52536014)(4326008)(55016002)(6606295002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Fxu7f4CKX42npCFADzSIii79v2lWuSquP8sUYDgXmTQsc0dWyc1AQqtCiXaWB4YmEhTVFvQ1QHMQBHrjGsNoLxrqM/d4XK168k7RjPJZEQaT2HPzFIb9LXkPd6y1prOY+pFMVSkX85N0qPT6egi2uuErjj4o2ALSwlCFb1nHo+qVW/QbbrAgED/t71kchT3hvDM28H929l7lYzXPqTtQydmwO2vZSMlaKj/1z4/gOEFW5JgdHHxPWipenKMwtVl2qXr3OUSc+eyilxzscRzyKCwxUvSTUehgrR0aFx2Jd+gr/f7jTxMl6BMUGjvJS5lZB1V63BuuGvsc2GUM2jSFCcYrL3ZvN+7J0YOUyZy5gWd1a9eePmY+w1VDYCzd6ma5o37DiGoDHv1ZEQHM+1tn3eqEC5oPTyEtQf2OyNhuqLP/4poWZAfJcSJTZMoaxarwQS873r2FdHwaiVROY0LthGRnz9EgkChyvQFsxG+xCbM= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR06MB6451AA8AE3E3787EBC086760B18A0BY5PR06MB6451namp_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 58dadd54-ccfd-4ed2-c335-08d8061cf15c X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2020 11:14:24.9840 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EdJxSFQm0B0UZsPqZKe5JtLf8t+MUxbAQsFVKtdV/d5qHQeco3Vcb5+FgjVjA2ic X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR06MB6660 Archived-At: Subject: Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques" X-BeenThere: pearg@irtf.org 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: Mon, 01 Jun 2020 11:14:35 -0000 --_000_BY5PR06MB6451AA8AE3E3787EBC086760B18A0BY5PR06MB6451namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The Tschantz SOK reviews empirical studies and findings about what censors = have done in order to inform academic study of censorship circumvention, so= quite useful for a this document (even if we don't go into the ongoing sag= a of the circumvention arms race). -- Joseph Lorenzo Hall, Senior Vice President, Strong Internet hall@isoc.org | +1-703-483-9504 internetsociety.org | @internetsociety pgp: https://josephhall.org/gpg-key 3CA28D7B9F6DDBD34B1016075F86698740A9A871 ________________________________ From: Pearg on behalf of David Oliver Sent: Saturday, May 30, 2020 3:11:30 PM To: Eliot Lear Cc: pearg@irtf.org Subject: Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Ce= nsorship Techniques" > Be a bit more explicit as to what the relevancies are. I was actually wondering the opposite: Why *are* circumvention methods ment= ioned in this document? Should I work on the assumption that "why" was has= hed out in discussion of earlier drafts? David David M. Oliver | david@guardianproject.info<= http://uardianproject.info> | http://guardianprojec= t.info | @davidmoliver | +1 970 368 2366 On Sat, May 30, 2020 at 11:52 AM Eliot Lear > wrote: Mallory, I wanted to come back to something you wrote: On 26 May 2020, at 19:04, Mallory Knodel > wrote: Because while there are indeed recognized legal, legitimate and proportiona= l reasons why the rights to free expression and to access information shoul= d be violated, censorship measures should not be taken without careful cons= ideration as it is a human rights matter. Regardless of the terminology, it seems to me that there is another aspect = that the document could capture that is related to the IETF. In the introd= uction, the authors write: There is also a growing field of academic study of censorship circumvention (see the review article of [Tschantz-2016]), results from which we seek to make relevant here for protocol designers and implementers. I wonder if it would be good to elaborate this. Be a bit more explicit as = to what the relevancies are. Are these cautionary tales for instance, wher= ein some cases the use of the technology for censorship was not what the en= gineers had in mind? How would you like engineers to evaluate technology t= radeoffs? This allows us to address one additional point that I=92d suggest the RG to= consider: the document motivation could be strengthened. Why is this doc= ument important? Who is it relevant to? This might also explain why there= is no conclusion or desired next steps. Good that they've enumerated vari= ous mechanisms. Would they like the IETF to review those points with an ey= e toward avoiding inadvertent avenues to additional censorship? What if an= ything would be good for PEARG to follow up? I=92m not suggesting many par= agraphs, but one or two wouldn=92t be out of line. Eliot -- Pearg mailing list Pearg@irtf.org https://www.irtf.org/mailman/listinfo/pearg --_000_BY5PR06MB6451AA8AE3E3787EBC086760B18A0BY5PR06MB6451namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The Tschantz SOK reviews empirical studies a= nd findings about what censors have done in order to inform academic study = of censorship circumvention, so quite useful for a this document (even if w= e don't go into the ongoing saga of the circumvention arms race).

--
Joseph Lorenzo Hall, Senior Vice President, = Strong Internet
hall@isoc.org | +1-703-483-9504
internetsociety.org | @internetsociety
pgp: https://josephhall.org/gpg-key
3CA28D7B9F6DDBD34B1016075F86698740A9A871
From: Pearg <pearg-bounc= es@irtf.org> on behalf of David Oliver <david@guardianproject.info>= ;
Sent: Saturday, May 30, 2020 3:11:30 PM
To: Eliot Lear <lear=3D40cisco.com@dmarc.ietf.org>
Cc: pearg@irtf.org <pearg@irtf.org>
Subject: Re: [Pearg] Research Group Last Call for "A Survey of = Worldwide Censorship Techniques"
 
> Be a bit m= ore explicit as to what the relevancies are. 

I was actually wondering the oppo= site: Why *are* circumvention methods mentioned in this document?  Sho= uld I work on the assumption that "why" was hashed out in di= scussion of earlier drafts?

David 

On Sat, May 30, 2020 at 11:52 AM El= iot Lear <lear=3D40cisco.c= om@dmarc.ietf.org> wrote:
Mallory,

I wanted to come back to something you wrote:

On 26 May 2020, at 19:04, Mallory Knodel <mknodel@cdt.org> wrote:

Because while there are indeed recognized legal, legitimate and proportional reaso= ns why the rights to free expression and to access information should be vi= olated, censorship measures should not be taken without careful considerati= on as it is a human rights matter.

Regardless of the terminology, it seems to me that there is another as= pect that the document could capture that is related to the IETF.  In = the introduction, the authors write:

   There is also a growing field of
   academic study of censorship circumvention (see the review article of
   [Tschantz-2016]), results from which we seek to make relevant here
   for protocol designers and implementers.
I wonder if =
it would be good to elaborate this.  Be a bit more explicit as to what the relev=
ancies are.  Are these cautionary tales for instance, wherein some cases the use of the technology f=
or censorship w=
as not what the engineers had in mind?  How would you like engineers t=
o evaluate technology tradeoffs?
This allows =
us to address one additional point that I=92d suggest the RG to consider:  the document motivat=
ion could be strengthened.  Why is this document important?  Who is it rele=
vant to?  This might also explain why there is no conclusion or desired next steps.=
  Good that they've enumerated various mechanisms.  Would they li=
ke the IETF to review those points with an eye toward avoiding inadver=
tent avenues to additional censorship?  What if anything would be good=
 for PEARG to follow up?  I=92m not suggesting many paragraphs, but on=
e or two wouldn=92t be out of line.
Eliot
--
Pearg mailing list
Pearg@irtf.org
https://www.irtf.org/mailman/listinfo/pearg
--_000_BY5PR06MB6451AA8AE3E3787EBC086760B18A0BY5PR06MB6451namp_-- From nobody Tue Jun 2 07:31:09 2020 Return-Path: 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 EB7D83A0061 for ; Tue, 2 Jun 2020 07:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=gmail.com 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 ikNIk4EkOaKi for ; Tue, 2 Jun 2020 07:31:05 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD2A83A00C4 for ; Tue, 2 Jun 2020 07:31:04 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id u26so2383216wmn.1 for ; Tue, 02 Jun 2020 07:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IAo1ZjmawFnGSfMSBid1PWaBlD0nqVkRV+rpW6m6XSw=; b=CLHzJ9eS0IMvRnZ4oz8leGcDnCJsV9pFf+c7SJaSz+nRnJDkLUsqfKstubxXYWY2Wi dzKISEwnwkkfajtNVys9+xoCFlxqD4C+ob5T8yjjgaT/j1zsDUeYzXK3ai1TgNvGy8CO 38awZ6P7jsM+utPgvBdbu3spJI65YLQgfimhHB/n0g5C1NGfZU41FG5C9FmOfBr0odk2 XATBJOa64xHLNcf63HOqfins1340ZbA0j8E/1zOXiTiVcDvHhi/3VgYbl3xDD6JoVtuN 7a9nPYOnDC8fmIMOZwBcHMkaeA203sTK7TRplp00eLuinBF2orEg/JLAYU6F0Ju4uMg1 YmHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IAo1ZjmawFnGSfMSBid1PWaBlD0nqVkRV+rpW6m6XSw=; b=a2RbgPaMkAiSA4kL/lMdmT5J8rI1tmqnZzXiUTDq5Nxm/OrFQvMCFTGJ2M7zgKIex3 6YmkIrEXPfXhz2JX3MqRsWbl81CADnd6Ey+qOJX+GtsSO71GB4ZBmcTFR+wHAz3FeHRs Dda4cXwBnJIH0i8rxMhhQWFaj4qVq9cV/9/vtCWkGwB/ThVfZgbkx4EqP39STzxIQR5r 5691N3QdtYFFVVwI3V9LEHJSmguUh3q5Mg+xn/oo63LPMH1a0QKCusbSWNg/vuuy2Gda /yygqbAArBgh+dI3uYvLyPxCKZrMcy23TEl6Wq4yv7ndKpvgSKWPpDFb5DtlfK/RjFDo md4A== X-Gm-Message-State: AOAM531HCvck64r0hV54QpF6QgB3K2CaCTgw0upzzGC6opvos22QWsnt H4jIceo8p1kresefcW3Z4bAsezxo7kcRSi4XVAtkBj1y X-Google-Smtp-Source: ABdhPJxnhcYi4EKvHmepOFP6Mwbwn4satuNRx1PK51zgxQMeRXJRyuRTcuBTvuVfDf45PBeGVv/jTpnpiDrl8A28lbU= X-Received: by 2002:a1c:7fc5:: with SMTP id a188mr4678725wmd.59.1591108263314; Tue, 02 Jun 2020 07:31:03 -0700 (PDT) MIME-Version: 1.0 References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> In-Reply-To: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> From: Chelsea Komlo Date: Tue, 2 Jun 2020 08:30:50 -0600 Message-ID: To: Christopher Wood Cc: pearg@irtf.org Content-Type: multipart/alternative; boundary="000000000000d5894405a71ac2f8" Archived-At: Subject: Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques" X-BeenThere: pearg@irtf.org 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, 02 Jun 2020 14:31:07 -0000 --000000000000d5894405a71ac2f8 Content-Type: text/plain; charset="UTF-8" Hi Chris, I have a couple meta points and a few specific points. Overall, my strongest recommendation is threefold. First, I recommend improving the document organization to clearly differentiate between a specific censorship technique and corresponding methods to circumvent that technique. Second, I suggest strengthening the review of current circumvention techniques and their effectiveness to give an improved view of the landscape and to prevent re-inventing the wheel, as the intended audience is protocol designers. Third, I recommend differentiating between the capabilities of mature censors like China, and weaker censors such as those with only off-the-shelf tools. Here is my discussion of these points in more detail. === Meta Points === - While I understand this draft to be purely informational, understanding censorship today is incomplete without understanding existing censorship circumvention techniques, and how effective these techniques are. Critically, some of the most effective and safe censorship techniques are "hanging by a thread" in terms of how much longer they will be available (such as domain fronting), so understanding these weak areas is important to understanding the sustainability of the current circumvention landscape. I suggest adding at minimum a discussion of "Where are we today" regarding circumvention. - To go along with the above point, providing a better review of existing censorship circumvention techniques will help encourage building on existing work, as opposed to re-inventing the wheel from first principles. While perhaps this review should be a follow-up document, I strongly encourage providing such a review, especially since the intended audience is protocol designs. - Within the draft itself, the discussion of censorship techniques is often interwoven with circumvention methods. I suggest separating these concepts out within each section. Instead of a "Tradeoffs" section, perhaps have sections pertaining to "Cost to Implement to Censor", and "Techniques to Circumvent", for improved clarity. - One important point is that while China is an extremely powerful censor, they are often in a class of their own. I encourage including a discussion of something like "censor maturity" or the technical resources required to implement different techniques. There is a bit of this discussion, but it can be better standardized and applied to each technique. For example, IP blacklisting is trivial and does not require significant infrastructure (and many censors do this), but performing active probing to fingerprint protocols and block them on the fly requires much more infrastructure and planning (and is essentially only China, as I understand). === Specific Points === - DPI (deep packet inspection) is technically any kind of packet analysis beyond IP address and port number- this concept can be better clarified. Further, this technique is not specific to - Clearly highlighting techniques that are thwarted by the use of TLS versus techniques which can be performed even in spite of TLS usage would also likely be helpful to readers. Thanks, Chelsea On Wed, May 20, 2020 at 11:00 AM Christopher Wood wrote: > This is the research group last call for the "A Survey of Worldwide > Censorship Techniques" (draft-irtf-pearg-censorship) draft available here: > > https://datatracker.ietf.org/doc/draft-irtf-pearg-censorship/ > > Please review the document and send your comments to the list by June 5, > 2020. Feedback may also be sent to the GitHub repository located here: > > https://github.com/IRTF-PEARG/rfc-censorship-tech > > Thanks, > Chris, on behalf of the chairs > > -- > Pearg mailing list > Pearg@irtf.org > https://www.irtf.org/mailman/listinfo/pearg > -- Chelsea H. Komlo --000000000000d5894405a71ac2f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Chris,

I have a cou= ple meta points and a few specific points.

Overall= , my strongest recommendation is threefold. First, I recommend improving th= e document organization to clearly differentiate between a specific censors= hip technique and corresponding methods to circumvent that technique. Secon= d, I suggest strengthening the review of current circumvention techniques a= nd their effectiveness to give an improved view of the landscape and to pre= vent re-inventing the wheel, as the intended audience is protocol designers= . Third, I recommend differentiating between the capabilities of mature cen= sors like China, and weaker censors such as those with only off-the-shelf t= ools.=C2=A0

Here is my discussion of these points = in more detail.=C2=A0

=3D=3D=3D Meta Points =3D=3D= =3D
- While I understand this draft to be purely informational, u= nderstanding censorship today is incomplete without understanding existing = censorship circumvention techniques, and how effective these techniques are= . Critically, some of the most effective and safe censorship techniques are= "hanging by a thread" in terms of how much longer they will be a= vailable (such as domain fronting), so understanding these weak areas is im= portant to understanding the sustainability of the current circumvention la= ndscape. I suggest adding at minimum a discussion of "Where are we tod= ay" regarding circumvention.
- To go along with the above po= int,=C2=A0 providing a better review of existing censorship circumvention t= echniques will help encourage building on existing work, as opposed to re-i= nventing the wheel from first principles. While perhaps this review should = be a follow-up document, I strongly encourage providing such a review, espe= cially since the intended audience is protocol designs.=C2=A0
- W= ithin the draft itself, the discussion of censorship techniques is often in= terwoven with circumvention methods. I suggest separating these concepts ou= t within each section. Instead of a "Tradeoffs" section, perhaps = have sections pertaining to "Cost to Implement to Censor", and &q= uot;Techniques to Circumvent", for improved clarity.=C2=A0
-= One important point is that while China is an extremely powerful censor, t= hey are often in a class of their own. I encourage including a discussion o= f something like "censor maturity" or the technical resources req= uired to implement different techniques. There is a bit of this discussion,= but it can be better standardized and applied to each technique. For examp= le, IP blacklisting is trivial and does not require significant infrastruct= ure (and many censors do this), but performing active probing to fingerprin= t protocols and block them on the fly requires much more infrastructure and= planning (and is essentially only China, as I understand).=C2=A0

=3D=3D=3D Specific Points =3D=3D=3D
- DPI (deep p= acket inspection) is technically any kind of packet analysis beyond IP addr= ess and port number- this concept can be better clarified. Further, this te= chnique is not specific to=C2=A0 =C2=A0
- Clearly=C2=A0highlighti= ng techniques that are thwarted by the use of TLS versus techniques which c= an be performed even in spite of TLS usage would also likely be helpful to = readers.=C2=A0

Thanks,
Chelsea

On W= ed, May 20, 2020 at 11:00 AM Christopher Wood <caw@heapingbits.net> wrote:
This is the research group last call for t= he "A Survey of Worldwide Censorship Techniques" (draft-irtf-pear= g-censorship) draft available here:

=C2=A0 =C2=A0https://datatracker.ietf.o= rg/doc/draft-irtf-pearg-censorship/

Please review the document and send your comments to the list by June 5, 20= 20. Feedback may also be sent to the GitHub repository located here:

=C2=A0 =C2=A0https://github.com/IRTF-PEARG/rfc-cens= orship-tech

Thanks,
Chris, on behalf of the chairs

--
Pearg mailing list
Pearg@irtf.org
https://www.irtf.org/mailman/listinfo/pearg


--
Chel= sea H. Komlo
--000000000000d5894405a71ac2f8-- From nobody Tue Jun 2 07:36:00 2020 Return-Path: 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 A44A03A07D8 for ; Tue, 2 Jun 2020 07:35:58 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 w16YWc4Yp5I5 for ; Tue, 2 Jun 2020 07:35:56 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2073.outbound.protection.outlook.com [40.107.92.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A9E03A07D4 for ; Tue, 2 Jun 2020 07:35:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gxz6LKYWx/AaAAGrICKJeKUtP9qafOVPpMlaQZD6zjqVW4EZeO72E2VzZBx0utUlGQFldlpJOI9+nFNFBZNaUBh75/VHxkkCgHiXl3+6s/Jbf6AN62KWdHJd7QgtYaJygDTHkXHtlFdWWG7vJtnMk8a6u7yN4YOBV42VTe6oyZv7IvA33wk0EpIOPe6e145+oZTFZ9PZTk5IBcVCbpSY0G/f4bKPq7+PZpmUM992mTYJ7Twy3q4aHG+xjPPSu8TkUwAQqZ7QN+Ipsn4Uh0cHjb3NGAa1ui1hcRMtysqDSpRibytM24XFaxgn/t9dpacWPnWP4EJP6J8lXhObXNt8Tg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bIZeQ3qb/VAxGmZ3j/oBLAQc/lKQw3IZV0JrOXJT3+I=; b=m/owGZMLxfAb1yMp2oBt0pqcKdnVmH5lPxSWxcQMX60sdbcoACxh2QrOKT2act9lhTvgQA7Jfnekecapk/G03PER7y+Rmw5116ia55IbpYGf6sTcqwVy03a3iDAcUUAZDPTdUCNZ24J+2ZQqb33JN5xqD8jA4hQMG6V4yczUeb/mbUYEH4BzQmluEUeCObcmdBstYbxA8WlsfCSxfRdxupJE7D/Sozr7CTY0fNC8AUWA/91ntp9/kYgL26E7OUvE1vPk/iVRWLN49FpJ6EvkYiuqasIIlX+FjgWVj5hUQiRb1VgXIz9MxpuPB7SpQ1XXuUDCqdG/zYbqX3Cm6kbEfQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bIZeQ3qb/VAxGmZ3j/oBLAQc/lKQw3IZV0JrOXJT3+I=; b=G69OAzVDQWbtlGDF5J1Vk50GDQSAsl9xFHaW9+nHEAqP0ZyTi8bUEJAsGHzBouUJIibk2lwntdh+rK72mtVp3HCxzO3pyXJeOzDXgHTFkyCmFWHMBko8s4A6rL6Zx6hlmG8XZ4KJf2qdZNOMA05VOKPAC00ej899ch9liAOynY4= Received: from BY5PR06MB6451.namprd06.prod.outlook.com (2603:10b6:a03:21e::20) by BY5PR06MB6561.namprd06.prod.outlook.com (2603:10b6:a03:21c::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Tue, 2 Jun 2020 14:35:53 +0000 Received: from BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::b9b7:f0a7:b076:d5d5]) by BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::b9b7:f0a7:b076:d5d5%4]) with mapi id 15.20.3066.018; Tue, 2 Jun 2020 14:35:53 +0000 From: Joseph Lorenzo Hall To: Chelsea Komlo , Christopher Wood CC: "pearg@irtf.org" Thread-Topic: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques" Thread-Index: AQHWLsgqnBPhO5w6N0yNNHBtsaHVYqjFd0IAgAAAqAc= Date: Tue, 2 Jun 2020 14:35:53 +0000 Message-ID: References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=isoc.org; x-originating-ip: [108.28.51.147] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f753677c-94ec-4845-eb49-08d807024131 x-ms-traffictypediagnostic: BY5PR06MB6561: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0422860ED4 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5JbE48uUR2ML9gc/bdvtJCRQ9xNqpxczyU8czVj+gXi5oiw4zpLqsOhaAAuoHO3wLp7E3GgLDn+/J1hE+uqQ3vG3NJBAiJZJunjlunIEA3dGKlxWYvuRN5RgeHBM9VOkFr9E1k01M+h5mZ9tSxO4m0XdsCQa7au4aUXAUo4tY2IhAWpXmEtUaKOp8La6Rw7Dh5JutaeCJye466Qqpq+iyBXgZKSVK5YvE23o0OgKUnhaqpLepfvd6n0IV2WzeXur3CUGHMFyzGXWoJT/C7agpG2Z4ZQPjiystT7yQ2Fk1NXNMooWjts6Ijwz2R7kWZHzhYZFGBLeR1R/99R2cdavoXqfB303ZP/2xN8vUCYoQENKBq7ANON+GxSWrwcAS298A5FgFpc0+W7FAkwHVqRICA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR06MB6451.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(366004)(396003)(376002)(346002)(39840400004)(136003)(8936002)(8676002)(316002)(6506007)(53546011)(7696005)(71200400001)(66446008)(4326008)(64756008)(52536014)(5660300002)(55016002)(86362001)(66946007)(66476007)(966005)(66556008)(76116006)(91956017)(33656002)(9686003)(2906002)(186003)(26005)(478600001)(19627405001)(110136005)(166002)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: aqJnKtzZ367T5BSYDLnEOdHgHx6bGi3t2hJKQSJzJRkTqr+/oJsRKl+R5273733dOvvbpyGMyibN0Pg3LxG5HYef37iJj/Q3ZRJBovZgI2ACZCtSd3UuEpEj/CPRiHPiPWzEOPduR1fH+cQomcQBeM9LLWk9Q/sVR9pGYWbGOqJJa6paKfL6lM0CXYpK0PtqugGzfpLAPyqXghCzXsiFjLhntYnwywULhenQK/96URxPoX8fNHQ3BU9SYCv+S7fV0QA3AVAiuOfIvcW4+hiMbR52y/9k9OgsuiVs5xhnlRrMuMJ0022hSCOJgZcIKShrN0qy3WkDJWG//NldKCOp4sudEG3LC638F0bIK7MEvyFzaDCHMlbjib68AAnGH5cB1I4qJ9rcWYk7SHSfEMfnKPXn9v2/umw3WZETZgwag/8A9F47YcryKf3lvg8SUVstfaLz9G8H4/Dtrgz9YFY52n/ZuMDBGBpWcC0Ne60U70YJLhbwX7lqXjHUopNA0hHw x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR06MB6451462E103F42C5F164AFDFB18B0BY5PR06MB6451namp_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: f753677c-94ec-4845-eb49-08d807024131 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jun 2020 14:35:53.7049 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vtfA1SkHdG2HeGO41KRlMFnaP45C4kya/c+f+Jb09o2LUjefjDc6+O9XeHaa28av X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR06MB6561 Archived-At: Subject: Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques" X-BeenThere: pearg@irtf.org 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, 02 Jun 2020 14:35:59 -0000 --_000_BY5PR06MB6451462E103F42C5F164AFDFB18B0BY5PR06MB6451namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you, Chelsea! I have a ton of $dayjob responsibilities this week that make it difficult t= o respond quickly, so I think what I'll do is absorb this and other reviews= and peel off github issues (discussion which I'll replicate or reference h= ere) to deal with these later this week (and I'll pow-wow with chairs, e.g,= Chris). Very thankful for the many reviews and please don't let my inability to res= pond quickly stifle any discussion! best, Joe ________________________________ From: Pearg on behalf of Chelsea Komlo Sent: Tuesday, June 2, 2020 10:30 To: Christopher Wood Cc: pearg@irtf.org Subject: Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Ce= nsorship Techniques" Hi Chris, I have a couple meta points and a few specific points. Overall, my strongest recommendation is threefold. First, I recommend impro= ving the document organization to clearly differentiate between a specific = censorship technique and corresponding methods to circumvent that technique= . Second, I suggest strengthening the review of current circumvention techn= iques and their effectiveness to give an improved view of the landscape and= to prevent re-inventing the wheel, as the intended audience is protocol de= signers.. Third, I recommend differentiating between the capabilities of ma= ture censors like China, and weaker censors such as those with only off-the= -shelf tools. Here is my discussion of these points in more detail. =3D=3D=3D Meta Points =3D=3D=3D - While I understand this draft to be purely informational, understanding c= ensorship today is incomplete without understanding existing censorship cir= cumvention techniques, and how effective these techniques are.. Critically,= some of the most effective and safe censorship techniques are "hanging by = a thread" in terms of how much longer they will be available (such as domai= n fronting), so understanding these weak areas is important to understandin= g the sustainability of the current circumvention landscape. I suggest addi= ng at minimum a discussion of "Where are we today" regarding circumvention. - To go along with the above point, providing a better review of existing = censorship circumvention techniques will help encourage building on existin= g work, as opposed to re-inventing the wheel from first principles. While p= erhaps this review should be a follow-up document, I strongly encourage pro= viding such a review, especially since the intended audience is protocol de= signs. - Within the draft itself, the discussion of censorship techniques is often= interwoven with circumvention methods. I suggest separating these concepts= out within each section. Instead of a "Tradeoffs" section, perhaps have se= ctions pertaining to "Cost to Implement to Censor", and "Techniques to Circ= umvent", for improved clarity. - One important point is that while China is an extremely powerful censor, = they are often in a class of their own. I encourage including a discussion = of something like "censor maturity" or the technical resources required to = implement different techniques. There is a bit of this discussion, but it c= an be better standardized and applied to each technique. For example, IP bl= acklisting is trivial and does not require significant infrastructure (and = many censors do this), but performing active probing to fingerprint protoco= ls and block them on the fly requires much more infrastructure and planning= (and is essentially only China, as I understand). =3D=3D=3D Specific Points =3D=3D=3D - DPI (deep packet inspection) is technically any kind of packet analysis b= eyond IP address and port number- this concept can be better clarified. Fur= ther, this technique is not specific to - Clearly highlighting techniques that are thwarted by the use of TLS versu= s techniques which can be performed even in spite of TLS usage would also l= ikely be helpful to readers. Thanks, Chelsea On Wed, May 20, 2020 at 11:00 AM Christopher Wood > wrote: This is the research group last call for the "A Survey of Worldwide Censors= hip Techniques" (draft-irtf-pearg-censorship) draft available here: https://datatracker.ietf.org/doc/draft-irtf-pearg-censorship/ Please review the document and send your comments to the list by June 5, 20= 20. Feedback may also be sent to the GitHub repository located here: https://github.com/IRTF-PEARG/rfc-censorship-tech Thanks, Chris, on behalf of the chairs -- Pearg mailing list Pearg@irtf.org https://www.irtf.org/mailman/listinfo/pearg -- Chelsea H. Komlo --_000_BY5PR06MB6451462E103F42C5F164AFDFB18B0BY5PR06MB6451namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thank you, Chelsea!

I have a ton of $dayjob responsibilities this week that make it difficult t= o respond quickly, so I think what I'll do is absorb this and other reviews= and peel off github issues (discussion which I'll replicate or reference h= ere) to deal with these later this week (and I'll pow-wow with chairs, e.g, Chris).

Very thankful for the many reviews and please don't let my inability to res= pond quickly stifle any discussion! best, Joe
From: Pearg <pearg-bounc= es@irtf.org> on behalf of Chelsea Komlo <chelsea.komlo@gmail.com><= br> Sent: Tuesday, June 2, 2020 10:30
To: Christopher Wood <caw@heapingbits.net>
Cc: pearg@irtf.org <pearg@irtf.org>
Subject: Re: [Pearg] Research Group Last Call for "A Survey of = Worldwide Censorship Techniques"
 
Hi Chris,

I have a couple meta points and a few specific points.

Overall, my strongest recommendation is threefold. First, I recommend = improving the document organization to clearly differentiate between a spec= ific censorship technique and corresponding methods to circumvent that tech= nique. Second, I suggest strengthening the review of current circumvention techniques and their effectiveness to = give an improved view of the landscape and to prevent re-inventing the whee= l, as the intended audience is protocol designers.. Third, I recommend diff= erentiating between the capabilities of mature censors like China, and weaker censors such as those with only o= ff-the-shelf tools. 

Here is my discussion of these points in more detail. 

=3D=3D=3D Meta Points =3D=3D=3D
- While I understand this draft to be purely informational, understand= ing censorship today is incomplete without understanding existing censorshi= p circumvention techniques, and how effective these techniques are.. Critic= ally, some of the most effective and safe censorship techniques are "hanging by a thread" in term= s of how much longer they will be available (such as domain fronting), so u= nderstanding these weak areas is important to understanding the sustainabil= ity of the current circumvention landscape. I suggest adding at minimum a discussion of "Where are we today"= regarding circumvention.
- To go along with the above point,  providing a better review of= existing censorship circumvention techniques will help encourage building = on existing work, as opposed to re-inventing the wheel from first principle= s. While perhaps this review should be a follow-up document, I strongly encourage providing such a review, especi= ally since the intended audience is protocol designs. 
- Within the draft itself, the discussion of censorship techniques is = often interwoven with circumvention methods. I suggest separating these con= cepts out within each section. Instead of a "Tradeoffs" section, = perhaps have sections pertaining to "Cost to Implement to Censor", and "Techniques to Circumvent", fo= r improved clarity. 
- One important point is that while China is an extremely powerful cen= sor, they are often in a class of their own. I encourage including a discus= sion of something like "censor maturity" or the technical resourc= es required to implement different techniques. There is a bit of this discussion, but it can be better standardized and a= pplied to each technique. For example, IP blacklisting is trivial and does = not require significant infrastructure (and many censors do this), but perf= orming active probing to fingerprint protocols and block them on the fly requires much more infrastructure and = planning (and is essentially only China, as I understand). 

=3D=3D=3D Specific Points =3D=3D=3D
- DPI (deep packet inspection) is technically any kind of packet analy= sis beyond IP address and port number- this concept can be better clarified= . Further, this technique is not specific to   
- Clearly highlighting techniques that are thwarted by the use of= TLS versus techniques which can be performed even in spite of TLS usage wo= uld also likely be helpful to readers. 

Thanks,
Chelsea

On Wed, May 20, 2020 at 11:00 AM Ch= ristopher Wood <caw@heapingbits.n= et> wrote:
This is the research group last call for the "A Survey of Worldwide Ce= nsorship Techniques" (draft-irtf-pearg-censorship) draft available her= e:

   https://datatracker.ietf.o= rg/doc/draft-irtf-pearg-censorship/

Please review the document and send your comments to the list by June 5, 20= 20. Feedback may also be sent to the GitHub repository located here:

   https://github.com/IRTF-PEARG/rfc-cens= orship-tech

Thanks,
Chris, on behalf of the chairs

--
Pearg mailing list
Pearg@irtf.org
https://www.irtf.org/mailman/listinfo/pearg


--
Chelsea H. Komlo
--_000_BY5PR06MB6451462E103F42C5F164AFDFB18B0BY5PR06MB6451namp_-- From nobody Tue Jun 2 08:00:01 2020 Return-Path: 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 BCC243A08CD for ; Tue, 2 Jun 2020 07:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 75QCZQsWZy57 for ; Tue, 2 Jun 2020 07:59:57 -0700 (PDT) Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0ED53A08C3 for ; Tue, 2 Jun 2020 07:59:57 -0700 (PDT) Received: by mail-qt1-f174.google.com with SMTP id j32so10825041qte.10 for ; Tue, 02 Jun 2020 07:59:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zvJC37+8pnyk6NiuEuRjyQoQhDzehIBkqC9OkxoQnYM=; b=BcdfuE5+2wou/tyDY+W/1k5brEXHy/DkWM5srVqyrq9tmc05/At7yVYudoWJpPdJkh NZrgc6BkEogDKr7+kADbUfzimcVpgbIEPfLU075nJQOUsXmIZyLK1uM+VR5b86mnsGlW z3x3DXcf8Q/UNm5sjAUyYEvzBn7xgxLKR3hhzW17CiCnrtisuJneAwAWSe05T3/zFDDB oSR1CPUIchdGsxc9VrSiJmFJ4h+qJf3VJxuTRqgvarKJAnkACEWtnnlNaYtkg2FcS+LW Jj4NZLeQgicQqgxbXFMdj38L0yQa3ozZXo/ofEhPKQXp+4pPfFnYbWpw6JRcaCZ2TJOc G+yw== X-Gm-Message-State: AOAM531xrBQ/oGvdGyeHAIyW/1/LQ4/m1jI0PvA3kSh8M1rrA1gWVbW/ FcN4evw+k/caAh3kEyyxKKL8mk9Dkc4DsrhY8jA= X-Google-Smtp-Source: ABdhPJxJLxrcBF1TnXNu28tVIZ5ugj6PvmY3Ga+5TpHnq+DUZrTiO4e6FmNKiKg/AawEYD5HeTnfxwdOOQBYsoDzrM4= X-Received: by 2002:ac8:7252:: with SMTP id l18mr12169844qtp.71.1591109996789; Tue, 02 Jun 2020 07:59:56 -0700 (PDT) MIME-Version: 1.0 References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> In-Reply-To: From: David Oliver Date: Tue, 2 Jun 2020 10:59:45 -0400 Message-ID: To: Chelsea Komlo Cc: Christopher Wood , pearg@irtf.org Content-Type: multipart/alternative; boundary="00000000000028456205a71b2ad0" Archived-At: Subject: Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques" X-BeenThere: pearg@irtf.org 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, 02 Jun 2020 15:00:00 -0000 --00000000000028456205a71b2ad0 Content-Type: text/plain; charset="UTF-8" Chelsea, thanks for this. > First, I recommend improving the document organization to clearly differentiate > between a specific censorship technique and corresponding methods to circumvent that technique. I'm still not understanding why - in a document defined to talk about censorship techniques - we're talking about circumvention methods. I believe it's particularly important to understand because, at least for the techniques I'm familiar with, these methods work "above the stack", not "in the stack" because we implementors can't have impact on "the stack" itself. IETF addresses "the stack" so, in theory at least, IETF could use the understanding of censorship techniques to implement solutions there. Why would we (implementors) be engaging with IETF if we do not seek new "in the stack" methods of preventing censorship? Thanks for any clarification that can be provided. David Oliver David M. Oliver | david@g uardianproject.info | http://g uardianproject.info | @davidmoliver | +1 970 368 2366 On Tue, Jun 2, 2020 at 10:31 AM Chelsea Komlo wrote: > Hi Chris, > > I have a couple meta points and a few specific points. > > Overall, my strongest recommendation is threefold. First, I recommend > improving the document organization to clearly differentiate between a > specific censorship technique and corresponding methods to circumvent that > technique. Second, I suggest strengthening the review of current > circumvention techniques and their effectiveness to give an improved view > of the landscape and to prevent re-inventing the wheel, as the intended > audience is protocol designers.. Third, I recommend differentiating between > the capabilities of mature censors like China, and weaker censors such as > those with only off-the-shelf tools. > > Here is my discussion of these points in more detail. > > === Meta Points === > - While I understand this draft to be purely informational, understanding > censorship today is incomplete without understanding existing censorship > circumvention techniques, and how effective these techniques are.. > Critically, some of the most effective and safe censorship techniques are > "hanging by a thread" in terms of how much longer they will be available > (such as domain fronting), so understanding these weak areas is important > to understanding the sustainability of the current circumvention landscape. > I suggest adding at minimum a discussion of "Where are we today" regarding > circumvention. > - To go along with the above point, providing a better review of existing > censorship circumvention techniques will help encourage building on > existing work, as opposed to re-inventing the wheel from first principles. > While perhaps this review should be a follow-up document, I strongly > encourage providing such a review, especially since the intended audience > is protocol designs. > - Within the draft itself, the discussion of censorship techniques is > often interwoven with circumvention methods. I suggest separating these > concepts out within each section. Instead of a "Tradeoffs" section, perhaps > have sections pertaining to "Cost to Implement to Censor", and "Techniques > to Circumvent", for improved clarity. > - One important point is that while China is an extremely powerful censor, > they are often in a class of their own. I encourage including a discussion > of something like "censor maturity" or the technical resources required to > implement different techniques. There is a bit of this discussion, but it > can be better standardized and applied to each technique. For example, IP > blacklisting is trivial and does not require significant infrastructure > (and many censors do this), but performing active probing to fingerprint > protocols and block them on the fly requires much more infrastructure and > planning (and is essentially only China, as I understand). > > === Specific Points === > - DPI (deep packet inspection) is technically any kind of packet analysis > beyond IP address and port number- this concept can be better clarified. > Further, this technique is not specific to > - Clearly highlighting techniques that are thwarted by the use of TLS > versus techniques which can be performed even in spite of TLS usage would > also likely be helpful to readers. > > Thanks, > Chelsea > > On Wed, May 20, 2020 at 11:00 AM Christopher Wood > wrote: > >> This is the research group last call for the "A Survey of Worldwide >> Censorship Techniques" (draft-irtf-pearg-censorship) draft available here: >> >> https://datatracker.ietf.org/doc/draft-irtf-pearg-censorship/ >> >> Please review the document and send your comments to the list by June 5, >> 2020. Feedback may also be sent to the GitHub repository located here: >> >> https://github.com/IRTF-PEARG/rfc-censorship-tech >> >> Thanks, >> Chris, on behalf of the chairs >> >> -- >> Pearg mailing list >> Pearg@irtf.org >> https://www.irtf.org/mailman/listinfo/pearg >> > > > -- > Chelsea H. Komlo > -- > Pearg mailing list > Pearg@irtf.org > https://www.irtf.org/mailman/listinfo/pearg > --00000000000028456205a71b2ad0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Chelsea, thanks for this. =C2=A0

=
>=C2=A0First, I recommend improving the document organization= to clearly differentiate
> =C2=A0between a specific censorshi= p technique and corresponding methods to circumvent that technique.

I'm still not understanding why - in a document defin= ed to talk about censorship techniques - we're talking about circumvent= ion methods. I believe it's particularly important to understand=C2=A0b= ecause, at least for the techniques I'm familiar with, these methods wo= rk "above the stack", not "in the stack" because we imp= lementors=C2=A0can't have impact on "the stack" itself.=C2=A0= IETF addresses "the stack" so, in theory at least, IETF could us= e the understanding of censorship techniques to implement solutions there.= =C2=A0 Why would we (implementors) be engaging with IETF if we do not seek = new "in the stack" methods of preventing censorship?
Thanks for any clarification that can be provided.
<= br>
David Oliver
David M. Oliver |=C2=A0david@guardianproject.info=C2=A0|=C2=A0http://guardianproject.info=C2=A0| @davidmoliver |=C2=A0+1 = 970 368 2366


On Tue, Jun 2, 2020 at 10:31 AM Che= lsea Komlo <chelsea.komlo@gma= il.com> wrote:
Hi Chris,

I have a couple meta points and a few= specific points.

Overall, my strongest recommenda= tion is threefold. First, I recommend improving the document organization t= o clearly differentiate between a specific censorship technique and corresp= onding methods to circumvent that technique. Second, I suggest strengthenin= g the review of current circumvention techniques and their effectiveness to= give an improved view of the landscape and to prevent re-inventing the whe= el, as the intended audience is protocol designers.. Third, I recommend dif= ferentiating between the capabilities of mature censors like China, and wea= ker censors such as those with only off-the-shelf tools.=C2=A0
Here is my discussion of these points in more detail.=C2=A0

=3D=3D=3D Meta Points =3D=3D=3D
- While I = understand this draft to be purely informational, understanding censorship = today is incomplete without understanding existing censorship circumvention= techniques, and how effective these techniques are.. Critically, some of t= he most effective and safe censorship techniques are "hanging by a thr= ead" in terms of how much longer they will be available (such as domai= n fronting), so understanding these weak areas is important to understandin= g the sustainability of the current circumvention landscape. I suggest addi= ng at minimum a discussion of "Where are we today" regarding circ= umvention.
- To go along with the above point,=C2=A0 providing a = better review of existing censorship circumvention techniques will help enc= ourage building on existing work, as opposed to re-inventing the wheel from= first principles. While perhaps this review should be a follow-up document= , I strongly encourage providing such a review, especially since the intend= ed audience is protocol designs.=C2=A0
- Within the draft itself,= the discussion of censorship techniques is often interwoven with circumven= tion methods. I suggest separating these concepts out within each section. = Instead of a "Tradeoffs" section, perhaps have sections pertainin= g to "Cost to Implement to Censor", and "Techniques to Circu= mvent", for improved clarity.=C2=A0
- One important point is= that while China is an extremely powerful censor, they are often in a clas= s of their own. I encourage including a discussion of something like "= censor maturity" or the technical resources required to implement diff= erent techniques. There is a bit of this discussion, but it can be better s= tandardized and applied to each technique. For example, IP blacklisting is = trivial and does not require significant infrastructure (and many censors d= o this), but performing active probing to fingerprint protocols and block t= hem on the fly requires much more infrastructure and planning (and is essen= tially only China, as I understand).=C2=A0

=3D=3D= =3D Specific Points =3D=3D=3D
- DPI (deep packet inspection) is t= echnically any kind of packet analysis beyond IP address and port number- t= his concept can be better clarified. Further, this technique is not specifi= c to=C2=A0 =C2=A0
- Clearly=C2=A0highlighting techniques that are= thwarted by the use of TLS versus techniques which can be performed even i= n spite of TLS usage would also likely be helpful to readers.=C2=A0

Thanks,
Chelsea

On Wed, May 20, 2020 at 11= :00 AM Christopher Wood <caw@heapingbits.net> wrote:
= This is the research group last call for the "A Survey of Worldwide Ce= nsorship Techniques" (draft-irtf-pearg-censorship) draft available her= e:

=C2=A0 =C2=A0https://datatracker.ietf.o= rg/doc/draft-irtf-pearg-censorship/

Please review the document and send your comments to the list by June 5, 20= 20. Feedback may also be sent to the GitHub repository located here:

=C2=A0 =C2=A0https://github.com/IRTF-PEARG/rfc-cens= orship-tech

Thanks,
Chris, on behalf of the chairs

--
Pearg mailing list
Pearg@irtf.org
https://www.irtf.org/mailman/listinfo/pearg


--
Chelsea H. Komlo
--
Pearg mailing list
Pearg@irtf.org
https://www.irtf.org/mailman/listinfo/pearg
--00000000000028456205a71b2ad0-- From nobody Tue Jun 2 10:15:13 2020 Return-Path: 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 623003A0CB2 for ; Tue, 2 Jun 2020 10:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=gmail.com 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 99RIP-8Pzjqw for ; Tue, 2 Jun 2020 10:15:11 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDA903A0CAF for ; Tue, 2 Jun 2020 10:15:10 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id k26so3915656wmi.4 for ; Tue, 02 Jun 2020 10:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iFz0kLaQv2z61T13dCqwZoNZdYhK1d1Ywq0nupsCoXk=; b=Om12rp86dIGUukDtpjFKngPXz4JKJ5mVain3Hpt7Vdr8AujUkDOzGRDlSZoPnPCMOm M8L+OecV5ZVeVByLRFpOv+bRWEMjJZaQgJ+nLr+xN0bDEqv/lU42GCjDYmd+1717WWi7 5O+jA+m7V3XO1PRslsHNpu9+fofHmhKYsOjL3QaqZor2fokae/AnAjzT4r067vAtNND8 NCemwN5DhPtoPeSxI/meu/Q6+Zx1W20S/1UVC2FPpnBljrhzkv20ESOPXA4Sz6yQ8kWJ mIq0Iys9DHfoJ0CVRn2hih1eHt0fH9LKce8Ozpge1jRqZ/JoOXMy2yMKmegLsayT2fRh QvOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iFz0kLaQv2z61T13dCqwZoNZdYhK1d1Ywq0nupsCoXk=; b=QuTI0UoREH/tOKsqT6oFx7tojB33QlMWk/vX5A5AFpyk+KlfqIrm7k/tMU4SpyMk4r 2pqvBOUKxxPdqLHQ6LAw/UpXquKyRMp8rt/WqDIZsT0BwF3R4mcQo6z3GCnsMziNZ+3k lrf8kk/2pOVGGmfL1yakgk/wjCS8+HcbpNyMIika5kY0aBvIeLlJ6gA8ExOE/DJ1Ziuy f9TT8JAt52oVre2eI2oHxajb+bKqckV54y3Ja/Lo9qEQmiwKZ21sN3/8iT58KboQ9KcX d8N7fL/JVNfiKm4Tn6IZkwscyiuEo2IopECa3uEwttq8x/DAClGEbcZIeHfZy00LcDz2 aV0w== X-Gm-Message-State: AOAM5325meNmHXKafRb927Vc5lEfwxIKfv5OMoPz9knfkmfbCrxIcmGK EmnX/tatRW0ucuIgVLIX3Jag0ENVbGUOqYsqZvxt2g== X-Google-Smtp-Source: ABdhPJwMBhmAmKm1sFf74Rkb/IX7Uuau1g4vLrdjDxEKmYj3UA/rGl0quFaMbpXBbs00FVrIOHUdrt8oCFCYHyoT5ws= X-Received: by 2002:a1c:7fc5:: with SMTP id a188mr5317771wmd.59.1591118107785; Tue, 02 Jun 2020 10:15:07 -0700 (PDT) MIME-Version: 1.0 References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> In-Reply-To: From: Chelsea Komlo Date: Tue, 2 Jun 2020 11:14:55 -0600 Message-ID: To: David Oliver Cc: Christopher Wood , pearg@irtf.org Content-Type: multipart/alternative; boundary="0000000000009c3e6005a71d0d8c" Archived-At: Subject: Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques" X-BeenThere: pearg@irtf.org 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, 02 Jun 2020 17:15:12 -0000 --0000000000009c3e6005a71d0d8c Content-Type: text/plain; charset="UTF-8" Hi David, On Tue, Jun 2, 2020 at 8:59 AM David Oliver wrote: > Chelsea, thanks for this. > > > First, I recommend improving the document organization to clearly > differentiate > > between a specific censorship technique and corresponding methods to > circumvent that technique. > > I'm still not understanding why - in a document defined to talk about > censorship techniques - we're talking about circumvention methods. I > believe it's particularly important to understand because, at least for the > techniques I'm familiar with, these methods work "above the stack", not "in > the stack" because we implementors can't have impact on "the stack" > itself. IETF addresses "the stack" so, in theory at least, IETF could use > the understanding of censorship techniques to implement solutions there. > Why would we (implementors) be engaging with IETF if we do not seek new "in > the stack" methods of preventing censorship? > > While yes, IETF can certainly address censorship techniques "down the stack", it is still critical to understand how existing circumvention techniques have or have not been successful in order to design for the future. There is a learning curve to understanding how to design for censorship circumvention and I would hate to see all of the same mistakes made that are already known to practitioners building circumvention tools higher up in the stack. So in short, let's avoid re-learning lessons that have already been learned in this space. Chelsea --0000000000009c3e6005a71d0d8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi David,

On Tue, Jun 2, 2020 at 8:59 AM D= avid Oliver <david@guardia= nproject.info> wrote:
Chelsea, thanks for this. = =C2=A0

>=C2=A0First, I recommend improving the docume= nt organization to clearly differentiate
> =C2=A0between a spe= cific censorship technique and corresponding methods to circumvent that tec= hnique.

I'm still not understanding why - in a= document defined to talk about censorship techniques - we're talking a= bout circumvention methods. I believe it's particularly important to un= derstand=C2=A0because, at least for the techniques I'm familiar with, t= hese methods work "above the stack", not "in the stack"= because we implementors=C2=A0can't have impact on "the stack"= ; itself.=C2=A0 IETF addresses "the stack" so, in theory at least= , IETF could use the understanding of censorship techniques to implement so= lutions there.=C2=A0 Why would we (implementors) be engaging with IETF if w= e do not seek new "in the stack" methods of preventing censorship= ?


While ye= s, IETF can certainly address censorship techniques "down the stack&qu= ot;, it is still critical to understand how existing circumvention techniqu= es have or have not been successful in order to design for the future. Ther= e is a learning curve to understanding how to design for censorship circumv= ention and I would hate to see all of the same mistakes made that=C2=A0are = already known to practitioners building circumvention tools higher up in th= e stack.=C2=A0

So in short, let's avoid re-lea= rning lessons that have already been learned in this space.=C2=A0

Chelsea
--0000000000009c3e6005a71d0d8c-- From nobody Wed Jun 3 03:59:23 2020 Return-Path: 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 197FF3A0FDE for ; Wed, 3 Jun 2020 03:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 jeR0E6ceujML for ; Wed, 3 Jun 2020 03:59:20 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2673A3A0FDD for ; Wed, 3 Jun 2020 03:59:19 -0700 (PDT) X-Originating-IP: 212.76.239.56 Received: from [192.168.0.233] (cable-212.76.239.56.coditel.net [212.76.239.56]) (Authenticated sender: amelia@andersdotter.cc) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id B7D46E0009 for ; Wed, 3 Jun 2020 10:59:15 +0000 (UTC) To: pearg@irtf.org References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> Reply-To: amelia.ietf@andersdotter.cc From: Amelia Andersdotter Message-ID: <07e1c625-9b0b-47ab-5d48-ac35b00899d2@andersdotter.cc> Date: Wed, 3 Jun 2020 12:57:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques" X-BeenThere: pearg@irtf.org 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: Wed, 03 Jun 2020 10:59:22 -0000 On 2020-05-29 19:28, Eric Rescorla wrote: > Document: draft-irtf-pearg-censorship-03.txt > > S 2. >     We describe three elements of Internet censorship: prescription, >     identification, and interference.  The document contains three major >     sections, each corresponding to one of these elements.  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 > > I'm not finding this distinction super clear. It seems to me like > deciding to block www.sex.example and "impairing...traffic to > www.sex.example" are pretty similar. I felt like picking up on this: the difference between blocking and impairing is that blocking would be definitive (content is rendered inaccessible to end-node), while impairment would just mean, for instance, downgraded in quality (content is made to run more slow or without encryption, for instance). I do feel there is a point to keeping that distinction. It serves the purpose of highlighting that censorship may take more subtle forms than outright bans on sensitive content. best regards, Amelia From nobody Wed Jun 3 05:53:40 2020 Return-Path: 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 DE6EE3A10D8 for ; Wed, 3 Jun 2020 05:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.com 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 H7W6VXqdaSsB for ; Wed, 3 Jun 2020 05:53:29 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F8DB3A10E6 for ; Wed, 3 Jun 2020 05:53:29 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id y11so922821ljm.9 for ; Wed, 03 Jun 2020 05:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XM9SFy4xM+f6tzvmOHTnc6A8ySVFqFqb0RTySDowNE0=; b=2C34JX08ewh0lehO4HDPWtSnjbvnPkjG9KH3D1gWfWy8A3ffm4iES3Jge3ndX8c/fY ejwwPUXgrLNOps9hyqQ200rvAhUMgN3vxqt3wbxH+o/Hhc4hD8CIRkKL4aZfGuAzua/V fwzcpxMGh/wJKu461CPOEUdW8u/Xii/3EwaJqPpD2Xn58sMdXivK9moqvn98sT0F7wg/ /AilfgtuImTXMVJw70eVFjGwckZDaQ3KufA0t59CEUpSa9ODSmkY3DPS5S30mgC3OIwb Ta6PJ9yF38ADmL0Z7Q4UWfuqxfIrHigRdBIMzNi70K1kdD7Mt1i4i12VH8P0MlzTCxsv z0zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XM9SFy4xM+f6tzvmOHTnc6A8ySVFqFqb0RTySDowNE0=; b=KMI2ZZvs/6hirP44oP6Sn4Vz6fMKTL0UIttnLBsSKx7cwlVW9Ifr1Dw6CK8t3t6cIN EiOy3NPz12p4Rm4L79494jynDwDFvQoAvgmL/LgxoJXPxXVR7JvJANeo7B5EgQj894zE prZWSqOlg8ZHGbwP4y71QdztnkHmTFcsjliDb8sqn8X/mWo8IQuLZIPtpl8wLuBZxwTH /GQMECe2qKzwW3bkoQTX+g1ZmmzaEStzF+tL5M6IJqM2PibYKjUPnnEIzLFJ7mNUBj6J l+Eu8bfWPd12xNtblGfc3As5AI7Fc4yrm12GIlcafRuwI80DnyB9XpRFyAJ0Lxc4kzgr w0/Q== X-Gm-Message-State: AOAM5328FrCp9JHd0XsLKx1juig/D16Nh0+hv6sl0Tzfw+a95diyTd3E aryqRl+6EPQU+GZ21+FKi3zHLnG4P4WDCsF5lAlV2zNf7U8= X-Google-Smtp-Source: ABdhPJzQrsqJBc5wRXYALljlzhhmbdV0sHTcBj9HiEAKLmcFpZzZ/WmEYQzQ5gOZiUQUOg1dI/kTBWmb+/2gDEu/RsQ= X-Received: by 2002:a2e:3609:: with SMTP id d9mr1874329lja.409.1591188807248; Wed, 03 Jun 2020 05:53:27 -0700 (PDT) MIME-Version: 1.0 References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <07e1c625-9b0b-47ab-5d48-ac35b00899d2@andersdotter.cc> In-Reply-To: <07e1c625-9b0b-47ab-5d48-ac35b00899d2@andersdotter.cc> From: Eric Rescorla Date: Wed, 3 Jun 2020 05:52:50 -0700 Message-ID: To: amelia.ietf@andersdotter.cc Cc: pearg@irtf.org Content-Type: multipart/alternative; boundary="000000000000a0aaa005a72d8321" Archived-At: Subject: Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques" X-BeenThere: pearg@irtf.org 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: Wed, 03 Jun 2020 12:53:38 -0000 --000000000000a0aaa005a72d8321 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 3, 2020 at 3:59 AM Amelia Andersdotter wrote: > On 2020-05-29 19:28, Eric Rescorla wrote: > > Document: draft-irtf-pearg-censorship-03.txt > > > > S 2. > > We describe three elements of Internet censorship: prescription, > > identification, and interference. The document contains three major > > sections, each corresponding to one of these elements. 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 > > > > I'm not finding this distinction super clear. It seems to me like > > deciding to block www.sex.example and "impairing...traffic to > > www.sex.example" are pretty similar. > > I felt like picking up on this: the difference between blocking and > impairing is that blocking would be definitive (content is rendered > inaccessible to end-node), while impairment would just mean, for > instance, downgraded in quality (content is made to run more slow or > without encryption, for instance). I do feel there is a point to keeping > that distinction. > This was actually bad quoting on my part because the text actually has "i.e., blocking or impairing...". My point is that "deciding to" and "doing" seem pretty similar... It serves the purpose of highlighting that censorship may take more > subtle forms than outright bans on sensitive content. > I definitely agree. best regards, > > Amelia > > -- > Pearg mailing list > Pearg@irtf.org > https://www.irtf.org/mailman/listinfo/pearg > --000000000000a0aaa005a72d8321 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jun 3, 2020 at 3:59 AM Amelia= Andersdotter <amelia.ietf@andersdotter.cc> wrote:
On 2020-05-29 19:28, Eric Rescorla= wrote:
> Document: draft-irtf-pearg-censorship-03.txt
>
> S 2.
> =C2=A0 =C2=A0 We describe three elements of Internet censorship: presc= ription,
> =C2=A0 =C2=A0 identification, and interference.=C2=A0 The document con= tains three major
> =C2=A0 =C2=A0 sections, each corresponding to one of these elements.= =C2=A0 Prescription
> =C2=A0 =C2=A0 is the process by which censors determine what types of = material they
> =C2=A0 =C2=A0 should block, i.e., deciding to block a list of pornogra= phic
> =C2=A0 =C2=A0 websites.=C2=A0 Identification is the process by which c= ensors classify
> =C2=A0 =C2=A0 specific traffic to be blocked or impaired, i.e., blocki= ng or
> =C2=A0 =C2=A0 impairing all webpages containing "sex" in the= title or traffic to
> =C2=A0 =C2=A0 www.sex.example.=C2=A0 Interference is the process by wh= ich censors
>
> I'm not finding this distinction super clear. It seems to me like<= br> > deciding to block www.sex.example and "impairing...traffic to
> www.sex.example" are pretty similar.

I felt like picking up on this: the difference between blocking and
impairing is that blocking would be definitive (content is rendered
inaccessible to end-node), while impairment would just mean, for
instance, downgraded in quality (content is made to run more slow or
without encryption, for instance). I do feel there is a point to keeping that distinction.

This was actually bad= quoting on my part because the text actually
has "i.e., blo= cking or impairing...". My point is that "deciding to"
=
and "doing" seem pretty similar...

<= div>
It serves the purpose of highlighting that censorship may take more
subtle forms than outright bans on sensitive content.
=
I definitely agree.

best regards,

Amelia

--
Pearg mailing list
Pearg@irtf.org
https://www.irtf.org/mailman/listinfo/pearg
--000000000000a0aaa005a72d8321-- From nobody Wed Jun 3 09:16:46 2020 Return-Path: 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 927823A0788 for ; Wed, 3 Jun 2020 09:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=R51yJMtQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=b1bbxAeQ 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 He7VIWhL85qQ for ; Wed, 3 Jun 2020 09:16:43 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276503A07C7 for ; Wed, 3 Jun 2020 09:15:47 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 802DC5C0143; Wed, 3 Jun 2020 12:15:46 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Wed, 03 Jun 2020 12:15:46 -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 :cc:subject:content-type; s=fm1; bh=QEhGKJTM+MFrbJ5JvLMv93j5r78T 6O3UoOK8XB0mUE8=; b=R51yJMtQD4FMh363SAnkNhUcZ7km30WM6DbEaC1el/YR UbRCUFqHelfOnmk7dvak3br+hHMKASzundkRoyTgdIIDqW9F05fBd4M3RiHTp7MM mUxemckXFQXL0+JNeqjPRQO5yqP0OgL0Bm+3F3j0kfsnF9NkSBXeZHd1AoU60NEO BEXXYYbRtXWMc4VT+C5N9AgMp3XXKGz/sfWSKyeFYXRMk4+LMxYHquCfOOIgXdP/ +R+ODZTMx+SmGqXSjR/erfLERC7IZsPPmny5ZjTS4mrB+cAjLO4gIqPkxecW2YDp VbuOjFOVCnF8MT0raeUUDGJHsofdZosxqJCnzhgfwA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=QEhGKJ TM+MFrbJ5JvLMv93j5r78T6O3UoOK8XB0mUE8=; b=b1bbxAeQAiSUv9b+BYVP+y sHMYceG4eeqmgQmbq3aXLLv+GlVPf8qXW2LeBbJ33xbnWFCFowbnw7JpILlKT3Cs EdqBRGf2oLbgufw3RMnPk+h0EDiT9I0KZSnYP2c00Le1cQkr2Wjstedz5W7HpSbK FJqETvQYl2rqqdetMmKohPkIyXzbsYbC+IKhHiyw3lB/gKQK75L6WqC193Eu/fYO kklITulUTYH6ABIK8nDll4ZeTfVknID+3iZEJOoemf36INWkRG0YVgWl4Hs4Y9wl 9V26JIjVVcUcPeu/YFF8/H9E4IELJShPpZBDytykkMj6rIyjWbdq7XEqRtKhOG5g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudefledgjeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdevhhhr ihhsthhophhhvghrucghohhougdfuceotggrfieshhgvrghpihhnghgsihhtshdrnhgvth eqnecuggftrfgrthhtvghrnhepffehfffhieekhefhheeftdekteeivddufeetleeggeeh leeitdevudeggfegveegnecuffhomhgrihhnpehivghtfhdrohhrghdpghhithhhuhgsrd gtohhmpdhirhhtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhep mhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2524B3C00A1; Wed, 3 Jun 2020 12:15:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6 Mime-Version: 1.0 Message-Id: <4ad77854-3f39-4e92-abd1-c2df712417bf@www.fastmail.com> In-Reply-To: References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> Date: Wed, 03 Jun 2020 09:15:23 -0700 From: "Christopher Wood" To: "Chelsea Komlo" Cc: pearg@irtf.org Content-Type: text/plain Archived-At: Subject: Re: [Pearg] =?utf-8?q?Research_Group_Last_Call_for_=22A_Survey_of_Wo?= =?utf-8?q?rldwide_Censorship_Techniques=22?= X-BeenThere: pearg@irtf.org 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: Wed, 03 Jun 2020 16:16:45 -0000 Thanks for the review, Chelsea! On Tue, Jun 2, 2020, at 7:30 AM, Chelsea Komlo wrote: > Hi Chris, > > I have a couple meta points and a few specific points. > > Overall, my strongest recommendation is threefold. First, I recommend > improving the document organization to clearly differentiate between a > specific censorship technique and corresponding methods to circumvent > that technique. Second, I suggest strengthening the review of current > circumvention techniques and their effectiveness to give an improved > view of the landscape and to prevent re-inventing the wheel, as the > intended audience is protocol designers. Third, I recommend > differentiating between the capabilities of mature censors like China, > and weaker censors such as those with only off-the-shelf tools. > > Here is my discussion of these points in more detail. > > === Meta Points === > - While I understand this draft to be purely informational, > understanding censorship today is incomplete without understanding > existing censorship circumvention techniques, and how effective these > techniques are. Critically, some of the most effective and safe > censorship techniques are "hanging by a thread" in terms of how much > longer they will be available (such as domain fronting), so > understanding these weak areas is important to understanding the > sustainability of the current circumvention landscape. I suggest adding > at minimum a discussion of "Where are we today" regarding circumvention. > - To go along with the above point, providing a better review of > existing censorship circumvention techniques will help encourage > building on existing work, as opposed to re-inventing the wheel from > first principles. While perhaps this review should be a follow-up > document, I strongly encourage providing such a review, especially > since the intended audience is protocol designs. > - Within the draft itself, the discussion of censorship techniques is > often interwoven with circumvention methods. I suggest separating these > concepts out within each section. Instead of a "Tradeoffs" section, > perhaps have sections pertaining to "Cost to Implement to Censor", and > "Techniques to Circumvent", for improved clarity. > - One important point is that while China is an extremely powerful > censor, they are often in a class of their own. I encourage including a > discussion of something like "censor maturity" or the technical > resources required to implement different techniques. There is a bit of > this discussion, but it can be better standardized and applied to each > technique. For example, IP blacklisting is trivial and does not require > significant infrastructure (and many censors do this), but performing > active probing to fingerprint protocols and block them on the fly > requires much more infrastructure and planning (and is essentially only > China, as I understand). > > === Specific Points === > - DPI (deep packet inspection) is technically any kind of packet > analysis beyond IP address and port number- this concept can be better > clarified. Further, this technique is not specific to > - Clearly highlighting techniques that are thwarted by the use of TLS > versus techniques which can be performed even in spite of TLS usage > would also likely be helpful to readers. > > Thanks, > Chelsea > > On Wed, May 20, 2020 at 11:00 AM Christopher Wood wrote: > > This is the research group last call for the "A Survey of Worldwide Censorship Techniques" (draft-irtf-pearg-censorship) draft available here: > > > > https://datatracker.ietf.org/doc/draft-irtf-pearg-censorship/ > > > > Please review the document and send your comments to the list by June 5, 2020. Feedback may also be sent to the GitHub repository located here: > > > > https://github.com/IRTF-PEARG/rfc-censorship-tech > > > > Thanks, > > Chris, on behalf of the chairs > > > > -- > > Pearg mailing list > > Pearg@irtf.org > > https://www.irtf.org/mailman/listinfo/pearg > > > -- > Chelsea H. Komlo From nobody Fri Jun 5 09:54:31 2020 Return-Path: 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 855693A08FC for ; Fri, 5 Jun 2020 09:54:29 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains application/pgp-encrypted,.pgp,.pgp.asc,AD72F782.asc,UNDECIPHERABLE X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 erZZxmC8Y3hr for ; Fri, 5 Jun 2020 09:54:27 -0700 (PDT) Received: from rsi20.gerwanserver.de (rsi20.gerwanserver.de [IPv6:2a02:2260:2::5bdc:227f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D153A3A090A for ; Fri, 5 Jun 2020 09:54:26 -0700 (PDT) Received: from RR (83.5.154.60.ipv4.supernova.orange.pl [83.5.154.60]) by rsi20.gerwanserver.de (Postfix) with ESMTPSA id AB39859E117 for ; Fri, 5 Jun 2020 18:54:23 +0200 (CEST) Date: Fri, 5 Jun 2020 18:48:33 +0200 From: Heinrich Feuerbach To: "pearg@irtf.org" Message-ID: <20200605184833.3d8dbe74@RR> Organization: Feuerbach-Informatik MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/BNy1VV/6RNwuLjqIX3I9vDI"; protocol="application/pgp-signature" X-PPP-Message-ID: <159137606402.23791.4810309311367625120@rsi20.gerwanserver.de> X-PPP-Vhost: feuerbach.info Archived-At: Subject: [Pearg] ***UNCHECKED*** Asymmetrical communication endpoints (ACE) to ultimately enhance data privacy and data security of enduser computers X-BeenThere: pearg@irtf.org 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: Fri, 05 Jun 2020 16:54:30 -0000 --Sig_/BNy1VV/6RNwuLjqIX3I9vDI Content-Type: multipart/mixed; boundary="MP_/TMpI1P019xqcI4/9QuaLarf" --MP_/TMpI1P019xqcI4/9QuaLarf Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dear members of the pearg mailing list, today I would like to introduce you to an invention I made to guarantee in a physical manner the privacy of data of endpoints like PCs and Laptops and other computers used for communication via the internet. The physical way to ensure privacy is by asymmetry between "sending" and "receiving" to and from the networks like the internet, so to separate in, but have co-working systems for sending and receiving instead of just one system for both sending and receiving. Asymmetria in this sense is not as often used for describing different speeds for download and upload.=20 Following this asymmetry, these advantages can be reached regarding the privacy and data security, to name just a few: - the sender part of the system and its data is immune to any hacker attacks, as not being reachable via the network (just sending, not receiving anything)=20 - the receiver may further receive like in symmetrical communicating systems malware etc., however, the malware can't send anything back into the network like the internet. Therefore, any espionage on the data hosted on the receiver can't be successful. As well, spreading of infections from one computer to another is not longer possible then. - as data is held on both systems, sender and receiver in parallel, any ransomware-like attack can be fixed easily.=20 To make use of these big advantages (and many more), it is needed, beneath other issues, to solve the protocol gap problem in asymmetrical systems. I solved these issues already and put beneath the theory also a working proof of concept onto my website for download and evaluation: https://firewalls.feuerbach.info File: AKE_PoC.tar.gz Source code is as well in the gzipped tarball. The tarball is electronically signed by me. You may use and redistribute the tarball. Please check the README.odt inside the tarball as well for any productive/commercial usage. Thank you for your time. Heinrich Feuerbach --MP_/TMpI1P019xqcI4/9QuaLarf Content-Type: application/pgp-encrypted Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=AD72F782.asc LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tClZlcnNpb246IEdudVBHIHYyLjAu MjIgKEdOVS9MaW51eCkKCm1RRU5CRjNoZk5RQkNBRFRnd1hlRGpUVm9MRjBIdWFHbVVEeWdzYVhv amtPeGNhcTFpenkzd3BYSzBueUJYYm8KMEFWRGR3SjQ5Mm84TzVFZUgvWENaWHBwdHR5Sndjc1NU Ti91MWgzRTR2MXFtV2R1L3VaR0VDTDJrRGEvUHRCegorU1phNmM0NGtRcUZ6SzBOVW1hQUJGWVls S1R3WU8rRloyakp4Unl5dTJDYXNSOXlLWlJJMENPTjhGTUtWSGl0CkJxKzhCVkhUcTQ3MUF0dUNR NDdNQyt2bVdJUklhc1hpaWt3YWg1alFlc050V0lDWjBLQ2Urck1wdG5jekZHdWkKMmJDSyt5bStX eXNUNDEwWXdWeUR3ZFJTM2h5OEJPVFdFc0NTTGdrWXZDVDk5MVY4RkQ4eURzTnRDeFRKSWY4ZQo3 ZzEvU1AxTlRhVGY4Q0VzNHJaWGhERFBtYjEzSDQ4ZmhjODlBQkVCQUFHMEtrWmxkV1Z5WW1GamFD MUpibVp2CmNtMWhkR2xySUR4cGJtWnZRR1psZFdWeVltRmphQzVwYm1adlBva0JPUVFUQVFJQUl3 VUNYZUY4MUFJYkx3Y0wKQ1FnSEF3SUJCaFVJQWdrS0N3UVdBZ01CQWg0QkFoZUFBQW9KRVB5N3d0 S3RjdmVDdXFFSC8wYXA4VEltRnhISApHMTg2MlloQTgzWUd4ZWI5Z3lLKzkvNTlqREw5Vms1Tmd6 Ulc5RGFJVXVnV3BXNGthQkVQYVlaKzRrdGN3aXgrCjY1eGxKSE0zOWxkd3A3VGMwN2s4YkZITEFs VFA5M3BCSk1CV00xRitubEU5emhxeXNiT2dsUkpNRVlHazYxREoKd2M3OG1OV04raktldjVtcjMr eFcrdEZ6SDYyMTUzdjJzaGw1Um1yeU9OZjFJZDRxNGNycUVTQXFZZnREL2VhcQpUVFpPTTRRdHEy R0FYNDlmRnpUN2FxTDlaQ2JTeXZuYVQ1NFZOK081MUwwUi9INWtDdXhCaU9vQjF4Sjl0TUpvCmo1 WFhWcU9TaU13VlpGKzFzVHo4clNoMlpjMU9vZ3VFOUlieWRDM1h0VENtcFhnc0NBbktMSTFQd25p enI0OUUKQ1cwdlRmTzIxRlc1QVEwRVhlRjgxQUVJQUs2bTNrK1ZuT0c4VEJMQmdJTmFpVHhwMHhH bzUvaUlIQ0ZZSDM0NwpITDdYNTFsM0Y1REVmWWxHeDFUY1RtemRlWWUzTWFBY092TkJrRlh4dVVS YlFIN3g5eW5CbXp5Zkp6aS9GYXpZCko2OVRPOXNhREZNZGZBZEE3TnowcHdJSVRNS1Q0bmxwRkdn YlhVS2ZxdTh1UTRieHp0bVJXTjJkZXkrZHJBVVMKNGxZNHk4UHNyTVlmUHViV1ozSXFkQStzSFBJ ZnhEd2lIYWhaZ1ovQlFHN2o0cnhuUTlkeDR4WTM3WXp6UE5HUwppT2EzeWJGN2VUMWJQd1VTeTZF RHUyY1psT3hmaEhWYlVuQ1VJQkRRSlJ6R2wweDRyUWlZRU8xV2FPRFNqR2Q2CnpZSlhadlNUU01u STFiVy95STdoYmZaTEVXemxKZXRSbzA1dTIxazVEbmd5dHc4QUVRRUFBWWtDUGdRWUFRSUEKQ1FV Q1hlRjgxQUliTGdFcENSRDh1OExTclhMM2dzQmRJQVFaQVFJQUJnVUNYZUY4MUFBS0NSRG1DYjdT VWtkdAphOWJCQi93SWJQQmJYWHJBRlZPYVRqTlIwMFM5M1UwcWhTTEszaXhPckU3aFdBc3llVzEx bjBpTUFsM0lPQUViCjUxcWhsQUd0ak5MUFNyUEhZWEZVM1RXZmh3NFlhdVUrQVJDS0R2Q2RkME03 T3g3NEhpS3M1NFRXTG02QndiRnUKQUVuZFdXT2swakc0NzMwSVJLa3ljSFVFTURNVHNQWHc1a0tn QUZxTTloZjRHSkNTS1d5MGpJTGpENHpTRGFiRwpSMkdOT2JmUnJaMHZRR01RcVg2R0t5OXVHWXZD R0tVREVRWW9penJNZWJUNEtUODByTG4vVVRaUDc1MlpFbjNFCmFEcWhleTJCU1dEM1I2M2ZGMnpu M2c2MEJSQjdqNUZFYnZHT1J1NzZFUTFsQ3ZjL0pmZ25BaUlqcEV2N0RYcmQKM0RIUTd0eTNKOXlp Mld3anRXUlRWakk5NkNKc0pSVUlBSmVpZUVHMm9lRzNTbDA2V2thOFI0dGttejFmcmtFegpONzBm eUFZMThjSmdlUzhhYXhWem9IZEdYdVRPNnQ4NFRyMFBHZmxYOEN4SklYNHIzV3JlMDVIZ2hNSGdH WmNOCmNrTnExajNjUWVwTDFJcS9rSHlkZ1ZySCsvZTlvT1QrZ1A0NW5rSCtqNUkwZDM0d2FTb0lV T0ZOUWJWSlQ4L3MKYTg2eDNqK29NaFlJZ1VTMkF1aU1ZdWJGNW02ZnNxNmd5NkhRYmlaT2Q5UTl0 bUpRdzJLUEdBOFU1K1VzSnc4Ngpva3FMV21nSHVXUXlyV3ZxSTdIRXB4WWxHSVNRbzJ4UzJSU2M4 Zit2WXlZcHdxeEtsWC82ckkxL044bXFxcnVPCk55RDh4R2llcS9kc0o4Vm0wQnJsamN6WWVEdXFy RGxzSlYrWlVtemZoWXloNTFIY0JsTWxNRnM9Cj1FeXVWCi0tLS0tRU5EIFBHUCBQVUJMSUMgS0VZ IEJMT0NLLS0tLS0K --MP_/TMpI1P019xqcI4/9QuaLarf-- --Sig_/BNy1VV/6RNwuLjqIX3I9vDI Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJe2neCAAoJEOYJvtJSR21r1JwH/j+XDOOHt9aILXRx+Z7w1PTR 7vm19WOpfLX9qhEPT+2EHUj7ZHmPEL2aUdYS1ACXQvLzzarvQ1YUxQ/S4wju4lzX 4NCeVMQvYWVqp/NrYQOrvimyu9ymCXmyc4DJ8QyKcAWrMhvwg24OvdISwWNbxMdG Uwizd5hNzlZeaGeNAUqjlLUNGL9jJTER6vwd9pt5Me39EfXVQSYlDThScEiAslHa WIl5qsFQcvl+g+5sMJ6T082kYnVytW4Cz6L+yyEcHii9LsoZ12LOWdx0lcYi/Qh9 1ZKC5VlAflIcv35SfgCI3mQg91AOQxSoLqsTv8ixHViLiJBR4sC5dCqqpTj2/rI= =cOoS -----END PGP SIGNATURE----- --Sig_/BNy1VV/6RNwuLjqIX3I9vDI-- From nobody Fri Jun 5 16:35:39 2020 Return-Path: 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 38F3E3A0F40 for ; Fri, 5 Jun 2020 16:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=Wu15ZSV7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NZKmmE9d 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 XjNBSh6Xr_o1 for ; Fri, 5 Jun 2020 16:35:36 -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 A18AB3A0F3E for ; Fri, 5 Jun 2020 16:35:36 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id C44FE7A3 for ; Fri, 5 Jun 2020 19:35:35 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Fri, 05 Jun 2020 19:35:35 -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; s=fm1; bh=PZwS0UnGnY9J3H0jN405ceu8H2EBLIb O40KblO5NaHc=; b=Wu15ZSV7ZeuAnj1SVjfSo/Zu7JyWXqLZRNULKzcnJ0kkcEe hT/g5yRriBHsaU7a9TxdJcGQyJaWOIdasAc0BTheXOtQJNlrVuALCppzoPzF9Snl e6ZAteJPAk0UTQhkOgqQoADo8WRB9LBbSIKFhlRGOMeHG9O0OdQLvFhmqDT9Pfbm t06AR764iPhg2mQa5zy0ifRmMlmHNEi2oYsdEDaZtgYSD6SJUPDYnZMIU9iHSXMv Y8/GpHpj892aGUft70L4jbSCHADbc18axiO/N4icQto3i0ILuwIql5wU448XgE42 RCqHB1NGeq4+LWurIN9JKnQUIr5qlR1y7qs4BfQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; bh=PZwS0U nGnY9J3H0jN405ceu8H2EBLIbO40KblO5NaHc=; b=NZKmmE9dJQCpcWIB2Z3owa 7tmzQxL0z2zOTb8xFnXabgTZDRDd+mRlzQfpTstj5//8mOYrB0YmuQB8qF/UjnNE CMXtnd1/6mNApADS4wiTOuHq48ok66CLeWLL0AX1iL/E3AZob611+IrZlZE6LvhL wmy9Q8BuBM+44hcnWd/VeTJhwNSopx2vxC/MtTqKhejbNFXRSB1eThGqUjKOj0if T7inWbx2Yxgkzq6ZwhYtZ5xUWaCDSfTGApd0fCcoYOaaVf8TLkSdK+0p+5EZW9SW 1k88Rcog7c+h9KrXrX/vSugd8WCwwWWw0Gxg1Z0HV5Slgk9DVFS/23cBNHe5d6fw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeggedgvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucggtffrrghtthgvrhhnpeffheffhfeike ehhfehfedtkeetiedvudefteelgeegheeliedtvedugefggeevgeenucffohhmrghinhep ihgvthhfrdhorhhgpdhgihhthhhusgdrtghomhdpihhrthhfrdhorhhgnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhn ghgsihhtshdrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 027DE3C00A1; Fri, 5 Jun 2020 19:35:35 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6 Mime-Version: 1.0 Message-Id: <3eba505f-8e85-472c-b22a-660c6ec697c1@www.fastmail.com> In-Reply-To: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> Date: Fri, 05 Jun 2020 16:34:08 -0700 From: "Christopher Wood" To: pearg@irtf.org Content-Type: text/plain Archived-At: Subject: Re: [Pearg] =?utf-8?q?Research_Group_Last_Call_for_=22A_Survey_of_Wo?= =?utf-8?q?rldwide_Censorship_Techniques=22?= X-BeenThere: pearg@irtf.org 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: Fri, 05 Jun 2020 23:35:38 -0000 This research group last call is complete. Thanks to everyone who contributed along the way! Based on the feedback and reviews received thus far, the chairs think this document needs more work before moving ahead. We will follow up with Joe and the other authors to address all feedback in the coming weeks. Best, Chris, on behalf of the chairs On Wed, May 20, 2020, at 9:59 AM, Christopher Wood wrote: > This is the research group last call for the "A Survey of Worldwide > Censorship Techniques" (draft-irtf-pearg-censorship) draft available > here: > > https://datatracker.ietf.org/doc/draft-irtf-pearg-censorship/ > > Please review the document and send your comments to the list by June > 5, 2020. Feedback may also be sent to the GitHub repository located > here: > > https://github.com/IRTF-PEARG/rfc-censorship-tech > > Thanks, > Chris, on behalf of the chairs > > -- > Pearg mailing list > Pearg@irtf.org > https://www.irtf.org/mailman/listinfo/pearg > From nobody Fri Jun 5 16:36:43 2020 Return-Path: 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 719B93A0F3E for ; Fri, 5 Jun 2020 16:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, TRACKER_ID=0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 ViaiacIEJENl for ; Fri, 5 Jun 2020 16:36:39 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2086.outbound.protection.outlook.com [40.107.244.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63D363A0F3C for ; Fri, 5 Jun 2020 16:36:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I0Z2s0Ckwphn3Vn9W+5hLhI21on+s+7Su5MYdM9Rq1FNgWOsLVW5lOkQxh3wHyhlCtMEdg5q/wrZpEogAoMkBY9lMjTG7mCpvg5QXTSaodQF52slInCtB9fRraahCz2TUQUiKvFPPtP0oFQekkdpqSQ5D3BxJ3WxOE6E53jlnq+zRP3UrcgHeUFXlkPxDOs4XnvcPu7Cb4NiD4HBdlDvlLXzdo4RoxiVzwld8AwYXKNxLFlke3SvORt+CZKMIRPj2T+f3fe4v4d6jtXRUORZzQ3/kX7RBn/b6hBx51Bx1z1yS9z2Tw0hZHbXqeSOCypkSjkRTrk6BvsiT0KYZ6cHcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S+/12DdgUPREhAnpkanOMQ65c+RHFucfKiDINh9F73Y=; b=bGOFzaSmGWJptH/dI+qEBNTsrHzpN9BRfKTpzk3czchx1nu8BT0VOi9r1lH9kBjLJ10I9ojGhjt6Q7j2ir8JCxk+p3dJEVGftxljLS6qTiVdDpS/B5l95Ej1LwbxTSf5crYdXAAdZBu/SJ6T7WAznODkLHotpZj4Y8GBgMe38NZHa3VoX1Qn4zO5hvOc1+04xAo1sAvJsbHrA5xWEWBdMwHcW8b0GPhIwGbmym93NdxECydE9lmfnOI4tNc89gDuJQrxNhngUU2prKvfMEuG9906JyskSHJTdPAQOE6RNRWMTftWbQOigaX8KJ3Hw4GSN6J9PAj11xs2FO148LOdyA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S+/12DdgUPREhAnpkanOMQ65c+RHFucfKiDINh9F73Y=; b=m7LuybY7PGdp6QwK9cccb3jhws6H+s4pBOT/0k+8jmzzv1G276E31hTKnUXjR4V1Kd002G5xAQNNXUM+1MRmU8jE+YJOs7VlTBgZSSUpFCssr2suST6mpFoUcWO4bL/r4II/h2Fxn4VykAsIeRP19Zmd9fD2u6m83ghbnEHYG84= Received: from BY5PR06MB6451.namprd06.prod.outlook.com (2603:10b6:a03:21e::20) by BY5PR06MB6451.namprd06.prod.outlook.com (2603:10b6:a03:21e::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Fri, 5 Jun 2020 23:36:28 +0000 Received: from BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::b9b7:f0a7:b076:d5d5]) by BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::b9b7:f0a7:b076:d5d5%4]) with mapi id 15.20.3066.022; Fri, 5 Jun 2020 23:36:28 +0000 From: Joseph Lorenzo Hall To: Christopher Wood , "pearg@irtf.org" Thread-Topic: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques" Thread-Index: AQHWO5IJdAdUXxLXc02rGQraBpH79KjKrRVC Date: Fri, 5 Jun 2020 23:36:28 +0000 Message-ID: References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com>, <3eba505f-8e85-472c-b22a-660c6ec697c1@www.fastmail.com> In-Reply-To: <3eba505f-8e85-472c-b22a-660c6ec697c1@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: heapingbits.net; dkim=none (message not signed) header.d=none;heapingbits.net; dmarc=none action=none header.from=isoc.org; x-originating-ip: [108.28.51.147] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8939f2e3-fc84-4e6d-fe5b-08d809a944e9 x-ms-traffictypediagnostic: BY5PR06MB6451: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 0425A67DEF x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ohHLQuNue+aLqBDpH6eZcgLvJnUCOoO1W39s04VyAh3g9NJ30v4R29r/oF0W50S8tvqrgqU3Riq1mdrMcxUQMJbNH/NQeO0CU/nch4lE8+xtKYYTb1dp8w1McqNoO7623wWJFJF2b1FRh+qglFL23cwE5OQfe9NAW225Gh65+vY/CN/Dsut+rUL/FHjRTBDB1Ee/0VXefKqBVpInVhEYBAJocxOsjj1ZP+YyW0FdbyinozqpzpZRCBQ5WayBrE79u78ETBuqPWhI83OQaejyd4ECa7aEQqdGj4UZxP+6a0zxsCxfOc/nmod6GuAS4d2LiM/D2OfRdpSsLWwM7r1/fNeswfjqEnsdHSKtNpjJaGR8Nbl1oZsz4078MCAGqD5ZRkiLUXX+c4g0yFCookEtWA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR06MB6451.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(136003)(396003)(366004)(346002)(39840400004)(376002)(53546011)(166002)(7696005)(52536014)(316002)(6506007)(9686003)(26005)(110136005)(33656002)(55016002)(66946007)(66574014)(5660300002)(76116006)(186003)(478600001)(86362001)(966005)(66556008)(2906002)(66446008)(64756008)(71200400001)(66476007)(8936002)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: tAUieRacQwevEl0FDUY5l/7hJo9/W/jIq5Mj+CDg8M7/rNd6Em9Yr1Su0gxe258E9pCenGVO829HkTs6CkAh9rVkuY9zXgJOP1YNsVIKfp8sEvIXau61lHpDoWfaPocQpWd3CeqBT/4wvclNMtgfMnTYOlL/RnZNo42jNSZzHRpU+WztVSPkNK+Sd9R4tuFZSN+DeVLCcPndq8NxBJzLgRCMlqnZ9nYFJnNKHFp1cdeJr7tvq2dnDVjYU4KX/WElL6nBuv22u9OHbRXFXBAHMBPRVH3lyi0HCb/TF0xbna1Cgmr+ac+iMc9aevQrsNE5C0o3hF6bWcWi6XMFHKIwpEMxLGsz4q8/4UgLFuh4AmXZm2HogYzFSoOGPvYXIl7qq3kYUKHh+wvHUFnuuN3F6g0a3I2NX9DMY6tiMT9lQ8ygy411seaER8VxyEGGGJ+u3EN9VdrqFKCI6H/7NYjgUNeTJPDkd9aP2tTBvFmw+X8vHvHX+x0XZ+fPitQ7J+cv x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR06MB6451CAEC5B1CF4FC2C32432EB1860BY5PR06MB6451namp_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 8939f2e3-fc84-4e6d-fe5b-08d809a944e9 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2020 23:36:28.2666 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: opuZThN8J4NdPr6zN9Eak6lucvmGwum147vG74K/ewL5/ywD3yfCPNIfXS/RvRwE X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR06MB6451 Archived-At: Subject: Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques" X-BeenThere: pearg@irtf.org 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: Fri, 05 Jun 2020 23:36:41 -0000 --_000_BY5PR06MB6451CAEC5B1CF4FC2C32432EB1860BY5PR06MB6451namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agreed! Thank you everyone, more to come -- Joseph Lorenzo Hall, Senior Vice President, Strong Internet hall@isoc.org | +1-703-483-9504 internetsociety.org | @internetsociety pgp: https://josephhall.org/gpg-key 3CA28D7B9F6DDBD34B1016075F86698740A9A871 ________________________________ From: Pearg on behalf of Christopher Wood Sent: Friday, June 5, 2020 7:34:08 PM To: pearg@irtf.org Subject: Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Ce= nsorship Techniques" This research group last call is complete. Thanks to everyone who contribut= ed along the way! Based on the feedback and reviews received thus far, the chairs think this = document needs more work before moving ahead. We will follow up with Joe an= d the other authors to address all feedback in the coming weeks. Best, Chris, on behalf of the chairs On Wed, May 20, 2020, at 9:59 AM, Christopher Wood wrote: > This is the research group last call for the "A Survey of Worldwide > Censorship Techniques" (draft-irtf-pearg-censorship) draft available > here: > > https://datatracker.ietf.org/doc/draft-irtf-pearg-censorship/ > > Please review the document and send your comments to the list by June > 5, 2020. Feedback may also be sent to the GitHub repository located > here: > > https://github.com/IRTF-PEARG/rfc-censorship-tech > > Thanks, > Chris, on behalf of the chairs > > -- > Pearg mailing list > Pearg@irtf.org > https://www.irtf.org/mailman/listinfo/pearg > -- Pearg mailing list Pearg@irtf.org https://www.irtf.org/mailman/listinfo/pearg --_000_BY5PR06MB6451CAEC5B1CF4FC2C32432EB1860BY5PR06MB6451namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Agreed! Thank you everyone, more to come

--
Joseph Lorenzo Hall, Senior Vice President, = Strong Internet
hall@isoc.org | +1-703-483-9504
internetsociety.org | @internetsociety
pgp: https://josephhall.org/gpg-key
3CA28D7B9F6DDBD34B1016075F86698740A9A871
From: Pearg <pearg-bounc= es@irtf.org> on behalf of Christopher Wood <caw@heapingbits.net> Sent: Friday, June 5, 2020 7:34:08 PM
To: pearg@irtf.org <pearg@irtf.org>
Subject: Re: [Pearg] Research Group Last Call for "A Survey of = Worldwide Censorship Techniques"
 
This research group last call is complete. Thanks = to everyone who contributed along the way!

Based on the feedback and reviews received thus far, the chairs think this = document needs more work before moving ahead. We will follow up with Joe an= d the other authors to address all feedback in the coming weeks.

Best,
Chris, on behalf of the chairs

On Wed, May 20, 2020, at 9:59 AM, Christopher Wood wrote:
> This is the research group last call for the "A Survey of Worldwi= de
> Censorship Techniques" (draft-irtf-pearg-censorship) draft availa= ble
> here:
>
>    https://datatracker.ietf.org/doc/draft-irtf-pearg-cen= sorship/
> 
> Please review the document and send your comments to the list by June =
> 5, 2020. Feedback may also be sent to the GitHub repository located > here:
>
>    https://github.com/IRTF-PEARG/rfc-censorship-tech
>
> Thanks,
> Chris, on behalf of the chairs
>
> --
> Pearg mailing list
> Pearg@irtf.org
> https://www.ir= tf.org/mailman/listinfo/pearg
>

--
Pearg mailing list
Pearg@irtf.org
https://www.irtf.or= g/mailman/listinfo/pearg
--_000_BY5PR06MB6451CAEC5B1CF4FC2C32432EB1860BY5PR06MB6451namp_-- From nobody Tue Jun 9 09:50:35 2020 Return-Path: X-Original-To: pearg@irtf.org Delivered-To: pearg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 565AA3A098E; Tue, 9 Jun 2020 09:50:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ssahib@salesforce.com, irtf-chair@irtf.org, pearg-chairs@ietf.org, pearg@irtf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159172143375.26172.12503977218445526976@ietfa.amsl.com> Date: Tue, 09 Jun 2020 09:50:34 -0700 Archived-At: Subject: [Pearg] pearg - New Meeting Session Request for IETF 108 X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 16:50:34 -0000 A new meeting session request has just been submitted by Shivan Kaul Sahib, a Chair of the pearg working group. --------------------------------------------------------- Working Group Name: Privacy Enhancements and Assessments Research Group Area Name: IRTF Session Requester: Shivan Sahib Number of Sessions: 1 Length of Session(s): 100 Minutes Number of Attendees: Conflicts to Avoid: Chair Conflict: hrpc cfrg irtfopen qirg tls git Technology Overlap: dprive mls httpbis quic dnssd saag dnsop People who must be present: Sara Dickinson Christopher A. Wood Shivan Kaul Sahib Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Jun 18 11:11:14 2020 Return-Path: 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 6F8163A0DD3 for ; Thu, 18 Jun 2020 11:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=gmail.com 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 BdUX6Hr326N7 for ; Thu, 18 Jun 2020 11:11:04 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 093163A0DD7 for ; Thu, 18 Jun 2020 11:11:04 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id y5so8064127iob.12 for ; Thu, 18 Jun 2020 11:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bOsp58RWLzDNARwMacijYwACs/1rApZ151lFSe2jnHc=; b=ZD5scNRCKnV0dwTyTLG5GBj82vC7n0a1TVHMnPBnTCCoQgkFkxSAWp5hVRfjvnCyie oCVK/gDEfiqf9uqq5xNMlb7SM6zxli9Y6FYK0Vai+KHk5j+b+VFmGlRLlMaCVxgJEsSN O1oWyJgyX25k1/t646gUMmKDQNgSLwHwJ47YpFQYOPFVahglaq81VA3x8rH35K+FxOmw SE4qcWCvuLiQ8ATy3K9ZHxaDDZbhDNdavsefRdxSTAq7vHBPWBstL7kIuCMhqk/8bVIv fUv4h/PmvO+mSDFVnvwQvgKi7EtQIP09Zhx08fCK8IqgBMsLEQXHUDcgnhVOcCHqI0l9 eRDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bOsp58RWLzDNARwMacijYwACs/1rApZ151lFSe2jnHc=; b=DBEOptbu26jeGZbgIAX7AFHhAjJyYN4Bq1HsHMK7WGfs5hmRPPnzExqwdcEf1WVLt0 WCy+vCovya2rtxwDPUMghOeXKqsGrRDRo/sIcakP7lC3PAz67SIagJCaS1f23kv7LNXK uIKdyg/TEakTOgRj/lOI2TzIXEwlMrsDhoCJqpcd5zYomblIddcOLYqZU8Z+n1djJdGk B8NbgSUjykYGTnxnDlicFDlg0tI0yCN7sXe7PIvgqn9o7fh9DjZexLpjtt4yX1n962XI tWh8BD84Kkp8sHuE04IB0sVYpvgp4nHSK6vDeKZ0zWr2qenCs7kSLXvVUSgl4BgPoYdC Thdw== X-Gm-Message-State: AOAM531el76IK6DOBLJ0Rirlc0krNHu0jn+8BhIVL5yeFjTAVmNoeNs6 0F3n5OBOHropF63dxt64xt+GZMQFpUig8zOb99w= X-Google-Smtp-Source: ABdhPJzZwSxWf9JE8CWyUfX/avR7Vltk6grRTOEl2/V9aUh2fircrkxWBOw7Ni97AhW4hofFFHL56LNf5EHPUkqO7ZQ= X-Received: by 2002:a5d:9dd2:: with SMTP id 18mr6341427ioo.196.1592503863354; Thu, 18 Jun 2020 11:11:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sandeep Rao Date: Thu, 18 Jun 2020 23:40:51 +0530 Message-ID: To: Joseph Salowey Cc: pearg@irtf.org Content-Type: multipart/alternative; boundary="00000000000014284305a85fb3c0" Archived-At: Subject: Re: [Pearg] Comments on draft-rao-pitfol-01 X-BeenThere: pearg@irtf.org 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: Thu, 18 Jun 2020 18:11:07 -0000 --00000000000014284305a85fb3c0 Content-Type: text/plain; charset="UTF-8" Hi Joe, Apologies for the delayed response. Thanks for your review and comments. Appreciate your time on this. Please find replies inline ... I had a chance to review draft-rao-pitfol-01. Sensitive information in > logs is a constant problem for many security and privacy organizations so I > am very happy to see this draft. Below are some thoughts on the draft. > > 1. While PII information is super important, the problem extends to all > types of sensitive information in logs. One common example is service > credentials written to logs or data that is confidential to an organization > and not an individual. I don't see anything that would limit this approach > to just PII, but it may extend the use cases a bit. > [sandeep]: Agree that the mechanism can be generalized to annotate anything that is deemed sensitive in logs. While the draft specifically discusses and illustrates tagging of PII data, we will think about extending this to mark other sensitive data. > 2. Log data is incredibly useful for troubleshooting, analytics and > other purposes. To meet these use cases the log data may be propagated, > extracted, transformed and stored in multiple places. This creates some > challenges: > > A. The data may be transformed into other data models and formats may not > preserve any privacy marking > B. If the privacy marking changes on a field it's unclear what should be > done to historical data. > > [sandeep]: Great points! (A) Privacy marking preservation across log/data transformations is critical as it flows through the log pipeline into various systems. While privacy marking and privacy preservation are discrete, we can emphasize that it is necessary to carry forward any privacy markings across format transformations without being prescriptive about it. (B) Agreed, I think retrospective change can be challenging. We will think through this and provide some guidance on this in the draft. > 3. Often when a sensitive value is written to a log it has gone > undetected for a period of time. The values have now propagated to > multiple systems and the task of the team responding to the incident is to: > > - stop the logging or mis-identification of the data > - determine where the sensitive data has propagated to > - purge (or other action) the sensitive date from where it now lives > - perform remedial actions and notifications (for example to rotate > credentials) > > I would like a system that helps to automate this. I think the draft > provides part of the solution, but it seems there should be more to the > solution: > > 1. Information and data models for sensitivity/privacy tagging of data > 2. Ways of attaching that sensitivity/privacy tagging to the data > itself (similar to current draft) > 3. Interface to systems to control > - actions based on tagging > - changes to tagging/classification > - communication of tagging/classification "out-of-band" > > I'm not really up on the state of the art here. I know there exists > proprietary protocols that do similar, but I'm not aware of any standards > work in this area. > [sandeep]: Carrying privacy annotations as you illustrated below can potentially help in automation of certain incident remediation actions. This can be a good requirement / use case to think through on the lines of 'Course of Action" for Sensitive data detection incident response, will think of addressing this as an addendum or in another write up. we can discuss further on this. > As an illustration a JSON message could contain a field descriptor to > match on a field and an action to take when you match on the field. > > { > "dataFieldDescriptor": { > "LogStream": "AuthenticationService", > "eventType": "Login", > "jsonField": "sessionID", > "startDate": "None", > "endDate": "Now" > }, > "action": { > "SensitivityLevelTag": "4", > "NotificationType": "SummaryReport", > "Action": "FullAnonymization", > } > } > > This message would be sent to one or more systems. It may result in the > inline tagging described in the draft, but the message could be propagated > in other ways. ETL systems that transform the data could transform the > request for the systems that consume their data. The actions can be > optional and derived from the default for the sensitivity level. > Notification and reporting is an essential piece of the puzzle. The > interface could be provided by log aggregators, endpoints, and ETL > systems. > > This provides a standard interface to different places that store data > derived from logs to remediate problems in their existing data. It could > potentially be used to service deletion requests and maybe information > requests. This obviously needs refinement. A higher level abstraction > could decouple the request from the logging format and allow the request go > through stages. For example the request says "delete user x@y.com" and > then intermediate systems fill out how to fulfil the request. > [sandeep]: We are experimenting various annotation formats, the above is a good illustration, we will more update on this soon. Thanks so much, great inputs, will follow up on this soon. Regards, -Sandeep > Cheers, > > Joe > > > > -- > Pearg mailing list > Pearg@irtf.org > https://www.irtf.org/mailman/listinfo/pearg > --00000000000014284305a85fb3c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joe,

Apologies for the de= layed=C2=A0response.=C2=A0

Thanks for your=C2= =A0review and comments. Appreciate your time on this.=C2=A0 Please find rep= lies inline ...

I had a chance to re= view=C2=A0draft-rao-pitfol-01.=C2=A0 Sensitive=C2=A0information in logs is = a constant problem for many security and privacy organizations so I am very= happy to see this draft.=C2=A0 Below are some thoughts on the draft.
<= br>
1.=C2=A0 While PII information is super important, the p= roblem=C2=A0extends=C2=A0to all types of sensitive information in logs.=C2= =A0 One common example is service credentials written to logs or data that = is confidential to an organization and not an individual.=C2=A0 I don't= see anything that would limit this approach to just PII, but it may extend= the use cases a bit.=C2=A0=C2=A0

[sandeep]:=C2=A0 Agree that the mechanism can be generalized to an= notate anything that is deemed sensitive in logs. While the draft specifica= lly discusses and illustrates tagging of PII data, we will think=C2=A0about= =C2=A0extending this to mark other sensitive data.

2.=C2=A0 Log data is incredibly=C2=A0useful for troubleshootin= g,=C2=A0 analytics and other purposes.=C2=A0 =C2=A0To meet these use cases = the log data may be propagated, extracted, transformed and stored in multip= le places.=C2=A0 This creates some challenges:

A. = The data may be transformed into other data models=C2=A0and formats may not= preserve any privacy marking
B.=C2=A0 If the privacy marking cha= nges on a field it's unclear what should be done to historical data.=C2= =A0


[sande= ep]:=C2=A0=C2=A0

Great points!=C2=A0=C2=A0

(A) Privacy marking preservation across log/data transfor= mations is critical as it flows through the log pipeline into various syste= ms.=C2=A0 While privacy marking and privacy preservation are discrete, we c= an emphasize=C2=A0that it is necessary to carry forward any privacy marking= s across format transformations without being prescriptive about it.

(B) Agreed, I think retrospective change can be cha= llenging.=C2=A0 We will think through this and provide some guidance on thi= s in the draft.

=C2=A0
3.=C2=A0 = Often when a sensitive value is written to a log it has gone undetected for= a period of time.=C2=A0 The values have now propagated to multiple systems= and the task of the team responding to the incident is to:
    <= li style=3D"margin-left:15px">stop the logging or mis-identification of the= data
  • determine where the sensitive data= has propagated to
  • purge (or other actio= n) the sensitive date from where it now lives
  • perform remedial actions and notifications (for example to rotate cre= dentials)
I would like a system that helps to automate this.= =C2=A0 I think the draft provides part of the solution, but it seems there = should be more to the solution:
  1. Information and data mode= ls for sensitivity/privacy tagging of data
  2. Ways of attaching that s= ensitivity/privacy tagging to the data itself (similar to current draft)
  3. Interface to systems to control
    • actions based on tagging<= /li>
    • changes to tagging/classification
    • communication of tagging/= classification "out-of-band"
I'm not= really up on the state of the art here.=C2=A0 I know there exists propriet= ary protocols that do similar, but I'm not aware of any standards work = in this area.=C2=A0=C2=A0

=
[sandeep]: Carrying privacy annotations as you illustrated below= can potentially help in automation of certain incident remediation actions= . This can be a good requirement / use case to think through on the lines o= f 'Course of Action" for Sensitive data detection incident respons= e, will think of addressing this as an addendum or in another write up. we = can discuss further on this.
=C2=A0
As an illustration a JSON m= essage could contain a field descriptor to match on a field and an action t= o take when you match on the field.=C2=A0

{=C2= =A0=C2=A0
=C2=A0 =C2=A0"dataFieldDescriptor": {=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"LogStream": "Aut= henticationService",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"= ;eventType": "Login",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&= quot;jsonField": "sessionID",
=C2=A0 =C2=A0 =C2=A0= =C2=A0 "startDate": "None",
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 "endDate": "Now"
=C2=A0 =C2=A0 = },
=C2=A0 =C2=A0 "action": {
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"SensitivityLevelTag": "4&= quot;,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Noti= ficationType": "SummaryReport",
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Action": "FullAnonymization&= quot;,
=C2=A0 =C2=A0 }
}

This = message would be sent to one or more systems.=C2=A0 It may result in the in= line tagging described in the draft, but the message could be propagated in= other ways.=C2=A0 =C2=A0ETL systems that transform the data could transfor= m the request for the systems that consume their data.=C2=A0 The actions ca= n be optional=C2=A0and derived from the=C2=A0default for the sensitivity le= vel.=C2=A0 =C2=A0Notification and reporting is an essential piece of the pu= zzle.=C2=A0 The interface could be provided by log aggregators, endpoints, = and ETL systems.=C2=A0=C2=A0

This provides a stand= ard interface to different places that store data derived from logs to reme= diate problems in their existing data.=C2=A0 It could potentially be used t= o service deletion requests and maybe information requests.=C2=A0 This obvi= ously needs refinement.=C2=A0 A higher level abstraction could decouple the= request from the logging format and allow the request go through stages.= =C2=A0 For example the request says "delete user=C2=A0x@y.com" and then intermediate system= s fill out how to fulfil=C2=A0the request.=C2=A0

[sandeep]:=C2=A0 We are experimenting various annotation = formats, the above is a good illustration, we will more update on this soon= .

Thanks so much, great inputs, will follow up on = this soon.

Regards,
-Sandeep
<= br>
--00000000000014284305a85fb3c0-- From nobody Mon Jun 29 13:47:52 2020 Return-Path: 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 A0FDA3A0BD8 for ; Mon, 29 Jun 2020 13:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 czkJGJ0Ibufy for ; Mon, 29 Jun 2020 13:47:49 -0700 (PDT) Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1E423A0C13 for ; Mon, 29 Jun 2020 13:47:48 -0700 (PDT) X-Originating-IP: 212.76.239.56 Received: from [192.168.0.233] (cable-212.76.239.56.coditel.net [212.76.239.56]) (Authenticated sender: amelia@andersdotter.cc) by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id 2CF37240008 for ; Mon, 29 Jun 2020 20:47:45 +0000 (UTC) To: pearg@irtf.org Reply-To: amelia.ietf@andersdotter.cc From: Amelia Andersdotter Message-ID: <081f4817-5635-7b74-d435-c33595cf045d@andersdotter.cc> Date: Mon, 29 Jun 2020 22:46:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Pearg] agenda request for Randomized response mechanisms in round-trip time measurements X-BeenThere: pearg@irtf.org 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: Mon, 29 Jun 2020 20:47:51 -0000 Dear iedereen, Would like to request time on the PEARG agenda ahead of IETF 108 to present a new version of https://datatracker.ietf.org/doc/draft-andersdotter-rrm-for-rrt-in-http3/ (to be created) best regards, Amelia From nobody Mon Jun 29 15:15:58 2020 Return-Path: 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 398E33A0DE1 for ; Mon, 29 Jun 2020 15:15:47 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 WoYgEU6NV5pn for ; Mon, 29 Jun 2020 15:15:44 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2063.outbound.protection.outlook.com [40.107.244.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D18E23A0DE5 for ; Mon, 29 Jun 2020 15:15:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Krzgu66g0iakbjLF3cN/eg+yKVPFjWSl1J2G79Np3AoXDCzLH58uBTWnmpnNGk8FX3flWQbmgShkqXScItPtK4WgRqb0EKmybLkRDQCLi2auIucVYDEDW5EtYcmd3kkEnRIyOu94wx/q7Mel3YiXnCTdXX9hMvvBWBQplkJE1kcoBxsit1WpBnhUPAaF2b9H4XJeSWy5yXpK84tzxvY/+ElgA5kHUz3+CBiO6oUV1zdJMn/yMQcm8vX1hWWFKM1ZSXmJshT/PWWHy+L3/hxFmqt504a6WAKwNxNMYJepAerrt5cVzKANzzexoL/ns9oKITQ2yg1pxjYn4tewplUNPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kho9eYXdLZmEMMiZXEkvUcb5BO1goBNI6CsedfcXDuw=; b=Z1g5y2Rzcem88ePWq67+RvHhMALXr5pG3P15bvDtGBHgXUGKlowieTGIKkCS32QBVlr+j6AtFUjJ8ue1+vSmEZZ1vlYgD1g4K7m6XjNFnW2UFqiVjL9+OgXu87mJDhkHEc7gb0JTLKl2CRU9quuXRetcigDCyBvj6Czd4zSfqRxg0nhV9bV4dQNHUsIpkCkaMLLkIh92Q6brB8lzDB4XPHSIF4u28DGU+8VC+97OUHK24XhoOOBWdF6lEqvcr59dH0JL/dyiiYIKZNPHRlqh2QBnzfPOd9mWca/Ldz1KlZcqycBvKSYOCBGmgWsYV54IOMgwtG0pYQfkgGdBSfW7Fg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kho9eYXdLZmEMMiZXEkvUcb5BO1goBNI6CsedfcXDuw=; b=A4TVQ3qilZUee/tJ1lKG8cdu7Yzz4PnyjVsV/IxNDNrYmmjR4SluwPciWky9rJM32D2f5Jm/y+HhkZQWO/YwRAxX79nw5HV2qDqzJgh6eqfhpZTY6rodko/0doVFMTlkwkVur4YXma/34feAzIjixFqkG79QOauQdslFxN67oDI= Received: from BY5PR06MB6451.namprd06.prod.outlook.com (2603:10b6:a03:21e::20) by BYAPR06MB4821.namprd06.prod.outlook.com (2603:10b6:a03:7d::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.25; Mon, 29 Jun 2020 22:15:43 +0000 Received: from BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::b9b7:f0a7:b076:d5d5]) by BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::b9b7:f0a7:b076:d5d5%4]) with mapi id 15.20.3131.026; Mon, 29 Jun 2020 22:15:43 +0000 From: Joseph Lorenzo Hall To: Amelia Andersdotter , Christopher Wood , "pearg@irtf.org" Thread-Topic: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques" Thread-Index: AQHWTlu2B5pg6PmZEE6Yav+dAms/Z6jwKNRD Date: Mon, 29 Jun 2020 22:15:43 +0000 Message-ID: References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <3eba505f-8e85-472c-b22a-660c6ec697c1@www.fastmail.com> , <3ed2d30b-9a8d-432f-273e-f2ca183f0f22@andersdotter.cc> In-Reply-To: <3ed2d30b-9a8d-432f-273e-f2ca183f0f22@andersdotter.cc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: andersdotter.cc; dkim=none (message not signed) header.d=none;andersdotter.cc; dmarc=none action=none header.from=isoc.org; x-originating-ip: [108.56.212.130] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 54ea901d-3cba-446b-abc3-08d81c79f732 x-ms-traffictypediagnostic: BYAPR06MB4821: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2657; x-forefront-prvs: 044968D9E1 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yyQdNVpTqSJkaxOKtHoeXo2NBwgCs99SpR7CUDNJ8wH5NVajvSn4Xivof3wNCfoyFjL5H2hT+9vVvvGIxVHe7Gd96YQsMn40BupP6YVdsR6M480iS7sqA9qz9ijl9Glj0Qru3HYgJaotCojiEh6SMMhBJxtDKN+fUn7yd9AdpxO02oO6KqWxts44Oe0WTQ/fxNSQGUIJUXWY5GiUQ7A2GLq6ajeW+qPxmUQzPNp59tJ1e090zjV3huUbVd+Ir8ZSjBGVfcSJKCJDuJtLiNCqpYxJJsLcrFZArI4ATgMcRSA3g/Lgp0F67+JT/eHs33gHtdws+1j96CP7zpUb9kIOD5pPfu0KphfM41sPu5m/5l8zORnyRQN7e2O7hl45456XR2/vQCOe1A4NkIcNBKIlhA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR06MB6451.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(39840400004)(376002)(396003)(346002)(366004)(136003)(186003)(66446008)(64756008)(66556008)(66476007)(2906002)(83380400001)(19627405001)(478600001)(166002)(966005)(53546011)(8936002)(8676002)(110136005)(316002)(71200400001)(76116006)(33656002)(6506007)(86362001)(7696005)(5660300002)(66946007)(66574015)(55016002)(26005)(9686003)(52536014)(91956017); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: I5jyqy4VanQBF9zLohqnrWFY5BtBNOjM5XbZWZvWngjIZCwaIi8JYoIJ8SYfCcA24RZ2fgQ6JUWK6RUkanLC+AazNXiiLGjN8cMeO68ZTl4fqPURuAa7lRua7YVCnSfpDyXvWCMN5FQVt0UahsGh1h6+gJbM+A2tJRPNvShFVPojd0Ap0Xb0NMrvGoCkpufTkINCMKax7g2D2H4PS5jiizSi10//PLrJuHi6mku/tkGau2ORPc/e7S3uKid+foJjll2lZrNUQTdqQBJLz7wBbG6FAaM0f4fEGUTp/dEWVN+OhL+E9bxILlK8HKoEXDLF52dZCfEYT9SBVOJUc8KrH+k1CgcBOpuWgpLbmMTIIJhsr2NPNMuDunot4uBdRIXCUg8jwvH1RxwOto8KLLvZ8W5jqKYcP53z0kppzxBpO+RSap8Uie39gtROGTyPrzAYnvoStahkva6FNK/4YuJmOD2X2ceB4yoDcWim9DdcTBsm1ISuCl4ZMIJoZtL/7EUy x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR06MB6451000D6397DFE09F93BB26B16E0BY5PR06MB6451namp_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR06MB6451.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 54ea901d-3cba-446b-abc3-08d81c79f732 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2020 22:15:43.4548 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Hc24H1wDhnvuOLzcosXn1+WJctwMTF5m5kVWplj9G3Z4p2OT1sQvZ33N4dawBFAc X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR06MB4821 Archived-At: Subject: Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques" X-BeenThere: pearg@irtf.org 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: Mon, 29 Jun 2020 22:15:56 -0000 --_000_BY5PR06MB6451000D6397DFE09F93BB26B16E0BY5PR06MB6451namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Wow, thank you so much, Amelia! ________________________________ From: Amelia Andersdotter Sent: Monday, June 29, 2020 17:22 To: Joseph Lorenzo Hall ; Christopher Wood ; pearg@irtf.org Subject: Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Ce= nsorship Techniques" Dear all, Without trying to definitely capture all the comments that were made in the last-call, I have added a bunch of issues on the github with proposed resolutions to some of the questions raised by you all: https://github.com/IRTF-PEARG/rfc-censorship-tech/issues I realized that there are a few things that may, at least from my side, require further reflection. I'll send a separate e-mail about this. best regards, Amelia On 2020-06-06 01:36, Joseph Lorenzo Hall wrote: > Agreed! Thank you everyone, more to come > > -- > Joseph Lorenzo Hall, Senior Vice President, Strong Internet > hall@isoc.org | +1-703-483-9504 > internetsociety.org | @internetsociety > pgp: https://josephhall.org/gpg-key > 3CA28D7B9F6DDBD34B1016075F86698740A9A871 > ------------------------------------------------------------------------ > *From:* Pearg on behalf of Christopher Wood > > *Sent:* Friday, June 5, 2020 7:34:08 PM > *To:* pearg@irtf.org > *Subject:* Re: [Pearg] Research Group Last Call for "A Survey of > Worldwide Censorship Techniques" > > This research group last call is complete. Thanks to everyone who > contributed along the way! > > Based on the feedback and reviews received thus far, the chairs think > this document needs more work before moving ahead. We will follow up > with Joe and the other authors to address all feedback in the coming > weeks. > > Best, > Chris, on behalf of the chairs > > On Wed, May 20, 2020, at 9:59 AM, Christopher Wood wrote: > > This is the research group last call for the "A Survey of Worldwide > > Censorship Techniques" (draft-irtf-pearg-censorship) draft available > > here: > > > > https://datatracker.ietf.org/doc/draft-irtf-pearg-censorship/ > > > > Please review the document and send your comments to the list by June > > 5, 2020. Feedback may also be sent to the GitHub repository located > > here: > > > > https://github.com/IRTF-PEARG/rfc-censorship-tech > > > > Thanks, > > Chris, on behalf of the chairs > > > > -- > > Pearg mailing list > > Pearg@irtf.org > > https://www.irtf.org/mailman/listinfo/pearg > > > > -- > Pearg mailing list > Pearg@irtf.org > https://www.irtf.org/mailman/listinfo/pearg > -- Amelia Andersdotter amelia.andersdotter.cc --_000_BY5PR06MB6451000D6397DFE09F93BB26B16E0BY5PR06MB6451namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Wow, thank you so much, Amelia!
From: Amelia Andersdotter &= lt;amelia@andersdotter.cc>
Sent: Monday, June 29, 2020 17:22
To: Joseph Lorenzo Hall <hall@isoc.org>; Christopher Wood <= caw@heapingbits.net>; pearg@irtf.org <pearg@irtf.org>
Subject: Re: [Pearg] Research Group Last Call for "A Survey of = Worldwide Censorship Techniques"
 
Dear all,

Without trying to definitely capture all the comments that were made in
the last-call, I have added a bunch of issues on the github with
proposed resolutions to some of the questions raised by you all:
https:= //github.com/IRTF-PEARG/rfc-censorship-tech/issues

I realized that there are a few things that may, at least from my side,
require further reflection. I'll send a separate e-mail about this.

best regards,

Amelia

On 2020-06-06 01:36, Joseph Lorenzo Hall wrote:
> Agreed! Thank you everyone, more to come
>
> --
> Joseph Lorenzo Hall, Senior Vice President, Strong Internet
> hall@isoc.org | +1-703-483-9504
> internetsociety.org | @internetsociety
> pgp: https://josephhall.org= /gpg-key
> 3CA28D7B9F6DDBD34B1016075F86698740A9A871
> ----------------------------------------------------------------------= --
> *From:* Pearg <pearg-bounces@irtf.org> on behalf of Christopher = Wood
> <caw@heapingbits.net>
> *Sent:* Friday, June 5, 2020 7:34:08 PM
> *To:* pearg@irtf.org <pearg@irtf.org>
> *Subject:* Re: [Pearg] Research Group Last Call for "A Survey of<= br> > Worldwide Censorship Techniques"
>  
> This research group last call is complete. Thanks to everyone who
> contributed along the way!
>
> Based on the feedback and reviews received thus far, the chairs think<= br> > this document needs more work before moving ahead. We will follow up > with Joe and the other authors to address all feedback in the coming > weeks.
>
> Best,
> Chris, on behalf of the chairs
>
> On Wed, May 20, 2020, at 9:59 AM, Christopher Wood wrote:
> > This is the research group last call for the "A Survey of Wo= rldwide
> > Censorship Techniques" (draft-irtf-pearg-censorship) draft a= vailable
> > here:
> >
> >    https://datatracker.ietf.org/doc/draft-irtf-pear= g-censorship/
> > 
> > Please review the document and send your comments to the list by = June
> > 5, 2020. Feedback may also be sent to the GitHub repository locat= ed
> > here:
> >
> >    https://github.com/IRTF-PEARG/rfc-censorship-tech
> >
> > Thanks,
> > Chris, on behalf of the chairs
> >
> > --
> > Pearg mailing list
> > Pearg@irtf.org
> > https://w= ww.irtf.org/mailman/listinfo/pearg
> >
>
> --
> Pearg mailing list
> Pearg@irtf.org
> https://www.ir= tf.org/mailman/listinfo/pearg
>

--
Amelia Andersdotter

amelia.andersdotter.cc

--_000_BY5PR06MB6451000D6397DFE09F93BB26B16E0BY5PR06MB6451namp_-- From nobody Mon Jun 29 18:39:09 2020 Return-Path: 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 573503A0EFF for ; Mon, 29 Jun 2020 18:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=LYlwzhA+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HhhSnrkJ 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 cW7RpgY0ZAzL for ; Mon, 29 Jun 2020 18:39:06 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6956B3A0EFD for ; Mon, 29 Jun 2020 18:39:06 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9046F5C0140 for ; Mon, 29 Jun 2020 21:39:05 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Mon, 29 Jun 2020 21:39:05 -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; s=fm1; bh=YbmghMxmVCzVfjXcKpLygV8bVx6z0Vt Ev2OoPYmP8/k=; b=LYlwzhA+aCBshXVExwImNq2t7qy8KZEoevar2dKtToTDFad ZK2hgPGXyWUQwfUzjFCZIQVm6g5Y/Gg4D/76SbdDtHzrr+1vz1O66T3helRzdlai v5pZFptLM65UdlH7Is1VkDkmFcrVLXs7TZQRjrwnhpZl3u1hdiJr9A0DnAlg9orx mAlScJfghIB+XzYqo+T9WRxeIAFkIcEgjej63xYaplV1xgljqn8ZmZHTvqHz0J2+ +VHdBV8JdwuJMNqimccinpHhpgVHpjfjlNXnvMEhfDLhA02DFzbplUsbsdKCdQPM OUdvTxr37YhhyNtpWT77gewpNN53U6htHVDyfEQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; bh=YbmghM xmVCzVfjXcKpLygV8bVx6z0VtEv2OoPYmP8/k=; b=HhhSnrkJJzmQRZZGG6WMGG j5HdBCNG5jNYKDSq4gFOmmt2rNXwwiv0tQ+7zKoygOa0c/HG/4JkIqECilQ+lGOX FEVpnSJMCqLzSxkmpRdOMsa/qrEy4zcB596H7dO4jM6xUb2sy3+eI2hzlV3GZJnd 3y+uFYougsJRniwvtzarX17z7ECSamEuhnQAY125dC5PeG2F4Y/VHEsfH9z7v2fU hVmKg6imhaIdTpBxty+L9s6JW5XG1Rpzaj2zVy41qhcb/TiN/At4GaWh2UeWDq8n y6k3KDNkueCkqv5nYoO2HmH6VorQ6jn3Juj4UiGJD/kNZb/FJSCxhbe0u8rFhSEQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrvddttddghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucggtffrrghtthgvrhhnpeefgffgjeeghe evieegtdekudetuedvueelvedtueelveehtedvvedvheefvdelveenucffohhmrghinhep ihgvthhfrdhorhhgpdhirhhtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 25C923C00A1; Mon, 29 Jun 2020 21:39:05 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-576-gfe2cd66-fm-20200629.001-gfe2cd668 Mime-Version: 1.0 Message-Id: In-Reply-To: <081f4817-5635-7b74-d435-c33595cf045d@andersdotter.cc> References: <081f4817-5635-7b74-d435-c33595cf045d@andersdotter.cc> Date: Mon, 29 Jun 2020 18:38:44 -0700 From: "Christopher Wood" To: pearg@irtf.org Content-Type: text/plain Archived-At: Subject: Re: [Pearg] =?utf-8?q?agenda_request_for_Randomized_response_mechani?= =?utf-8?q?sms_in_round-trip_time_measurements?= X-BeenThere: pearg@irtf.org 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, 30 Jun 2020 01:39:08 -0000 Sounds good! We'll add you to the agenda. Best, Chris On Mon, Jun 29, 2020, at 1:46 PM, Amelia Andersdotter wrote: > Dear iedereen, > > Would like to request time on the PEARG agenda ahead of IETF 108 to > present a new version of > https://datatracker.ietf.org/doc/draft-andersdotter-rrm-for-rrt-in-http3/ > (to be created) > > best regards, > > Amelia > > -- > Pearg mailing list > Pearg@irtf.org > https://www.irtf.org/mailman/listinfo/pearg > From nobody Mon Jun 29 19:35:21 2020 Return-Path: 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 D3CDD3A0A09 for ; Mon, 29 Jun 2020 19:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=gmail.com 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 P9OLzhl3CBJ3 for ; Mon, 29 Jun 2020 19:35:18 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA4E63A0A04 for ; Mon, 29 Jun 2020 19:35:17 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id k6so18557742wrn.3 for ; Mon, 29 Jun 2020 19:35:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=elSe7rbRVD6j52v1dXFN9Erk1qzqxURb4uA3/ysuVzM=; b=PRFWyIB4BsEvQCjb0xV7OIafT9ovlFptaP9IjSiGZCy6oW1yQbqlTB1lJd4G546ph7 ExFwAk4GYnTq9krA22uMvnxCTHqpOTpd9jHw59qSL0hOV96Ue47Zp9xTu/MoPoTtB2kx neV5VVSSk4vwd6cJxgTEtTNBeY+W5qFyG7LL+rBqjaZRIMedJ3u2VyJ6AvC2i9VkWX+D spBW06fjPyn6UmGFPQ1dDtSE7MfDG7AlMZnKqtRXnk52SrenQm1jouGXLmkDNssjllu1 oXxCiLHj02RuEne3KPjgra+M5ZUHwhTwtLec9WVL8qfFP88NN8E2cjLiMEcYd6QHdCOx tgoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=elSe7rbRVD6j52v1dXFN9Erk1qzqxURb4uA3/ysuVzM=; b=B/eARSdioZLcQSUBflVoENzlxD6/Tvs8D0Jpk3ZR0+lOoz1yrU8TXsm50SZsr5gutL cfY9IIzCW7ObWwByNIfH7PsifPu9Hi5olhvI3KSG9P1BfF7DHhzqGaN/7iVB5yufdnbQ iTH/jLlgIGxSMLCn72SvWE5q5eFG2p5oLmlA3XjOAmZMRY+ntQtQUhdtFFcJqym2bmms DEozf+U9Y0vLrhv7z5xnY7mmA8g5spfvptfIcAZI+G6kF6Ccsi1eGBMXxxCCpFatwtHc F5Rm+wgH2AxCmSgUMOoZWQUfv5eKqQ3qVddRSHsAsMPL/+T23huqve0BeDEhiJROTFKz 5bWA== X-Gm-Message-State: AOAM53234b6pr2UzImN5zjry2eLuphtfOf6ZgDl+qvG1Nzsgt/VglXrv 6p4GI6BjV6s79rx4bz494w2xo0gO96ot2JkPNkmTfrZC X-Google-Smtp-Source: ABdhPJxmAiTfL7pn2b3h2ALVEGMZC8HYY8JL2KXm6B9ewnPRy4O3LDmBu8I+c7YxqhokUqFKbAq6lhSTp9tWgn2dTuk= X-Received: by 2002:a5d:6786:: with SMTP id v6mr19326022wru.258.1593484516081; Mon, 29 Jun 2020 19:35:16 -0700 (PDT) MIME-Version: 1.0 References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> In-Reply-To: From: Chelsea Komlo Date: Mon, 29 Jun 2020 20:35:04 -0600 Message-ID: To: amelia@andersdotter.cc Cc: Christopher Wood , pearg@irtf.org Content-Type: multipart/alternative; boundary="0000000000008942a005a94406cd" Archived-At: Subject: Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques" X-BeenThere: pearg@irtf.org 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, 30 Jun 2020 02:35:20 -0000 --0000000000008942a005a94406cd Content-Type: text/plain; charset="UTF-8" Hi Amelia, On Mon, Jun 29, 2020 at 3:37 PM Amelia Andersdotter wrote: > On 2020-06-02 16:30, Chelsea Komlo wrote: > > > > - One important point is that while China is an extremely powerful > > censor, they are often in a class of their own. I encourage including > > a discussion of something like "censor maturity" or the technical > > resources required to implement different techniques. There is a bit > > of this discussion, but it can be better standardized and applied to > > each technique. For example, IP blacklisting is trivial and does not > > require significant infrastructure (and many censors do this), but > > performing active probing to fingerprint protocols and block them on > > the fly requires much more infrastructure and planning (and is > > essentially only China, as I understand). > > > I'm hesitant about creating metrics that are specifically designed to > capture the behaviour of certain jurisdictions. In Sweden, it used to be > that the internet filtering industry was very strong and innovative. The > royal family and the Swedish EU Commissioner[2] were heavily involved in > advancing internet filters around the world. Now the Swedish local > actors are over-taken by US competitors on both the domestic and > European markets, for most part, but that's a question of scale and > resources more than anything else. Also I suppose once the ground-work > is there, it's easier to build on it - the cost goes down with time. > > But it made me think of something else too. Last year, I came across the > case where a South-East Asian country had bought Chinese infrastructure, > with government ministers in that country later telling the media that > they would be able to log into everyone's Facebook account and remove > posts without Facebook's active involvement or the involvement of the > user. I sincerely doubted at that time (and still doubt) that the > infrastructure deployed by this country could actually do that. Probably > the government ministers had misunderstood the technologies they > purchased, or wanted to over-sell its capacities with respect to the > population to make them more afraid than they needed to be of > repercussions. > > Thanks for the response. My suggestion might have been unclear, so I'll clarify. I don't think the document needs to give an overview of specific regions as they are today. However, I do think classifying censorship techniques by "how much effort it takes to implement" and "how much technical maturity is required of the censor" helps identify the most effective techniques to address, as opposed to techniques which are theoretically possible but not often deployed in reality. I'll give a heuristic example. Today, blocking based on IP address/domain is so easy and effective for a censor that more advanced techniques such as traffic fingerprinting are not necessary for governments to successfully censor content. What I have heard from practitioners is that there is little evidence that fingerprinting-based censorship is being used today at scale. As far as this document goes, it will be valuable to provide deeper classification of censorship techniques based on the cost/maturity for a censor to implement, to ensure that protocol designers don't target theoretically possible techniques while overlooking commonly deployed techniques in practice. Hope that addressed the above point. Chelsea -- Chelsea H. Komlo | chelseakomlo.com --0000000000008942a005a94406cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Amelia,

On Mon, Jun 29, 2020 at 3:37 PM= Amelia Andersdotter <amelia@andersdotter.cc> wrote:
On 2020-06-02 16:30, Chelsea Kom= lo wrote:
>
> - One important point is that while China is an extremely powerful
> censor, they are often in a class of their own. I encourage including<= br> > a discussion of something like "censor maturity" or the tech= nical
> resources required to implement different techniques. There is a bit > of this discussion, but it can be better standardized and applied to > each technique. For example, IP blacklisting is trivial and does not > require significant infrastructure (and many censors do this), but
> performing active probing to fingerprint protocols and block them on > the fly requires much more infrastructure and planning (and is
> essentially only China, as I understand).=C2=A0
>
I'm hesitant about creating metrics that are specifically designed to capture the behaviour of certain jurisdictions. In Sweden, it used to be that the internet filtering industry was very strong and innovative. The royal family and the Swedish EU Commissioner[2] were heavily involved in advancing internet filters around the world. Now the Swedish local
actors are over-taken by US competitors on both the domestic and
European markets, for most part, but that's a question of scale and
resources more than anything else. Also I suppose once the ground-work
is there, it's easier to build on it - the cost goes down with time.
But it made me think of something else too. Last year, I came across the case where a South-East Asian country had bought Chinese infrastructure, with government ministers in that country later telling the media that
they would be able to log into everyone's Facebook account and remove posts without Facebook's active involvement or the involvement of the user. I sincerely doubted at that time (and still doubt) that the
infrastructure deployed by this country could actually do that. Probably the government ministers had misunderstood the technologies they
purchased, or wanted to over-sell its capacities with respect to the
population to make them more afraid than they needed to be of
repercussions.=C2=A0


Thanks for the= response. My suggestion might have been unclear, so I'll clarify. I do= n't think the document needs to give an overview of specific regions as= they are today. However, I do think classifying censorship techniques by &= quot;how much effort it takes to implement" and "how much technic= al maturity is required of the censor" helps identify the most effecti= ve techniques to address, as opposed to techniques which are theoretically = possible but not often deployed in reality.=C2=A0

= I'll give a heuristic example. Today, blocking based on IP address/doma= in is so easy and effective for a censor that more advanced=C2=A0 technique= s such as traffic fingerprinting are not necessary for governments to succe= ssfully censor content. What I have heard from practitioners is that there = is little evidence that fingerprinting-based censorship is being used today= at scale.=C2=A0

As far as this document goes, it = will be valuable to provide deeper classification of censorship techniques = based on the cost/maturity for a censor to implement, to ensure that protoc= ol designers don't target theoretically possible techniques while overl= ooking commonly deployed techniques in practice.

H= ope that addressed the above point.
Chelsea
=C2=A0
--
<= div>
Chelsea H. Komlo | chelseakomlo.com
--0000000000008942a005a94406cd--