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

"Ralf Weber" <dns@fl1ger.de> Tue, 10 January 2017 14:56 UTC

Return-Path: <dns@fl1ger.de>
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 19BDC1294F9 for <dnsop@ietfa.amsl.com>; Tue, 10 Jan 2017 06:56:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 bsb9obCjup4J for <dnsop@ietfa.amsl.com>; Tue, 10 Jan 2017 06:55:59 -0800 (PST)
Received: from smtp.guxx.net (nyx.guxx.net [85.10.208.173]) by ietfa.amsl.com (Postfix) with ESMTP id E66FD1294FE for <dnsop@ietf.org>; Tue, 10 Jan 2017 06:55:58 -0800 (PST)
Received: by nyx.guxx.net (Postfix, from userid 107) id ABD965F4081B; Tue, 10 Jan 2017 15:55:57 +0100 (CET)
Received: from [192.168.2.129] (p57B9E1B8.dip0.t-ipconnect.de [87.185.225.184]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 0CEC65F402E9; Tue, 10 Jan 2017 15:55:56 +0100 (CET)
From: "Ralf Weber" <dns@fl1ger.de>
To: "Scott Schmit" <i.grok@comcast.net>
Date: Tue, 10 Jan 2017 15:55:55 +0100
Message-ID: <115D5265-B9C0-49D9-9257-7BBFC0535DFB@fl1ger.de>
In-Reply-To: <20170107225456.GB10627@odin.ULTHAR.us>
References: <20161229160603.GA10627@odin.ULTHAR.us> <20161229163826.34758.qmail@ary.lan> <20170107225456.GB10627@odin.ULTHAR.us>
MIME-Version: 1.0
X-Mailer: MailMate (1.9.6r5319)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ALCCoUp6bgCSJUUNNChkk0Mdjo4>
Cc: dnsop@ietf.org, John Levine <johnl@taugh.com>
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: Tue, 10 Jan 2017 14:56:00 -0000

Moin!

On 7 Jan 2017, at 23:54, Scott Schmit wrote:
>>>> why you think hostile actors will do things with RPZ that they
>>>> couldn't do now?
>
> For the very reasons that the authors want to make this an RFC -- RPZ
> isn't interoperable between DNS resolvers today.  Once this RFC is
> published, it's clearly hoped that RPZ will be more interoperable and
> thus widespread.
>
> It's true that countries can legislate anything they want, and the
> publication (or not) of an RFC won't change that.
>
> But the enforcement of laws costs resources, and resources are finite --
> so a country passing laws requiring network operators to filter and/or
> redirect will have no choice but to prioritize enforcement of such laws
> against other needs.
I don't know if you ever where involved in law creation, but I can assure
you, being involved in lobbying lawmakers to make sensible laws and also
implementing redirection via DNS which is common in a lot of countries,
that lawmakers give a damn about how much it costs providers to
implement the redirection.

When implementing redirection via DNS I've seen every sort of possible
input thrown at me from snail mail to EBDIC text files, pdf, you name
it. The funniest case was one country that had different branches of
the government issuing block lists one with a word document over ftp
and the other with XML over https. I would love to have had a common
format then and not re-invent the wheel on every new case.

BTW all of these implementations where in what one would consider
democratic countries in Europe (The nice thing about the EU is even
if you have a EU directive you still get 27 different laws to follow
if you are a pan european provider ;-). My point here is if you don't
like redirection and blocking via DNS (which IMHO is much better than
mandating DPI - unless you are a DPI vendor ;-) get involved in
politics and try to change that at OSI layer 9.

None of the stuff we discuss here will change any law or mandated
redirection, nor will it change the efforts of lots of sysadmins and
security researchers using the discussed technology to block bonnets
and bad guys to not infect subscribers.

It just would be nice if these poor sysadmins had some common tools,
but as said we've solved problems without that until now and as others
said RPZ actually might not be the best tool to express DNS policy
configuration, but given the current state of the discussion I have
serious doubt that the working group would consider working on that
at all.

So long
-Ralf