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

Warren Kumari <warren@kumari.net> Sat, 31 December 2016 23:32 UTC

Return-Path: <warren@kumari.net>
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 3E2621295CD for <dnsop@ietfa.amsl.com>; Sat, 31 Dec 2016 15:32:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 k3N6UGf1x-zV for <dnsop@ietfa.amsl.com>; Sat, 31 Dec 2016 15:32:14 -0800 (PST)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 838F61295D5 for <dnsop@ietf.org>; Sat, 31 Dec 2016 15:32:14 -0800 (PST)
Received: by mail-qk0-x234.google.com with SMTP id n21so319805200qka.3 for <dnsop@ietf.org>; Sat, 31 Dec 2016 15:32:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=bx/2Lo3GG0GK1QUL/exLVWFJ/blF+0v9BlrOtcojJ7s=; b=vwUB18KQAeBPnDJq2/Qb3liqOY1yuDlRATUNfhZ8QVyzcVbsagii7CvU9Urgkg1anX +9SR1cGzHvzeiUeWn4hCBRMLiNe0S0SHDr0O6OXBQAtXLwVLcvXPxLqJmqZao2pgmXQJ muMOOMhJaL2GL85Iseg/cKCgcHgl9/dBbaO6g4diHVxuFblqycgjY2LQIEEDt+Bgf9Kb VqiuGkJ7Z+MNVcxRGtcLOoA58QZLSEUCvK6efIPiHUgeWVU+uud7pNZ9wpRU8CbHCqqV O+D4wjNbfaJFLnH0DwDGCSwrDOjwYeyabQqdEILgItalaYjaFC9ApR2pgDxVNZ5osMfS l9rQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=bx/2Lo3GG0GK1QUL/exLVWFJ/blF+0v9BlrOtcojJ7s=; b=NtZ2UsHUjLoVqrAkgXvuNPUasMiH/8FWv57d9eRHRh7u7Zdoi3M6RdaOvWGrHe3hyd YZbN0EBJ3NIVsljcEV7vdMrYxj94z83m0NmRemJ1yuZcQz6JDnfeYWjNRapPOxVNQv5c yP9VnvF8PaYrdRUe4vXf36l/VXGmJHfOwCbTO4++voETIaS31QdSdbZpw5CqGkk7xLRr BX+KPmHDXPexk0Oa9bs2rNeeX7Gj/VbTRg8WGwDfvimUOznJg2+vbgd6EGeOXAIYNFgq OBZ0zBr3fNINPU3+s31ynaCra16nlJBPDY0jWHl0jANIJDkxAGP9CLuMal0+6BjBV8uD ZJyQ==
X-Gm-Message-State: AIkVDXLCVield+aU8JEeMwUeMmE1ibRfrLW0PExIsv8a3Al/4c2dA/CfAB6fPbLV45T3cDai1lBu7a9ILolpqzBj
X-Received: by 10.55.132.4 with SMTP id g4mr48818747qkd.2.1483227132893; Sat, 31 Dec 2016 15:32:12 -0800 (PST)
MIME-Version: 1.0
References: <20161229040637.GA26031@odin.ulthar.us> <20161229054559.31443.qmail@ary.lan> <20161231202731.GX13486@mournblade.imrryr.org> <5932AEFF-E099-4175-A4FB-B1D7418028FF@fugue.com>
In-Reply-To: <5932AEFF-E099-4175-A4FB-B1D7418028FF@fugue.com>
From: Warren Kumari <warren@kumari.net>
Date: Sat, 31 Dec 2016 23:32:02 +0000
Message-ID: <CAHw9_iKgHLyD9u2jtUGwLu73yUGQQ7JSfXJw72V8pgyvmDw4jw@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c07639460b8e10544fcba38"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/vK_Knp6yqdNglM6hzyLnSSp5KW8>
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: Sat, 31 Dec 2016 23:32:16 -0000

On Sat, Dec 31, 2016 at 5:00 PM Ted Lemon <mellon@fugue.com> wrote:

> On Dec 31, 2016, at 3:27 PM, Viktor Dukhovni <ietf-dane@dukhovni.org>
> wrote:
>
> why is there a need to make it easier for outside forces
> to pressure providers to use such mechanisms to exert control over
> their users rather than protect them from harm?
>
>
> There is no _way_ to make it easier for said outside forces to pressure
> providers.   They have the force of law on their side.   What we do makes
> no difference in that arena.   The arena in which it _does_ make a
> difference is protecting people from losing their homes because they got
> suckered by some malware that got into their personal records on their
> computer.
>

Another arena in which we have some control is how well implemented and
interoperable the feature is -- if we document RPZ properly then,
regardless of why it is being deployed, at least it will behave
deterministically across implementations.

RPZ is already implemented in nameserver software -- if the feature exists,
I'd like it to work the same wherever it gets uses, and not cause
collateral damage...

W
P.S / full-disclosure: I happen to use RPZ, and have for a number of years
-- I run a number of (personal) mailing lists on my own mailserver, and use
a number of RPZ feeds (e.g Spamhaus' DBL) for spam mitigation.


>
> IOW, the argument you are presenting has nothing to do with the choice
> that faces us.   If you want to make the case for rpz being a bad thing,
> the argument you should be making would have to show why protecting people
> in this way is the wrong solution to the problem, and why some other
> solution to the problem (e.g., a blacklist in the browser) is less bad.
>
> Can’t we have that conversation, instead of these repeated assertions
> about things over which we have no control?
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>