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

[Scott Schmit <[e-mail]>]

On Sun, Dec 18, 2016 at 07:59:44PM +0000, Tony Finch wrote:
> Scott Schmit wrote:
> > This doesn't magically make it possible for this DNS firewall to forge
> > DNSSEC-signed data, so if a validating end-system is going to have its
> > behavior modified, it would need to opt in.  
> 
> That's not entirely true. An RPZ setup can lie regardless of whether a
> client appears to be validating or not. If the admin's goal is to block
> access to malicious sites, then a validating client will get a bogus
> result or SERVFAIL, and the site will be blocked as intended.

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.

If the goal is to censor the Internet and keep the rebellion from
successfully gathering and planning their actions against the Galactic
Empire, then this scheme works perfectly because it works without
requiring end systems to be involved.  And it's much easier than
manually maintaining lists.  And cross-vendor, too, so it's easier to
manage the rules across organizations, companies, even country-wide.

With a redirect capability at that scale, a (mis)configuration could
also make it very easy to send DDoS attacks at particular sites.

> > But it looks like the contents of this zone are intended to be kept
> > secret from end-users. 
> 
> That depends entirely on the zone maintainer's policy. The admin can
> easily allow clients to query or transfer an RPZ, and/or provide out of
> band information about the zone on its web site.

If allowing the zone contents to be kept secret wasn't a goal of this
design, then it wouldn't be mentioned in the security considerations
twice.  It also wouldn't be a SHOULD that the list be access-controlled.

Sure, an admin isn't required to keep it secret, but it's absolutely
built into the design.

An out of band mechanism is no substitute, as it allows for
summarization or lying by omission:  "We are only blocking access to
criminal sites.  If you're having trouble, the problem must be you."
Meanwhile the filter also blocks legal-but-"subversive" organizations.

> > So this, if implemented, is ultimately a DNSSEC-killer.
> 
> I don't think so.

Even the draft admits in 12.2 that the "break-dnssec" configuration
setting is "common".  So let's admit that this draft considers
DNSSEC an obstacle to be overcome and that doing so will be typical.

> DNSSEC is not able to improve the availability of the DNS. The point of
> DNSSEC is to ensure that if you get an answer, you can be sure it is
> authentic. If your local network wants to prevent you from accessing a
> malicious site, DNSSEC can't stop them.

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?  What
are the negative effects of that we'd rather avoid?

-- 
Scott Schmit