Re: [DNSOP] Client Validation - filtering validation?

Paul Wouters <paul@nohats.ca> Tue, 28 April 2020 13:38 UTC

Return-Path: <paul@nohats.ca>
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 256053A1535 for <dnsop@ietfa.amsl.com>; Tue, 28 Apr 2020 06:38:48 -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, 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 (1024-bit key) header.d=nohats.ca
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 6P8Q3pgqcPCE for <dnsop@ietfa.amsl.com>; Tue, 28 Apr 2020 06:38:46 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 793B83A1532 for <dnsop@ietf.org>; Tue, 28 Apr 2020 06:38:46 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49BN5d1Cf6zDDq; Tue, 28 Apr 2020 15:38:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1588081125; bh=7Ugq7sqE5PAbBg0SPs9criYI8ewud+w2c4bZtLlMyOM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=XaMPGZuUR+6xH2jqsT+ST1t4OJ1Ui/M1MD3tsaRB9hIa7nvv4dBZI/288dCH7xg/P K3rlMdQJOSNbEMFFc38dq9Q10tt/zt27uWVE9LVKcaKfRbpEc2Ds4gh0hmDVoLPV4D aMK2RHPra8bjVh2cSr/1W8dLg3qaYiKkUsUjMNWs=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id x_K3Ql9_csV0; Tue, 28 Apr 2020 15:38:44 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 28 Apr 2020 15:38:44 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 323E960009B6; Tue, 28 Apr 2020 09:38:43 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2E57923D186; Tue, 28 Apr 2020 09:38:43 -0400 (EDT)
Date: Tue, 28 Apr 2020 09:38:43 -0400
From: Paul Wouters <paul@nohats.ca>
To: Vittorio Bertola <vittorio.bertola=40open-xchange.com@dmarc.ietf.org>
cc: Brian Dickson <brian.peter.dickson@gmail.com>, "dnsop@ietf.org WG" <dnsop@ietf.org>
In-Reply-To: <843057379.5811.1588069262749@appsuite-gw2.open-xchange.com>
Message-ID: <alpine.LRH.2.21.2004280934590.18623@bofh.nohats.ca>
References: <CAHPuVdV9eSCLQOqMF0cq8fHcuSZs7nCgjhHMfMoaV5H=ekbtSA@mail.gmail.com> <CAHPuVdUh4UTP5pH_X83pm8OvY7juEotSYT6FLbVyE4_S-ev9Bg@mail.gmail.com> <71d22908-b0a9-5f0c-585e-0d10aa3edc8a@nic.cz> <2119709.gsHikbp680@linux-9daj> <CAH1iCiprfBNuMPWeraogqE9vR-UesZ_BWEzzeXQQGM1AZxipFw@mail.gmail.com> <843057379.5811.1588069262749@appsuite-gw2.open-xchange.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/46duzs4RZTCzSfQ7AdkqH7T7cO8>
Subject: Re: [DNSOP] Client Validation - filtering validation?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 28 Apr 2020 13:38:49 -0000

On Tue, 28 Apr 2020, Vittorio Bertola wrote:

> I've been thinking about whether/how a provider of filtering service (directly or indirectly) could be explicitly trusted to provide filtered
> "answers".

There is only one method where you can trust the filtering service. That
is that they offer you the filtered data in a neutralized fashion. I
have already been waiting a few years for the RPZ draft to pass the ISE
publication process so the IETF can work on the bis document that moves
the censored data into the authoritative section. That way, you get
all the data innoculated. Clients not supporting this will not see
this data and get filtered. Clients supporting this can talk to an
enduser if one is available to say their data was filtered and present
a choice on accepting the filter or not.

I have poked Paul Vixie and the ISE a number of times on the RPZ draft.
I even gave them another full review, but it seems nothing is happening
to move this draft forward.

If I hadn't been too busy, I would have already submitted a rpz bis
draft.

Paul