IETF Logo Mail Archive

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

Paul Wouters <paul@nohats.ca> Mon, 09 January 2017 04:49 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 C6CBE1294B5 for <dnsop@ietfa.amsl.com>; Sun, 8 Jan 2017 20:49:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.799
X-Spam-Level:
X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.199] 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 CntYAJCuu4T9 for <dnsop@ietfa.amsl.com>; Sun, 8 Jan 2017 20:49:29 -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 813CB129440 for <dnsop@ietf.org>; Sun, 8 Jan 2017 20:49:27 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3txjNy5jx1z1rr; Mon, 9 Jan 2017 05:49:22 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1483937362; bh=Q4qTZchw/7mKWwLEdC6VsxaPeDxLdJ6tbKpwNdXUIvA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=VtfJU+H34g8Df1BFSopj6D4kmLX8/78JR7eBXM4z01NBWhuerod2QzHpn0JG1to44 Zx5/9iK2gSKuMDcYQbACGDuFTzEoksA6c7JZzgOXE37+EijOdlnnc8ObSW9OlXg4BL SwUwZC3Ih7ozUNRvNqz5OLEeIbtUMK9FcchVwIY0=
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 TMScBW0vY9UQ; Mon, 9 Jan 2017 05:49:21 +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; Mon, 9 Jan 2017 05:49:21 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1FDA6CA34B6; Sun, 8 Jan 2017 23:49:18 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 1FDA6CA34B6
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 045A940D7281; Sun, 8 Jan 2017 23:49:17 -0500 (EST)
Date: Sun, 08 Jan 2017 23:49:17 -0500
From: Paul Wouters <paul@nohats.ca>
To: Barry Raveendran Greene <bgreene@senki.org>
In-Reply-To: <7B87D311-5132-4D1D-9684-B09FE2CCA3B3@senki.org>
Message-ID: <alpine.LRH.2.20.1701082342250.18316@bofh.nohats.ca>
References: <20161229160603.GA10627@odin.ULTHAR.us> <20161229163826.34758.qmail@ary.lan> <20170107225456.GB10627@odin.ULTHAR.us> <7B87D311-5132-4D1D-9684-B09FE2CCA3B3@senki.org>
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/aXwDyWGsCLZngmPMFggq7GSke44>
Cc: dnsop <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: Mon, 09 Jan 2017 04:49:31 -0000

On Mon, 9 Jan 2017, Barry Raveendran Greene wrote:

>> On Jan 8, 2017, at 6:54 AM, Scott Schmit <i.grok@comcast.net> wrote:
>>
>> Eventually, if DNSSEC verification on endpoints becomes widespread,
>> operators will need to turn to other means or break DNSSEC in these
>> cases (but redirection will stop working).
>
> Bad guys are not going to take the time to use DNSSEC to build a path that can be followed to their place of operations.

It is actually the other way around. If an end-node performs DNSSEC
validation, it can only see RPZ modified answers as an attack. It is
in the interest of RPZ to give such clients the confidence that the RPZ
produced answer is not an attack but a handbreak action in the user's
interest.

I won't re-iterate my previous suggestion on how this could be done. See
the archive.

Paul

v2.14.0 | Report a Bug | By Email