Re: [DNSOP] Filtering and DNSSEC

Paul Wouters <paul@nohats.ca> Thu, 25 November 2021 23:36 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 26E7C3A0BC1; Thu, 25 Nov 2021 15:36:47 -0800 (PST)
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=unavailable 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 0YM-hI55jJML; Thu, 25 Nov 2021 15:36:42 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::85]) (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 8A38E3A0BD3; Thu, 25 Nov 2021 15:36:42 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4J0Z5Z6w5zzCw5; Fri, 26 Nov 2021 00:36:34 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1637883394; bh=Zf3tUncu3TKJFZZUFZHz3YV3QeXeyPqPKfFM3xW236g=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=luDrImsJFQnxyq3sMtb+CKEYdxELcgZ9ES2T8/la8Re+7RRqVVXrtBx7I2VsgXcwZ vIanlwJ+4HCO8occh3N75NKVQM/X5KDbIY1rzyUZk0bmh+XUpbw1B1mpkTgld5AW38 GYNyzuEbOIrYCcU4grkIvlxqNR64oKLHGhD+hWDE=
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 abBQfaZ5-9i5; Fri, 26 Nov 2021 00:36:33 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 26 Nov 2021 00:36:32 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 14CA317F588; Thu, 25 Nov 2021 18:36:32 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1161317F587; Thu, 25 Nov 2021 18:36:32 -0500 (EST)
Date: Thu, 25 Nov 2021 18:36:32 -0500
From: Paul Wouters <paul@nohats.ca>
To: Paul Vixie <paul=40redbarn.org@dmarc.ietf.org>
cc: DNSOP WG <dnsop@ietf.org>, draft-wing-dnsop-structured-dns-error-page@ietf.org
In-Reply-To: <34afe362-24b9-789e-ff25-22882f689ef7@redbarn.org>
Message-ID: <98755a3d-c8b-ff30-e377-c8b55ce63cd0@nohats.ca>
References: <4dc9b976-cc1c-d0a6-0352-06db19e42068@nic.cz> <D9B13846-F7B3-4402-9363-8E8036F0E4B2@nohats.ca> <34afe362-24b9-789e-ff25-22882f689ef7@redbarn.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/wbB6vqX21HDH8c_rTQl9tJcYwxI>
Subject: Re: [DNSOP] Filtering and DNSSEC
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: Thu, 25 Nov 2021 23:36:47 -0000

On Thu, 25 Nov 2021, Paul Vixie wrote:

> in the years since DNS RPZ was made, i've realized that authoritarian network 
> operators including authoritarian national governments are not well served by 
> DNS RPZ in its current form. what we (and they) need is a way to include the 
> original answer and also a server-level signature on the policy-trampled 
> answer. this way we (and they) can watch what the stub does next -- which 
> answer it consumes -- and therefore know whether the policy (or the law) is 
> being abrogated, so as to trigger an enforcement action.

This is deeply concerning statement, even if you are trying to convince
the authoritarians that they should let the DNS answer slide through
"in their best interest".

In fact, a much better answer here would be to develop a DNS protocol
that would prevent those kind of authoritarian network operators to
get any visiblity at all in what their citizens are doing. Luckily,
there is a good protocol for that, DoH. I hope it sees widespread use
over too many hostnames to track and block.

> probably this just means packing the original answer and the policy signature 
> into EDNS in some way. but the response itself will have to have the 
> policy-trampled answer and rcode (likely NXDOMAIN but not always.)

This has a similar effect as moving the RRs from Answer to Authority
section, and sure has a little better signaling support although if
this is not coming directly from the application, they might not see
the EDNS option either. So sadly this would be a reason to move DNS
into applications, something which I wish we could stop doing.