Re: [Pearg] I-D Action: draft-irtf-pearg-censorship-04.txt

Stephane Bortzmeyer <bortzmeyer@nic.fr> Tue, 21 July 2020 15:21 UTC

Return-Path: <bortzmeyer@nic.fr>
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 62A2B3A0A93 for <pearg@ietfa.amsl.com>; Tue, 21 Jul 2020 08:21:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9QQPG8tzWXDJ for <pearg@ietfa.amsl.com>; Tue, 21 Jul 2020 08:21:09 -0700 (PDT)
Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 3026D3A0A4A for <pearg@irtf.org>; Tue, 21 Jul 2020 08:21:07 -0700 (PDT)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 3CE872801BC; Tue, 21 Jul 2020 17:21:05 +0200 (CEST)
Received: by mx4.nic.fr (Postfix, from userid 500) id 366ED28051E; Tue, 21 Jul 2020 17:21:05 +0200 (CEST)
Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id 2EB812801BC; Tue, 21 Jul 2020 17:21:05 +0200 (CEST)
Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 23B8864C6C03; Tue, 21 Jul 2020 17:21:05 +0200 (CEST)
Received: by b12.nic.fr (Postfix, from userid 1000) id BA31546C6C; Tue, 21 Jul 2020 17:21:04 +0200 (CEST)
Date: Tue, 21 Jul 2020 17:21:04 +0200
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Joseph Lorenzo Hall <hall@isoc.org>
Cc: "pearg@irtf.org" <pearg@irtf.org>
Message-ID: <20200721152104.GA26448@nic.fr>
References: <159466596628.22724.642459259274073600@ietfa.amsl.com> <BY5PR06MB6451513C274911A1F5897F5CB1600@BY5PR06MB6451.namprd06.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BY5PR06MB6451513C274911A1F5897F5CB1600@BY5PR06MB6451.namprd06.prod.outlook.com>
X-Operating-System: Debian GNU/Linux 10.4
X-Kernel: Linux 4.19.0-9-amd64 x86_64
X-Charlie: Je suis Charlie
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Bogosity: No, tests=bogofilter, spamicity=0.033310, version=1.2.2
X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.11.5.63017
Archived-At: <https://mailarchive.ietf.org/arch/msg/pearg/XaStHULNjhEFXV6AlDysKgHWllw>
Subject: Re: [Pearg] I-D Action: draft-irtf-pearg-censorship-04.txt
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: Tue, 21 Jul 2020 15:21:11 -0000

On Mon, Jul 13, 2020 at 06:51:19PM +0000,
 Joseph Lorenzo Hall <hall@isoc.org> wrote 
 a message of 238 lines which said:

>         Title           : A Survey of Worldwide Censorship Techniques
>         Filename        : draft-irtf-pearg-censorship-04.txt

A general issue with drafts dealing with current techniques is that it
is hard to stay up-to-date (a reason to publish rapidly). 

For instance:

> For example, a censor could block the default HTTPS port, port 443,
> thereby forcing most users to fall back to HTTP.

Is it still true today? With HSTS (RFC 6797) and many Web sites
redirecting unconditionnaly from http: to https: I wonder if it could
still be used.

Also:

> When in-window sequencing is allowed, it is trivial to conduct a
> Blind RST Injection:

Trivial may be too strong, if RFC 5961 is used. Referring to RFC 5961,
section 5.1 may be a good idea (the draft mentions a fixed number of
possible windows, which does not seem true).

> while the term "blind" injection implies the censor doesn't know any
> sensitive (encrypted)

? "blind" refers to being off-path, it has nothing to do with
encryption.

> authoritative resolvers 

There is no such thing as an authoritative resolver. Either it is a
resolver, or it is an authoritative name server. (Source: RFC 8499,
section 6)

Editorial:

> This in-window recommendation is important, as if it is implemented
> it allows for successful Blind RST Injection attacks [Netsec-2011].

Not clear.

> [Bortzmayer-2015]
>              Bortzmayer, S., "DNS Censorship (DNS Lies) As Seen By RIPE
>              Atlas", 2015,

It's Bortzmeyer :-)

> [Zmijewski-2014]
>              Zmijewski, E., "Turkish Internet Censorship Takes a New
>              Turn", 2014, <http://www.renesys.com/2014/03/turkish-
>              internet-censorship/>.

Moved (without a redirect) with all the Renesys content, after being
bought by Oracle. It is now
<https://blogs.oracle.com/internetintelligence/turkish-internet-censorship-takes-a-new-turn>