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

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 10 January 2017 04:30 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 E0D9C129E74 for <dnsop@ietfa.amsl.com>; Mon, 9 Jan 2017 20:30:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 8D4ajEAeXq07 for <dnsop@ietfa.amsl.com>; Mon, 9 Jan 2017 20:30:56 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A601C129E6F for <dnsop@ietf.org>; Mon, 9 Jan 2017 20:30:56 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8D7F6284E49; Tue, 10 Jan 2017 04:30:55 +0000 (UTC)
Date: Tue, 10 Jan 2017 04:30:55 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop@ietf.org
Message-ID: <20170110043055.GN13486@mournblade.imrryr.org>
References: <F1E2DDCD-6114-43A3-B9FB-831C3AC13F15@fugue.com> <201701091551.v09FpVif091631@calcite.rhyolite.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <201701091551.v09FpVif091631@calcite.rhyolite.com>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Vv6JiGXTPBj5eupvC8L2wrQTLVg>
Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: dnsop@ietf.org
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, 10 Jan 2017 04:30:58 -0000

On Mon, Jan 09, 2017 at 03:51:31PM +0000, Vernon Schryver wrote:

> Note that the vast majority of clients of RPZ rewriting resolvers are
> stubs that don't do validation

So far, and at present, correct.  Validating resolvers (unbound
and the like) are seeing deployment on servers first, including
some of the caches queried by said stubs.  (Far from representative
of course, My home OpenWRT router runs a validating unbound.)

> but trust header bits saying that a
> resolver operated by a third party did the validation.

But not this.  The stubs in question are generally security oblivious,
and don't in any sense "trust" that any validation happens upstream.

> I think that's
> wrong, evil, nasty, unethical, a Major Human Rights Issue, and blah
> de blah de blah, but it's also something no one seems willing and able
> to change.

And this part is both irrelevant, and IMHO inappropriately dismissive
of legitimate concerns expressed upstream.  We won't all agree,
but we should be held to a higher standard on the manner of the
discourse.

--
	Viktor.