Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

Tony Finch <dot@dotat.at> Mon, 19 December 2016 11:01 UTC

Return-Path: <dot@dotat.at>
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 2174C129958 for <dnsop@ietfa.amsl.com>; Mon, 19 Dec 2016 03:01:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_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 LoTHjXvYRPXM for <dnsop@ietfa.amsl.com>; Mon, 19 Dec 2016 03:01:18 -0800 (PST)
Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) by ietfa.amsl.com (Postfix) with ESMTP id 3E61A12945D for <dnsop@ietf.org>; Mon, 19 Dec 2016 03:01:18 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:42733) by ppsw-33.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1cIvgx-0005aG-hz (Exim 4.86_36-e07b163) (return-path <dot@dotat.at>); Mon, 19 Dec 2016 11:01:15 +0000
Date: Mon, 19 Dec 2016 11:01:15 +0000
From: Tony Finch <dot@dotat.at>
To: Scott Schmit <i.grok@comcast.net>
In-Reply-To: <20161218224231.GB16301@odin.ulthar.us>
Message-ID: <alpine.DEB.2.11.1612191035220.14104@grey.csi.cam.ac.uk>
References: <148192523291.14691.3300133966679345337.idtracker@ietfa.amsl.com> <20161217184006.GB4916@odin.ULTHAR.us> <1482091184.4026817.822869193.1FAC8153@webmail.messagingengine.com> <20161218224231.GB16301@odin.ulthar.us>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Egpk-lIBPEvHXt5GwhV2U0CqFTc>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt
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, 19 Dec 2016 11:01:20 -0000

Scott Schmit <i.grok@comcast.net> wrote:
>
> If the admin's goal is to block access to malicious sites, then they
> want to block the traffic, not falsify DNS.  If the goal is to warn
> users away from bad places, they can publish the list as a filter for
> end-system firewalls.

Blocking traffic at a lower level is tricky. Blocking by IP address has a
high false-positive problem because of name-based virtual hosting.
Blocking by URL requires an intrusive middlebox. And if you deploy that
kind of blocking it is harder to give users an opt-out.

I agree it would be nice to be able to ship block lists to end-user
devices, but there's not much open technology to do that. AV software is
supposed to do this kind of thing but it's sufficiently ineffective that
security admins want centralized blocking to try to plug the holes.

Like most universities, we have a problem with fairly frequent targeted
phishing attacks (they re-skin their phishing site to look like our
single-sign-on login page) and services like Google Safe Browsing don't
catch these attacks fast enough, nor do they provide a way for us to
augment their list with our own blocklist.

> You make a good point.  Sounds like there's no need for the IETF to
> publish this as an RFC, since admins can already do this via other
> means.  What does this make easier that should be made easier?

The point of making this a standard is so that multiple suppliers can
supply policy zones in a standard format, and DNS software from multiple
vendors can consume these policy zones. From my point of view as an admin
at a site which doesn't have the resources to maintain our own
comprehensive block list, this is a boon.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Thames, Dover, Wight, Portland, Plymouth: Variable 3 or 4 becoming east or
northeast 4 or 5. Slight or moderate, becoming moderate or rough in Portland
and Plymouth and very rough later in southwest Plymouth. Drizzle, fog patches.
Moderate or good, occasionally very poor.