Re: [DNSOP] draft-ietf-dnsop-structured-dns-error: suberr registration policy

Vittorio Bertola <vittorio.bertola@open-xchange.com> Fri, 21 April 2023 10:18 UTC

Return-Path: <vittorio.bertola@open-xchange.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9881C151709; Fri, 21 Apr 2023 03:18:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 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_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ix5qWBGkaecB; Fri, 21 Apr 2023 03:18:10 -0700 (PDT)
Received: from mx3.open-xchange.com (mx3.open-xchange.com [87.191.57.183]) (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 DCBC2C15155E; Fri, 21 Apr 2023 03:18:09 -0700 (PDT)
Received: from imap.open-xchange.com (imap.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPSA id 511F46A113; Fri, 21 Apr 2023 12:18:06 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1682072286; bh=1yB+O8Dt5JdQ+OnJdLqpFa4FiyQ9Nbg3kFnazPt2gyo=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=DrnD6Omj9RgG36wHhfihFXb+GhFGPuWrWlXUY2xXZTQi79c6vgfps0T4y8cJbai01 452bQE2oDGjKl8Ezm9HTJ8ts1B8C3ZSkjSl3rvVFHIlstg9sIO69/qgQbj3/dAMdsc uV1Bed4uG8lJ287NDzLrlUZDTzDOUx7s4CZ+BBvbVmO6PbGuQvtn0Dzn8hEBBgr+XY HJSlMrZHX7ZDGRKVHH0PJt3Qpf0Rt6axG7YgNts7MD5Sa0NU8kaUHUCjq5m1QhMbBs oS20/VIT6sgQ1fEhv55kZlH6LvrYzhPuv4GfHSXn2h4Cv9fmQH3vEFADLBoxBMcCZo rOS/g+63myiLQ==
Received: from appsuite-gw1.open-xchange.com ([10.20.28.81]) by imap.open-xchange.com with ESMTPSA id EO8uEt5iQmQxYyAA3c6Kzw (envelope-from <vittorio.bertola@open-xchange.com>); Fri, 21 Apr 2023 12:18:06 +0200
Date: Fri, 21 Apr 2023 12:18:06 +0200
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: Benjamin Schwartz <ietf@bemasc.net>, Ralf Weber <dns@fl1ger.de>
Cc: mohamed.boucadair@orange.com, dnsop <dnsop@ietf.org>, draft-ietf-dnsop-structured-dns-error@ietf.org
Message-ID: <877749052.51052.1682072286250@appsuite-gw1.open-xchange.com>
In-Reply-To: <CAJF-iTTWJq=8xOa+=tkQ2iXsYhttyPGGQNhaeZcq1EQVkE9Cxg@mail.gmail.com>
References: <4561_1680881181_6430361D_4561_496_1_cbba461734d74dbf8116d7f476960f88@orange.com> <CAJF-iTRHVS8asiaf-fvtWZqpNdzou4zEsb36roaK-S_HMAEX2g@mail.gmail.com> <9DFB9E73-1AB8-4B24-BC59-F6ADB4252B3A@fl1ger.de> <CAJF-iTTWJq=8xOa+=tkQ2iXsYhttyPGGQNhaeZcq1EQVkE9Cxg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_51050_1966667301.1682072286236"
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.6-Rev42
X-Originating-Client: open-xchange-appsuite
Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/B50yiHu7DZbadsbKJFh_CX0wGLs>
Subject: Re: [DNSOP] draft-ietf-dnsop-structured-dns-error: suberr registration policy
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Apr 2023 10:18:14 -0000

 

> Il 18/04/2023 15:54 CEST Benjamin Schwartz <ietf@bemasc.net> ha scritto:
>  
>  
>  
> 
> On Tue, Apr 18, 2023 at 7:49 AM Ralf Weber <dns@fl1ger.de mailto:dns@fl1ger.de> wrote:
> 
> > Moin!
> > 
> > On 18 Apr 2023, at 13:11, Benjamin Schwartz wrote:
> > 
> > > The draft's opening words are "DNS filtering is widely deployed for network
> > > security".  This is true, but by far the "widest" deployment of DNS
> > > filtering is for authoritarian national censorship, to prevent citizens
> > > from engaging with forbidden ideas.
> > 
> > Do you have any data to back this claim up?
> > 
>  
> According to Freedom House, 64% of Internet users "live in countries where political, social, or religious content was blocked", and "51% live in countries where access to social media platforms was temporarily or permanently restricted". (https://freedomhouse.org/report/freedom-net/2022/countering-authoritarian-overhaul-internet)  In my experience, DNS-based censorship is used for a majority of these blocks (often in concert with other methods).
> 
Ok, so now you just need to prove that that all those countries are "authoritarian" and that all blocking of social media or other content is "censorship". This really depends on the report's definition of "political, social or religious" - if a country blocks nazi or terrorist propaganda or CSAM or social fake news or the unauthorized streaming of movies, is that classified as "censorship of social and political content"? Many here would disagree, or at least find that censorship highly desirable.
 
But, more usefully: there is wide disagreement across the planet and even within the Internet community on what constitutes "censorship". I do not think that it is acceptable for the IETF to withhold standardization that is useful for those who provide filtering systems, and do so on policy grounds. Who ever gave the IETF the authority to decide whether country X or operator Y should be allowed to block certain types of content? Also, in practical terms, the real authoritarian countries won't bother anyway, but not having a way to provide meaningful information in reasonable filtering contexts (e.g. blocking illegal content in a European country) will just damage end users without reducing the extent of filtering in any way.
 
At the same time, your objections on how hard it is to agree on categorizations are valid. Of course any explanation of reasons for filtering that comes from a resolver should be taken at face value and at the same time presented as only worth as the trust one puts in one's resolver. Users are not required to believe or agree with the explanation, but it would still be useful for them to know it, especially in the many cases in which the filtering was actually requested by the user (e.g. parental controls). It may actually help them in evaluating the reliability of the service and choosing whether to continue using it or not.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com mailto:vittorio.bertola@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy