Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

Paul Wouters <paul@nohats.ca> Wed, 21 December 2016 19:01 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 1035F1294BA for <dnsop@ietfa.amsl.com>; Wed, 21 Dec 2016 11:01:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.1
X-Spam-Level:
X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.1] 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 eyctR9lDphkM for <dnsop@ietfa.amsl.com>; Wed, 21 Dec 2016 11:01:31 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::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 DEC511294DA for <dnsop@ietf.org>; Wed, 21 Dec 2016 11:01:30 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tkPBw2xRCzG1V; Wed, 21 Dec 2016 20:01:28 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1482346888; bh=ZO41GhiPzCLzYCGeKtHeQG0wVlT2OElmWOWfpRZwy8c=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Wr3NtBqlkjGLMAZikDrYReGOJw1Yaqj253znbyCkc6uZ+b7xGcucPrlqNbKCI8B3v 3+7ScLjpzJ8SeD+qJRmJkwj06v/0QABGjjMPDOl1CU6otST2R2BFEW/+WOSAj8IuXc dJRQ4uyJKMZgOtFRn67M5sFk+8x0af58siNkvBKI=
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 xZ7cB_IZw6NX; Wed, 21 Dec 2016 20:01:25 +0100 (CET)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 21 Dec 2016 20:01:25 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 726AB91B; Wed, 21 Dec 2016 14:01:23 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 726AB91B
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6DDEC40BDBD5; Wed, 21 Dec 2016 14:01:23 -0500 (EST)
Date: Wed, 21 Dec 2016 14:01:23 -0500
From: Paul Wouters <paul@nohats.ca>
To: Vernon Schryver <vjs@rhyolite.com>
In-Reply-To: <201612211829.uBLITI5B085692@calcite.rhyolite.com>
Message-ID: <alpine.LRH.2.20.1612211343570.18385@bofh.nohats.ca>
References: <201612211829.uBLITI5B085692@calcite.rhyolite.com>
User-Agent: Alpine 2.20 (LRH 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/v_nw-x5sDrXYnmZYhP1aFLFhEu4>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 21 Dec 2016 19:01:33 -0000

On Wed, 21 Dec 2016, Vernon Schryver wrote:

> As I wrote on Monday, the final paragraph of section 6 on page 18 of
> https://tools.ietf.org/html/draft-vixie-dns-rpz-04
> says:
>
>  If a policy rule matches and results in a modified answer, then that
>  modified answer will include in its additional section the SOA RR of
>  the policy zone whose rule was used to generate the modified answer.
>  This SOA RR includes the name of the DNS RPZ and the serial number of
>  the policy data which was connected to the DNS control plane when the
>  answer was modified.
>
> It's not signed, but perhaps it could be with look-asside trust anchors,
> although an ever growing forest of DLVs doesn't sound good to me.
>
> Browsers and other interested applications would have to do more than
> gethostbyname() or a modern equivalent to see those SOAs.  But if
> browsers ever do any DANE, they'll need to do more than gethostbyname().
>
> (perhaps that "will include" should be "MUST include")

If the goal is to block the query, I think this is fine. I would prefer
a signed response of any kind as a marker we can keep to hold the
resolver operator accountable for their blocking actions.

If the goal is to block the answer, I think it would be much better to
move the original Answer RRTYPE into the Authority Section and use an
ENDS0 bit to signal RPZ was applied. That way, clients that understand
RPZ can see the censored results and do smart things - including ignoring
or accepting the censor - and clients that do not support understanding
RPZ will still be prevented from seeing the censored results for their
security.

Possibly an additional RRTYPE with a URL to a page explaining the
censorship would be useful to standarize as well. Having a "serial
number" of a policy is not very helpful for a user to hold an operator
responsible. It is important that we know the reason, as we've seen
many filter software doing things like filtering out the EFF or ACLU as
"porn site".

The important issue here is that DNS filtering is done for many valid
and invalid reasons. It is important that we give the consumers the
tools to see the difference. I'm fine with non-updated software/users
that cannot tell the difference to be blocked as-is for their
protection.

Paul