Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques"

"S. Moonesamy" <sm+sdo@afrinic.net> Wed, 01 July 2020 22:16 UTC

Return-Path: <sm@afrinic.net>
X-Original-To: pearg@ietfa.amsl.com
Delivered-To: pearg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54F53A0E3B for <pearg@ietfa.amsl.com>; Wed, 1 Jul 2020 15:16:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5edkaFSHoj0a for <pearg@ietfa.amsl.com>; Wed, 1 Jul 2020 15:16:31 -0700 (PDT)
Received: from board.afrinic.net (board.afrinic.net [IPv6:2001:42d0:0:404::83]) (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 68FF53A0E37 for <pearg@irtf.org>; Wed, 1 Jul 2020 15:16:29 -0700 (PDT)
Received: from [102.115.171.75] (port=56181 helo=DESKTOP-K6V9C2L.afrinic.net) by board.afrinic.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from <sm@afrinic.net>) id 1jql1i-0002F0-WF; Thu, 02 Jul 2020 02:16:23 +0400
Message-Id: <6.2.5.6.2.20200701121525.0adc6978@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 01 Jul 2020 15:14:10 -0700
To: Joseph Lorenzo Hall <hall@isoc.org>, pearg@irtf.org
From: "S. Moonesamy" <sm+sdo@afrinic.net>
In-Reply-To: <44321D58-F56E-47E2-94BF-ED1B7ECA56A7@isoc.org>
References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <3eba505f-8e85-472c-b22a-660c6ec697c1@www.fastmail.com> <BY5PR06MB6451CAEC5B1CF4FC2C32432EB1860@BY5PR06MB6451.namprd06.prod.outlook.com> <3ed2d30b-9a8d-432f-273e-f2ca183f0f22@andersdotter.cc> <BY5PR06MB6451000D6397DFE09F93BB26B16E0@BY5PR06MB6451.namprd06.prod.outlook.com> <6.2.5.6.2.20200701055337.0d575238@elandnews.com> <6.2.5.6.2.20200701113215.0bf66010@elandnews.com> <44321D58-F56E-47E2-94BF-ED1B7ECA56A7@isoc.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/pearg/9nXPOCSe76oBPs3PoRw-WSVC5E8>
X-Mailman-Approved-At: Wed, 01 Jul 2020 15:17:48 -0700
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 <pearg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/pearg>, <mailto:pearg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pearg/>
List-Post: <mailto:pearg@irtf.org>
List-Help: <mailto:pearg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/pearg>, <mailto:pearg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2020 22:16:34 -0000

Dear Joseph,
At 11:59 AM 01-07-2020, Joseph Lorenzo Hall wrote:
>I think what the wording of the draft is trying 
>to do there is to point out that if you can 
>compel a signed route, ASs will tend to start 
>sending traffic that direction, potentially 
>compromising the confidentiality and integrity 
>of the traffic, not the ROA. I'm happy to make 
>that clear. Also, feel free to push back and say 
>that it's out of place… this ppart is trying to 
>catalog entities in positions of power that 
>could affect the ability of two ends to communicate.

I'll explain what I understood.  Please do 
correct me if you or anyone believes that it is 
incorrect:  The Introduction section states that 
the document describes technical mechanisms that 
censorship regimes around the world use for 
blocking or impairing Internet traffic.  In my 
opinion, the reader would expect that the points 
of control (Section 3.1) are/were used for impairing Internet traffic.

Section 3 is about the identification of 
"technical" points of control.  One of the 
examples given is that of a Regional Internet 
Registry which issues a Route Origination 
Authorization when it is requested to do so by 
one of the members of the Registry.  The argument 
is that the Registry can be compelled by law to 
issue a Route Origination Authorization which is 
not compliant with its practices.  The traffic 
for the "prefix" would then be redirected to another entity.

Given the above, the two ends would not 
communicate as expected (there are RFCs which 
discuss end-to-end).  Would that happen without a 
Route Origination Authorization?

The example at the end of the paragraph about 
"Certificate Authorities" mentions "TLS 
interception".  Wouldn't that be detected when 
the certificate is verified by the receiving side?

I suggest reviewing the issue which you described 
and the text instead of saying that the text is out of place.

Regards,
S. Moonesamy