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

From: [email-masked]
Date: Fri, 16 Dec 2016 13:53:52 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.

        Title           : DNS Response Policy Zones (RPZ)
        Authors         : Paul Vixie
                          Vernon Schryver
	Filename        : draft-vixie-dns-rpz-04.txt
	Pages           : 30
	Date            : 2016-12-16

Abstract:
   This document describes a method for expressing DNS response policy
   inside a specially constructed DNS zone, and for recursive name
   servers to use such policy to return modified results to DNS clients.
   The modified DNS results can stop access to selected HTTP servers,
   redirect users to "walled gardens", block objectionable email, and
   otherwise defend against attack.  These "DNS Firewalls" are widely
   used in fighting Internet crime and abuse.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-vixie-dns-rpz/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-vixie-dns-rpz-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-vixie-dns-rpz-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: ac <[email-masked]>
Date: Sat, 17 Dec 2016 07:37:44 +0200

and so we all go down the slippery slope.

On Fri, 16 Dec 2016 13:53:52 -0800
[email-masked] wrote:

> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Domain Name System
> Operations of the IETF.
> 
>    servers to use such policy to return modified results to DNS
> clients. The modified DNS results can stop access to selected HTTP
> servers, redirect users to "walled gardens", block objectionable
> email, and otherwise defend against attack.  These "DNS Firewalls"
> are widely used in fighting Internet crime and abuse.
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Ted Lemon <[email-masked]>
Date: Sat, 17 Dec 2016 08:05:36 -0500

We are already zooming down it at full speed. The night is dark and full of
ice weasels.

---

From: ac <[email-masked]>
Date: Sat, 17 Dec 2016 19:18:52 +0200

On Sat, 17 Dec 2016 08:05:36 -0500
Ted Lemon <[email-masked]> wrote:
> We are already zooming down it at full speed. The night is dark and
> full of ice weasels.
> 

that is only your point of view, take of your sunglasses, it is bright

outside, we are Making The Internet Great Again, writing protocols to

tell lies, moving lines, exploring the dark side of the force, a new

time is upon us, where toasters also make ice and ice and tell time.

you are right about the speed though, must be the wind in your hair?

> > >    This document describes a method for expressing DNS response
> > > policy inside a specially constructed DNS zone, and for recursive
> > > name servers to use such policy to return modified results to DNS

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 17 Dec 2016 18:27:51 GMT

> From: ac <[email-masked]>

> you are right about the speed though, must be the wind in your hair?

The Internet stopped at the bottom of this particular slope years ago.
The idea of dishonest DNS servers is at least 25 years old, although
almost all such talk avoids words like "lie" and "truth."  As you can
see from the History section on page 23 of
https://datatracker.ietf.org/doc/draft-vixie-dns-rpz/?include_text=1
RPZ has been available in BIND9 for half a dozen years.  There are
also RPZ implementations or partial implementations in or for BIND9,
Unbound, Powerdns, Knot, and probably other recursive server
implementations.
(I'd be happy to relay descriptions of other RPZ code to the editor
of https://dnsrpz.info/ or introduce people to him. )

The new version of RPZ draft is longer, but it might finally completely
describe RPZ.  Previous descriptions lacked significant details about
how a single effective policy rule is chosen among multiple hits and
about less common (but I think more effective) types of triggers
including NSIP and NSDNAME.

Comments on the 04 draft (other than marking it Top Secret) are welcome.

Vernon Schryver    [email-masked]

---

From: Scott Schmit <[email-masked]>
Date: Sat, 17 Dec 2016 13:40:06 -0500

>    used in fighting Internet crime and abuse.

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.  (Whatever that means if
it's legally required to participate.)

But it looks like the contents of this zone are intended to be kept
secret from end-users.  The option to use other recursive resolvers
provided in 12.1 ignores that access to them could be blocked.

I could imagine a world in which the response to this draft is to
accelerate DNSSEC deployment [maybe optimistic]. That would highlight
where this is being used, since only affected domains would have their
lookups broken.  The natural counter to that would be to deliberately
break DNSSEC everywhere to blind end-users to where they're being lied
to.

So this, if implemented, is ultimately a DNSSEC-killer.

-- 
Scott Schmit

---

From: ac <[email-masked]>
Date: Sun, 18 Dec 2016 06:56:47 +0200

On Sat, 17 Dec 2016 18:27:51 GMT
Vernon Schryver <[email-masked]> wrote:
> > From: ac <[email-masked]>
> > that is only your point of view, take of your sunglasses, it is
> > bright outside, we are Making The Internet Great Again, writing
> > protocols to tell lies, moving lines, exploring the dark side of
> > the force, a new time is upon us, where toasters also make ice and
> > ice and tell time. you are right about the speed though, must be
> > the wind in your hair?

in 2017 if we do not start talking about "truth" and "lies" we will
end up where we are going.

And, objectively, This (RPZ) does more evil than it does good.

And, it is morally objectionable to enable evil. As with all evil, this
also hides the truth from it's own users

anyway, the discussion is about having the stones to actually ask
for comments on making protocols to tell lies and it not being
morally objectionable to do that (because of the Vixie name, whom the
majority respect (and some are in awe of) )

but, simply because i respect someone, it does not make it okay when
they tell me that it is okay to rob the corner liquor store, as I know
it is not.

there are many good arguments for and against (RPZ)

But the ethics of this protocol is fatally flawed.

The community should take note, sit up straight and drive the accelerated adoption of DNSSEC deployment

Maybe that is why you are driving this, Vernon? not because you are
short sighted, or ethically challenged, but because you are secretly a
decent, honest, fair human being and this is your contribution to
galvanize action on DNSSEC deployment?

Andre

---

From: Tony Finch <[email-masked]>
Date: Sun, 18 Dec 2016 19:59:44 +0000

Scott Schmit <[email-masked]> wrote:

> 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.

> 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.

> So this, if implemented, is ultimately a DNSSEC-killer.

I don't think so.

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.

Tony.

--

f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--
  zr8h punycode

---

From: Scott Schmit <[email-masked]>
Date: Sun, 18 Dec 2016 17:42:31 -0500

On Sun, Dec 18, 2016 at 07:59:44PM +0000, Tony Finch wrote:
> Scott Schmit 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.

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.

> 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.

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.

> 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

---

From: "Adrien de Croy" <[email-masked]>
Date: Sun, 18 Dec 2016 23:45:34 +0000

> users away from bad places, they can publish the list as a filter for

That may be your view about how blocking should work, but a lot of 
companies are using systems like OpenDNS who would beg to differ with 
you.

In terms of many of the metrics admins like such as simplicity, 
effectiveness, cost etc, then spoofing DNS comes out very favourably.

---

From: ac <[email-masked]>
Date: Mon, 19 Dec 2016 07:05:24 +0200

On Sun, 18 Dec 2016 23:45:34 +0000
"Adrien de Croy" <[email-masked]> 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.

DNS admins also have a  fiduciary responsibility to their users. 

Other services also have implied fiduciary responsibility, like email,
but DNS is a direct service - Your user is asking you, right now, for a
fact, not a best guess. Your user is asking you : What are the
operators of my bank saying their IP number is. 

While I am saying things that nobody is saying out loud, (I may as
well continue down my own slippery slope...) DNS admins are 
more important than other admins. DNS admins must be more sensitive to
their own ethics, their own truth. 

When it is presented as "okay" or "normal" to create protocols for
telling lies,  AND hiding those lies from their users, this is an indication 
that a lack of understanding exists about how important it is to meet
the high trust expectations the world has, on DNS. 

Many arguments could be made why it is a good thing to "protect" users
by using DNS and many arguments could be made why using DNS is
completely wrong for this.

My objection to the continued publication of the subject matter in this draft, is not that.

My objection is that it is simply not ethical.

It is simply not right.

Andre

---

From: "Ralf Weber" <[email-masked]>
Date: Mon, 19 Dec 2016 07:53:42 +0100

Moin!

> operators of my bank saying their IP number is.
So if this is the IP of a phishing site or the IP of an command and
control host that tells its bot to execute criminal action you still
valid the accuracy of the answer higher then possible damage this
could do to your user?

I don't and I've been using similar techniques either as employee of
a DNS operator or a DNS software vendor for 10 years now.

Local policy, which this is, always trumped validation and in the end
user can validate and find out that this answer doesn't validate
and then can try to find out why, but honestly most internet users
have no idea what DNS let alone DNSSEC is or how to deal with it.

Protecting Internet users with DNS by not letting them go to these
sites seems like a good idea to me and is also done by e.g browser
vendors (have you complained to them ;-).

Sure this technology can be used to bad things, but that is true
for a lot of other technologies also. It's the use that makes them
bad and not the technology itself.

So long
-Ralf

---

From: ac <[email-masked]>
Date: Mon, 19 Dec 2016 09:28:54 +0200

On Mon, 19 Dec 2016 07:53:42 +0100
> Moin!
Aloha

<snip>
> > Other services also have implied fiduciary responsibility, like
> > email, but DNS is a direct service - Your user is asking you, right
> > now, for a fact, not a best guess. Your user is asking you : What
> > are the operators of my bank saying their IP number is.
yes. 

In your example, ethically, it is a problem that should be addressed on IP, not on DNS

It is never okay to tell lies.

and then to add deception to the already ethically flawed approach
offends.  

> bad and not the technology itself.

this is exactly the same argument the authors of other software uses
and also argues for the use of DNS as a firewall, etc.

and you are of course correct: you are free to develop malware, write virus and do anything your heart
desires. It is your DNS servers, you may do anything you like and
answer anything you want.

but, to publish protocols and request comments on how to operate a
botnet or do whatever you wish to do that is not ethical, is crossing a line.

To legitimize the telling of lies and to define protocols that hides
the truth from users, (deception) for whatever reason, is wrong.

My argument is extremely simple to counter, I am saying one word:

dishonesty

I assume you are saying that it is okay to lie, cheat (and steal?) if
the reason you are doing it is well intended? - Please correct me if I
am wrong?

I am saying that it is never okay to lie, steal, cheat, deceive, etc.

maybe we can talk about that? Ethics? - Do DNS admins have other ethics
than those of normal people? Are DNS admins special? may they decide to
be the Internet Executioners and is it okay for DNS Admins to lie, cheat or steal?

> So long
or short, depending on your POV :)

Andre

---

From: [email-masked]
Date: Mon, 19 Dec 2016 09:16:28 +0100 (CET)

> It is never okay to tell lies.

Unfortunately the real world isn't that simple.

Sometimes you are required by law to tell lies. Case in point: Various
domains belonging to Pirate Bay and several other torrent providers
have been explicitly blocked in Norway - explicitly as in: The biggest
ISPs in Norway (I happen to work for one of these) have been told by
the Oslo district court to block access to a list of domains supplied
by the court, and that this is to be implemented through DNS blocking
(lies, if you will).

It doesn't matter whether I *like* this or not, and it also doesn't
matter whether the domains in question are easily available by using
OpenDNS, Google Public DNS, running your own name server, etc. ISPs
are still required to block access as long as the verdict from the
Oslo district court is valid.

Today this blocking is done without using RPZ. Having RPZ standardized
and implemented in more DNS software would make it possible to perform
the same blocking as mentioned above with fewer moving parts and thus
a simpler system less likely to have "interesting" failure modes.

Note that it makes absolutely no difference to the blocking described
above whether the RPZ draft is published as an RFC or not - in both
cases the blocking would still be performed, because it is required
by law.

Steinar Haug, AS2116

---

From: ac <[email-masked]>
Date: Mon, 19 Dec 2016 10:39:55 +0200

On Mon, 19 Dec 2016 09:16:28 +0100 (CET)
[email-masked] wrote:
> > > So if this is the IP of a phishing site or the IP of an command
> > > and control host that tells its bot to execute criminal action
> > > you still valid the accuracy of the answer higher then possible
> > > damage this could do to your user?
> > yes. 
it actually is.

> Sometimes you are required by law to tell lies. Case in point: Various

it still is never okay to lie and to deceive.

If the law requires you to answer example.com as ipv4 xxx.xxx.xxx.xxx

The law does not say : send "Pirate Bay" to "example.com" to deceive
your users! it may instruct you to send coca-cola.org to coca-cola.com

but I am not aware of any court (on the planet?) that instructs people
to lie, cheat, steal or deceive - maybe in the interests of national
security, etc. - but arguing that is like pulling the dam from underneath the duck.

 so, factually, the law is not instructing you to lie or to deceive.

the law is saying: do not resolve "pirate bay" or lie to your users or
deceive your users!

Why would you say (or think that?)

your reply is not addressing dishonesty at all?

This is a simply  about ethics. 

dishonesty

---

From: ac <[email-masked]>
Date: Mon, 19 Dec 2016 10:42:35 +0200

it actually is.

This is simply  about ethics. 

is it okay to be dishonest, to deceive and where is the ethical line

More specifically: When do you become me - when there is an RFC to
describe methods to steal? - i.e more direct than fraud?

Andre

<snip - left for context>
/*
> cases the blocking would still be performed, because it is required

*/

---

From: Evan Hunt <[email-masked]>
Date: Mon, 19 Dec 2016 09:09:42 +0000

On Mon, Dec 19, 2016 at 10:42:35AM +0200, ac wrote:
> [...]

I hereby, with full knowledge and prior consent, give my resolver (which
I own) *permission* to falsely tell my browser (which I also own) that
malware domains don't exist.

The ethical conundrum having been resolved, we can now carry on with
documenting the mechanism I used to tell my resolver to do this.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: bert hubert <[email-masked]>
Date: Mon, 19 Dec 2016 10:13:22 +0100

> documenting the mechanism I used to tell my resolver to do this.

For the record, I have just told my resolver the same thing. My ethics
problem is also resolved. And let us now get on with documenting the
mechanism by which I told my resolver to do this.

My resolver also strips out IPv6 addresses for various services because they
get geolocation wrong. The lies improve my life.

	Bert
	PowerDNS

---

From: "Ralf Weber" <[email-masked]>
Date: Mon, 19 Dec 2016 11:05:45 +0100

Moin!

> In your example, ethically, it is a problem that should be addressed 
So you are arguing for DPI inspection of all packets? That would be not
what I want, but if you think this is more ethical go ahead.

> and also argues for the use of DNS as a firewall, etc.
Yes and I work for a company that produces such software, so what?

> answer anything you want.
Well I don't run DNS servers these days, but that's what I did when I
ran them some time ago and I prevented a lot of bad activity on the
network by doing so.

> botnet or do whatever you wish to do that is not ethical, is crossing 
Sorry you lost me there. This draft is describing a mechanism how to
block/redirect stuff in DNS. I don't see how you could run a botnet
with it and I know some stuff on bonnets that use DNS.

This draft just uses a DNS zone file format to achieve this blocking/
redirection. While this may not be the best way to encode policy, it
seems to be the one lots of DNS people can agree on.

> the reason you are doing it is well intended? - Please correct me if I
I never said such a thing and while I know it is common these days to
accuse people with different opinions as liars or non ethical it is just
that a different opinion. And while I usually hate metaphors let's try
one here. Say if I work on an information counter and you ask me how
to get to a part of town where you are likely to get robbed or shot,
should I just tell you the way or is it more ethical to warn you.

> be the Internet Executioners and is it okay for DNS Admins to lie, 
A lot of people I trust and respect work in that area and run DNS
resolvers that block/redirect DNS for various reasons: services (yes
there are DNS services where the users request to be redirected),
trojan/malware protection, court orders, etc. Calling them non
ethical IMHO is an insult. Humans are not black (0) and white (1),
the come in more shades and colours.

Other than that +1 to what Evan said (slightly modified):

"I hereby, with full knowledge and prior consent, give my resolver 
(which
I own) *permission* to falsely tell my browser (which I also own) that
malware domains don't exist.

The ethical conundrum having been resolved, we can now carry on with
documenting the mechanism some resolvers use."

So long
-Ralf

---

From: Tony Finch <[email-masked]>
Date: Mon, 19 Dec 2016 10:59:57 +0000

> the truth from users, (deception) for whatever reason, is wrong.

I agree.

That is why, if you are deploying RPZ, you should do so in an ethical
manner. When someone connects to your network, you have an AUP or
something similar which informs them about how you run your network.

And when a site is blocked, you do your best to inform your users about
why it was blocked, who is responsible for the blocking, how they can
correct erroneous blocks, how they can opt out of blocking, and so forth.

This is independent of the technology you use to implement the blocking.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Trafalgar: Northeasterly, backing northerly later, 4 or 5, increasing 6 at
times. Moderate or rough becoming rough or very rough. Rain or showers.
Moderate or good.

---

From: Tony Finch <[email-masked]>
Date: Mon, 19 Dec 2016 11:01:15 +0000

> users away from bad places, they can publish the list as a filter for

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.

> 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  <[email-masked]>  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.

---

From: ac <[email-masked]>
Date: Mon, 19 Dec 2016 13:22:47 +0200

On Mon, 19 Dec 2016 10:59:57 +0000
Tony Finch <[email-masked]> wrote:
> And when a site is blocked, you do your best to inform your users
> about why it was blocked, who is responsible for the blocking, how
> they can correct erroneous blocks, how they can opt out of blocking,
> and so forth. 

I agree with what you said as well, as it is my own network, my
infrastructure and, thanks to open source (community) even my own 
software

So I am in 100% agreement with you

but, additionally

I do object to a request for comment that ignores ethics.

For example, should RFC 2588/2979/7288/3511 etc etc describe a method
to re-direct a request for x to y and to abstruse the results non
transparently to x AND to hide that - I would have the same objections.

It is also not just an issue of changing the draft, in this thread I realized that 
my own previous c'est la vie, is not what I should aspire to and for
myself it is morally wrong to just go with the flow.

It is really never okay to tell lies. More so, it is never okay to
deceive and it is just wrong to 'normalize' this by rfc.

Andre

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 19 Dec 2016 15:35:43 GMT

] From: Scott Schmit <[email-masked]> wrote:

] But it looks like the contents of this zone are intended to be kept
] secret from end-users.

Depending on one's view of end users, that notion conflicts with
the final paragraph of section 6 on page 18:

  If a policy rule matches and results in a modified answer, then that
  modified answer will include in its additional section the SOA RR of
  the policy zone whose rule was used to generate the modified answer.
  This SOA RR includes the name of the DNS RPZ and the serial number of
  the policy data which was connected to the DNS control plane when the
  answer was modified.

 .............

> From: Scott Schmit <[email-masked]>

> twice.

If that mistaken notion is matters, please point out the words in
https://tools.ietf.org/html/draft-vixie-dns-rpz-04 that support it.
I think trying to keep policy zone contents secret would be foolish
and hopeless like trying to keep the contents of .com secret.

Section 12.4 is intended to be about minimizing disclosure of whether
RPZ is in use to the operators of authority servers of listed domains.
Over the years, that goal has receded.  RPZ subscribers tend to to
care less about whether bad guys could in theory notice that they're
being blocked than about the costs of recursing to their often slow
or even broken servers.

>         It also wouldn't be a SHOULD that the list be access-controlled.

None of the SHOULDs in section 12 mention "access control."  There is
a SHOULD for TSIG for authentication and integrity, but access control
is neither.  One might use TSIG for policy zone access control and I
think RPZ publishers should, but that is not the intent of section 12.3.

A RPZ publisher's interest in limiting timely access to paying subscribers
differs from keeping secrets.  It's like paying for access to current .com
changes versus .com secrecy.  Common DNS access controls including
"allow-transfer" and "allow-recursion" are also not about keeping secrets.

> Sure, an admin isn't required to keep it secret, but it's absolutely

If it matters, please point out the words in the draft that prompt
that mistaken notion.

---

From: william manning <[email-masked]>
Date: Mon, 19 Dec 2016 20:58:23 -0800

adding complexity in the middle of any system increases the size of an
attack surface.  true for SMTP, Firewalls, and DNS.   This draft formalizes
adding massive complexity throughout the DNS without a clear or crisp way
to debug and correct problems, particularly since resolution issues will
emerge that have are due to RPZ configurations multiple "hops" away from
the initial resolver and there is no business relationship in place that
would facilitate correcting errors.  When it becomes easier to create and
operate "walled gardens" and have such tools encouraged and sanctioned by
the IETF and its architecture board than to work on a common, open
Internet, I would suggest that ISOC review its support of an organization
that is actively working on tools, protocols, and techniques to destroy the
basic creed of an open Internet.  But hey, thats just my own opinion.

/Wm

https://www.linkedin.com/pulse/why-firewalls-do-work-open-expert?

---

From: william manning <[email-masked]>
Date: Wed, 21 Dec 2016 06:27:11 -0800

Vernon won't see this, since he has blocked my email, but here goes.

I think it is a huge mistake to adopt this work within the IETF.  Although
the IEtF has, in the past, documented worst common practice, i suspect that
this case is one where the WG chairs should tell the authors to take the
work to an industry forum, like DNS-OARC.   The authors (and others)
suggest that RPZ is needed in todays hostile Internet, if only to protect
oneself from abuse.    This work does NOT decrease the hostility of the
Internet, it raises the bar.   Indeed, nearly every case of the [+1] for
adoption comes with a caveat of "this is the worst thing ever."

While documenting common practice, this is clearly not "BEST COMMON
PRACTICE", (or is it? :)

It clearly is antithetical to ISOC's mission, "By connecting the world,
working with others, and advocating for equal access to the Internet, the
Internet Society strives to make the world a better place."   ...  No equal
access here, not connecting the world, not making the DNS a better place.
RPZ destroys trust in the DNS, which is DNSOPS "*Cutting off* the *nose to
spite* the *face*". For those who have not heard this before, it is an
expression used to describe a needlessly self-destructive over-reaction to
a problem.

So +1 if you feel you must.  RPZ does not make for a robust, resilient,
trustworthy Internet.  It actively works to undermine and and fragment the
Internet into insular walled gardens.

I'd be happier if there was an exit strategy for RPZ, so we would know when
to turn it off.

/Wm

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Dec 2016 09:54:16 -0500

William, I think the exit strategy for RPZ is DNSSEC.   We really need to figure out how to get people to be able to reliably and safely set up DNSSEC.   Despite Olaf’s excellent documents, we don’t really have that yet.   I don’t think that operating DNSSEC should be as scary as it is, but right now all the IETF advice on this topic is too general, requiring the installer to make decisions about their setup that the average IT person doesn’t know how to make.

We should have a document that says "look, if you don’t know any better, here is a way to set up DNSSEC that will make your users more secure than they are without it, and that will not blow up in your face (assuming you do it)."   I’ve seen a few documents like that, but nothing out of the IETF; they are generally on someone’s personal web site, and don’t see wide distribution.

I think we need to stop thinking that there will be some shining day when the Internet is a safe place.  The internet is an ecosystem, and ecosystems have predators and parasites.   We may not like it, it may violate our ideals, but it is reality, and denying reality doesn’t make it go away.   What we should be doing is thinking like gardeners, not like machinists.  Gardeners sometimes have to use methods for dealing with pests that allow us to have yummy food but aren’t so good for the pests.   The same is true with the Internet.

(FWIW, I’m in favor of adoption, for precisely this reason.)

---

From: Ray Bellis <[email-masked]>
Date: Wed, 21 Dec 2016 15:41:31 +0000

On 21/12/2016 14:54, Ted Lemon wrote:

> I think the exit strategy for RPZ is DNSSEC.

I don't follow this argument.

RPZ is primarily used to protect end-users from visiting sites
associated with malware, either because the A / AAAA result of a lookup
resolves to a particular address, or because the NS set used to resolve
the query shares resolvers with ones used by malevolent actors.

Those malevolent actors are just as capable of using DNSSEC.

Ray

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Dec 2016 10:50:02 -0500

> Those malevolent actors are just as capable of using DNSSEC.

Yes, but we don’t care.   The DNS infrastructure will still block queries to their zones; the difference will be that now the end node can _tell_ that the infrastructure blocked the queries.

Of course, some things you can do without DNSSEC you can’t do with DNSSEC.   You can’t send the browser to a _different_ web server.   This breaks some usage models, and would certainly cause my employer some pain.   I think that a transparent way of signaling that a zone has been blocked and signaling why it was blocked is worth doing as well.   But independent of that, if RPZ spurs further deployment of DNSSEC, I would consider that a win.

---

From: "John Levine" <[email-masked]>
Date: 21 Dec 2016 15:55:05 -0000

>Those malevolent actors are just as capable of using DNSSEC.

A lot of the arguments I'm seeing here boil down to "my users are
better off with a signed A record pointing to a site that installs
Cryptolocker than with an unsigned NXDOMAIN or SERVFAIL."

There may be a world in which that is true but I'm pretty sure this
isn't it.

R's,
John

---

From: Paul Wouters <[email-masked]>
Date: Wed, 21 Dec 2016 11:06:24 -0500 (EST)

> Cryptolocker than with an unsigned NXDOMAIN or SERVFAIL."

This comparison is false. Asking people to trust unsigned DNS, or
filtering out DNS without a signature of proof why it is filtered
is a downgrade attack on everything DNSSEC is supposed to protect
us from.

It's like saying browser users must click on "accept bogus cert
to continue".

> There may be a world in which that is true but I'm pretty sure this

You are wrong.

For example, imagine the irony of the next DNSCHANGER to actually change
people's DNS configuration from ISP-issued resolver to enabling the
local full resolver to bypass rpz or government DNS filters.

Paul
ps guess the good news is governments to mandating port 53 blocking
nationwide will run into 4 different ways of people doing DNS over
HTTP/TLS.

---

From: Scott Morizot <[email-masked]>
Date: Wed, 21 Dec 2016 10:17:39 -0600

Speaking as a large enterprise operator (over 100,000 employees and
contractors at over 600 sites as well as a significant public Internet
presence) that has DNSSEC signed all public zones, the majority of internal
zones, and has DNSSEC validation enabled at all levels throughout our
recursive DNS infrastructure (not just at our Internet access layer) and
which also employs RPZ based protections, I don't see a lot of overlap in
the threats against which each protect. The primary DNS based threats about
which we are concerned when it comes to RPZ are the vectors that utilize
malicious authoritative DNS zones for botnet command & control and data
exfiltration. In those scenarios especially, we do not even want the query
leaving the enterprise as the queries themselves are often the payload. (We
are also planning to use our own RPZ zones in addition to our current
subscription feeds to block malicious domains not in the feed when
identified. And we are looking at mechanisms to perhaps automatically
detect particular malicious query traffic patterns, especially those
associated with data exfiltration.) If a malicious zone is DNSSEC signed,
BOGUS validation of the RPZ responses by other internal validating
recursive nameservers, stub resolvers, or applications is perfectly
acceptable. Either way, the query is stopped from going out, which is a
primary goal. There's nothing that stops an operator for a malicious
authoritative zone from properly DNSSEC signing their authoritative zone.
The traffic itself would still be malicious. RPZ is widely used because
there isn't really another mechanism that effectively addresses that
specific attack vector.

Virtually every protocol standardized by the IETF either has been abused by
malicious actors or has the potential for abuse. Yes, if an authoritarian
nation state has the ability to restrict its citizens to state operated
recursive nameservers, then RPZ gives them another tool they can use to
forge responses. But such nation states were forging responses long before
RPZ existed. In such an environment, they have considerable ability to
abuse any protocol.

If the IETF has any ideas on ways to improve RPZ to better protect against
those DNS attack vectors in particular while reducing the potential for
abuse or if anyone has a proposal for an alternative standard, I doubt
those of us in the community that actually rely on it now would object. It
would be helpful if there were an agreed reference standard for
interoperability, but absent anything else that addresses the need, we'll
keep using the tool we have. As an operator, dnsop certainly looks like the
appropriate IETF working group for this draft. I'm not sure I understand
the rationale behind Informational as opposed to Proposed Standard, but if
the IETF wishes to have any input on the mechanism, this would seem to be
the place to discuss it. I'm in favor of adopting it as a working group
draft.

Scott Morizot

On Wed, Dec 21, 2016 at 8:54 AM, Ted Lemon <[email-masked]> wrote:

> William, I think the exit strategy for RPZ is DNSSEC.   We really need to
> figure out how to get people to be able to reliably and safely set up
> DNSSEC.   Despite Olaf’s excellent documents, we don’t really have that
> yet.   I don’t think that operating DNSSEC should be as scary as it is, but
> right now all the IETF advice on this topic is too general, requiring the
> installer to make decisions about their setup that the average IT person
> doesn’t know how to make.
>
> We should have a document that says "look, if you don’t know any better,
> here is a way to set up DNSSEC that will make your users more secure than
> they are without it, and that will not blow up in your face (assuming you
> do it)."   I’ve seen a few documents like that, but nothing out of the
> IETF; they are generally on someone’s personal web site, and don’t see wide
> distribution.
>
> I think we need to stop thinking that there will be some shining day when
> the Internet is a safe place.  The internet is an ecosystem, and ecosystems
> have predators and parasites.   We may not like it, it may violate our
> ideals, but it is reality, and denying reality doesn’t make it go away.
>  What we should be doing is thinking like gardeners, not like machinists.
> Gardeners sometimes have to use methods for dealing with pests that allow
> us to have yummy food but aren’t so good for the pests.   The same is true
> with the Internet.
>

---

From: "John Levine" <[email-masked]>
Date: 21 Dec 2016 16:27:26 -0000

>is a downgrade attack on everything DNSSEC is supposed to protect

Since DNSSEC doesn't protect us from people sending us malicious
content, it's hard to understand what point you're making here.

>local full resolver to bypass rpz or government DNS filters.

That's what DNSCHANGER has always done -- it gets answers from a DNS
server controlled by the bad guys which returns whatever the bad guys
want.  Again, it's hard to understand what point you're making here.

R's,
John

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 21 Dec 2016 21:51:09 +0100

On Mon, Dec 19, 2016 at 09:09:42AM +0000,
 Evan Hunt <[email-masked]> wrote 
 a message of 20 lines which said:

> I hereby, with full knowledge and prior consent, give my resolver
> (which I own) *permission* to falsely tell my browser (which I also
> own) that malware domains don't exist.

I hereby, with full knowledge and prior consent, *refuse* that my ISP
(or the hotel where I stay) modify DNS responses. I don't think it is
its job to do so (yes, I have google-analytics.com and many others on
my own blacklist on my own machine: I'm speaking for intermediaries
like the ISP).

> The ethical conundrum having been resolved,

No, we just handled a few cases.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 21 Dec 2016 22:08:08 +0100

On Mon, Dec 19, 2016 at 08:58:23PM -0800,
 william manning <[email-masked]> wrote 
 a message of 214 lines which said:

> attack surface.

+1 This was described in detail several times (see for instance this
report
<https://www.afnic.fr/medias/documents/conseilscientifique/SC-consequences-of-DNS-based-Internet-filtering.pdf>)
and we already saw its consequences for the security and stability of
the Internet
<http://www.computerworld.dk/art/214431/koks-hos-dansk-politi-spaerrer-for-8-000-websites>
(in danish)
<http://www.bortzmeyer.org/google-detourne-par-orange.html> (in
french)

---

From: [email-masked]
Date: Wed, 21 Dec 2016 22:20:32 +0100 (CET)

> <http://www.bortzmeyer.org/google-detourne-par-orange.html> (in

Agreed about the general comment about adding complexity. However,
consider the fact that quite a few operators (I happen to work for
one of them) *already* have this complexity in the system, and the
use of RPZ would actually *reduce* complexity.

Steinar Haug, AS2116

---

From: "John Levine" <[email-masked]>
Date: 21 Dec 2016 22:54:40 -0000

>(or the hotel where I stay) modify DNS responses.

I gather you live in France, where the government can and occasionally
does require ISPs to change DNS responses so that requests for domains
that a court considers illegal in various ways get the address of an
interior ministry server instead.  They did not need RPZ to do this,
and they do not ask your permission when they do so.  I'm certainly
not saying it's a good idea, but it is the law in France, and there
are similar laws in the UK and other countries that ISPs have to
follow.

To me, it is utter self-indulgence to imagine that it will make any
difference whatsoever to government censorship if we do or do not
publish RPZ documents.  On the other hand, as many people with
operational experience have confirmed, RPZ is an extremely useful tool
to keep Internet users from being attacked by malware.  It seems clear
to me that if we can help providers deploy anti-malware RPZ zones, by
enabling interoperable implementations, that will prevent a lot of
evil directed at our users.

It might be helpful to explain what people consider a reasoanble
tradeoff between censorship concerns and consumer protection concerns,
and how likely it is that RPZ publication or standardization would
have any practical effect in the two areas.

R's,
John

---

From: Mukund Sivaraman <[email-masked]>
Date: Fri, 30 Dec 2016 14:56:14 +0530

Hi Vernon

A couple of items:

1. I sent the following text to Paul, but it has missed making this
revision of the draft. Please add it into the next revision.

> In 4.1.1 (IP address encoding in triggers), I suggest adding:
>
> - The encoded address prefix MUST NOT not have any extra trailing 1s
>   (longer address prefix than the prefix length) or the rule will be
>   rejected. E.g., the following trigger will be rejected:
>
>   8.1.0.0.10.rpz-client-ip
>
> Some minor nits:
>
> - Include an IPv4 example in 4.1.1 (IP address encoding in triggers)
> - Maybe include that "zz" label in v6 encoding can also appear on
> - either side of the address bits label sequence

2. BIND makes the assumption that a trigger is exclusive within a zone.
So for example, if a zone transfer of an RPZ zone has taken place, and
currently the RPZ summary datastructures are being updated, the
datastructures can contain policy rules partially from an older version
of the zone and partially from a newer version of the zone (from the
transfer). As long as the change to an entire RR of a policy rule is
applied atomically, to BIND this is a consistent set of policy rules
(some of rules from previous version of zone, remaining from newer
version). This behavior is consistent with the RPZ rules so far, but it
would be wise to make a note of it.

(Note that this behavior is different from the old BIND RPZ
implementation and so you may not be familiar with it.)

		Mukund

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 30 Dec 2016 11:45:23 GMT

> From: Mukund Sivaraman <[email-masked]>

> >   rejected. E.g., the following trigger will be rejected:

The draft tries to address that issue with these final words of 4.1.1 in
https://tools.ietf.org/html/draft-vixie-dns-rpz-04

]  In the case of an address block, either IPv4 or IPv6, the address
]  part MUST NOT contain any non-zero bits after the section indicated
]  by the prefix length.  For example, "8.2.0.0.10.rpz-client-ip" is not
]  a valid trigger, because in the address "10.0.0.2" expressed in
]  binary notation, a one occurs outside the first 8 bits or prefix of
]  the address block.

Please suggest improvements.

> > - Include an IPv4 example in 4.1.1 (IP address encoding in triggers)

I don't understand how that would differ from the second paragraph of 4.1.1
which is

]  For example, the address block 192.0.2.0/24 is encoded as
]  "24.0.2.0.192".

Could you suggest some more or better text?

> > - either side of the address bits label sequence

I don't understand.  Describing how zz/:: works seemed difficult (as
demonstrated by the tech.note), so the draft tries to punt to RFC 5952.
As always, please suggest better words than are now in the draft.

> implementation and so you may not be familiar with it.)

Are you saying that the rdataset held st->r.r_rdataset or st->r.ns_rdataset
could be bogus in old versions of BIND?  Or that st->r.ns_rdataset and
st->r.r_rdataset might be from differing versions of red/black trees?
If so, that sounds like a good bug fix that might be documented in
BIND release notes or elsewhere, but not like something that should
be mentioned in description of the protocol.

Or do you mean that there should be words somewhere to the effect that
RPZ results must be sane despite concurrent AXFR/IXFR activity of
individual policy zones?  If so, please suggest some words.  Then there
is what should happen if a transfer of a policy zone happens between
the time QNAME rules are checked and the generally later time when
NSIP and NSDNAME rules are checked.  The draft tries to pretend that
all of the rules in all of the policy zones are checked instantaneously,
and never mind real code or the delays forced by recursion.  Words
about these issues are not BIND specific would probably be good, so
please suggest some.

---

From: Mukund Sivaraman <[email-masked]>
Date: Fri, 30 Dec 2016 17:55:50 +0530

Hi Vernon

> ]  For example, the address block 192.0.2.0/24 is encoded as

It seems that I was again reading an older revision of the draft! It
appears Paul did make the changes. I'm sorry for the confusion.

> about these issues are not BIND specific would probably be good, so

What I mean is is effectively this: an update to an RPZ zone on the
resolver may not be atomic, i.e., the resolver may not match policy
rules against a consistent before- or after- copy of the RPZ zone during
its zone transfer.

It may have a copy of RPZ policy rules in a datastructure that is
partially from a previous revision of the zone, and partially from the
incoming next revision.

Let A be the pre-transfer revision of the zone. B be the post-transfer
revision of the zone:

1. If trigger X doesn't exist in zone A and doesn't exist in zone B, the
resolver will not match against X during the transfer. This is
consistent with the case when the zone update is done atomically.

2. If trigger X exists in zone A and doesn't exist in zone B, the
resolver may or may not match against X during the transfer. This is
consistent with the case when the zone update is done atomically.

3. If trigger X doesn't exist in zone A and exists in zone B, the
resolver may or may not match against X during the transfer. This is
consistent with the case when the zone update is done atomically.

4. If trigger X exists in zone A and exists in zone B, the resolver will
match against trigger X from zone A or zone B during the transfer. This
is consistent with the case when the zone update is done atomically.

What I mean to say is that a zone transfer of policy zone is not atomic.
The resolver may match against triggers in A or B depending on the
progress of update. Only 1 trigger may match within a zone, so this can
be assumed with current RPZ syntax. But this behavior of RPZ zone
transfers not being treated atomically should be documented.

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Fri, 30 Dec 2016 18:22:11 +0530

On Fri, Dec 30, 2016 at 11:45:23AM +0000, Vernon Schryver wrote:
> Then there is what should happen if a transfer of a policy zone
> happens between the time QNAME rules are checked and the generally
> later time when NSIP and NSDNAME rules are checked.  The draft tries
> to pretend that all of the rules in all of the policy zones are
> checked instantaneously, and never mind real code or the delays forced
> by recursion.  Words about these issues are not BIND specific would
> probably be good, so please suggest some.

This is also a good point. Perhaps just saying that RPZ zone transfers
are not assumed to be atomic for the whole zone, but only at the
RR/policy rule level will suffice?

Paul mentioned during the RPZ bar/pub meeting that the purpose of this
RFC is to document BIND's behavior. BIND is not atomic in handling RPZ
updates. So the draft should explicitly state as unknown what happens
during a zone transfer when there are QNAME and NSIP triggers, where
QNAME comes from a previous revision of the zone and the NSIP comes from
the next revision of the zone.

		Mukund

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 30 Dec 2016 18:32:04 GMT

] From: Mukund Sivaraman <[email-masked]>

] This is also a good point. Perhaps just saying that RPZ zone transfers
] are not assumed to be atomic for the whole zone, but only at the
] RR/policy rule level will suffice?
]
] Paul mentioned during the RPZ bar/pub meeting that the purpose of this
] RFC is to document BIND's behavior.

I understand the goal of the draft a little differently.  I think it
should document the RPZ mechanism that originally existed only in BIND,
but without bugs or BIND9 specific oddities that no one not reading
BIND9 code would discover.  It must be readily added to other recursive
server implementations whose internal mechanisms differ from those of BIND9.

]                                     BIND is not atomic in handling RPZ
] updates. 

I've the impression that BIND applies IXFR/AXFR changes to all slave
zones atomically, so that an ordinary DNS response is always based on
a single version of the zone associated with the SOA serial number,
and hence the version pointer that is carried around in bin/named/query.c.

On the other hand I think we're talking about the fact that RPZ trigger
checking in BIND9 is (or was?) not atomic with respect to concurrent
policy zone updates or changes.

]          So the draft should explicitly state as unknown what happens
] during a zone transfer when there are QNAME and NSIP triggers, where
] QNAME comes from a previous revision of the zone and the NSIP comes from
] the next revision of the zone.

I think I agree with that.  If the working group does not reject the
draft, I will try to add text near the 3rd and 4th paragraphs of section 5
saying implementations need not check RPZ triggers atomically with
respect to concurrent policy zone transfers.

I'd welcome suggestions for those words.

 ..............

> ...

Wouldn't this also be covered by  words in section 5 saying
implementations need not check RPZ triggers atomically with respect
to concurrent policy zone transfers?