Subject: Re: [DNSOP] draft-ietf-dnsop-dns-rpz

From: Petr Špaček <[email-masked]>
Date: Fri, 6 Oct 2017 15:56:20 +0200

Hello dnsop,

draft-ietf-dnsop-dns-rpz expired on 2017-09-10, i.e. did not receive any
update from 2017-03-09.

Is there a real apetite for work on this document?

We are considering RPZ implementation for Knot Resolver next year but if
the document is not going to move forward I would rather close the
ticket and be done with it. I certainly do commit to implementing
ever-changing protocol without readily available description ...

Is there anyone interested in the document except me and the appointed
editor?

Thank you for replies.
Petr Špaček  @  CZ.NIC

On 18.7.2017 14:13, Suzanne Woolf wrote:
> Dear colleagues,
> 
> 
> As you might recall, we had a call for adoption for draft-vixie-dns-rpz
> just before IETF 98 in March. We had a lively discussion and decided to
> adopt the document for further work in the WG as an Informational RFC.
> 
> However, the chairs then discovered we’d made a mistake in adopting the
> draft with the copyright that reserved rights in derivative works to the
> original authors. This isn’t allowed for a Working Group document (see
> RFC5378, Section 3.3).
> 
> We’ve talked since then with the authors about how we might move forward
> with the draft. They had concerns, which had already been discussed on
> the list, about some of the views of the WG on the applicability of RPZ.
> 
> We believe we’ve found a way forward that meets their concerns and the
> needs of the WG. We propose that:
> 
> 1. The draft adopts the following language in the Introduction:
> 
>     This document describes an existing and widely deployed method by
>     which a security policy can be applied to DNS responses, possibly
>     causing an end system to receive responses that do not correspond to
>     actual DNS zone content. Such policy-based responses might prevent
>     access to selected HTTP servers, or redirect users to "walled
>     gardens", or block objectionable email, or otherwise defend against
>     DNS content deemed malicious by the RDNS operator and the end-user.
> 
>     This method describes its policy using a specially formatted DNS
>     Zone called a Response Policy Zone (RPZ), and is an instance of a
>     more general mechanism called a "DNS Firewall." Like other
>     mechanisms called "firewalls," response policy zones (RPZ) can be
>     used to block both wanted as well as unwanted data.  RPZ ought not
>     be used to interfere with data desired by recipients. In other
>     words, RPZ should be deployed only with the permission of every
>     affected RDNS end-users.
> 
>     This document does not recommend the use of RPZ in any particular
>     situation or instead of other mechanisms including those more
>     commonly called "firewalls."  This document lacks an applicability
>     statement for that reason, and because it merely describes a
>     currently common practice, without recommending or criticising that
>     practice. By design and expectation, response policy zones (RPZ)
>     must be seen as a defensive and virtuous tool, or it will either not
>     be used, or will be bypassed by end-users.
> 
> 
> 2. We had already limited the the scope of the document to describing
> the current protocol, with any discussion of proposed changes left to a
> later document if people want to do that work. That limitation stands.
> The intended document status is Informational.
> 
> 3. The copyright is changed to the standard boilerplate required for a
> WG draft.
> 
> 
> If this is acceptable to the WG, we’ll keep the new draft with these
> changes as a WG draft. 
> 
> If not, the draft will be dropped as a WG item. The authors can seek
> publication of the document as an independent submission or outside of
> the RFC series.
> 
> If you have a comment on this, please make it succinctly and soon.
> 
> 
> thanks,
> Suzanne & TIm

---

From: Mukund Sivaraman <[email-masked]>
Date: Fri, 6 Oct 2017 20:02:03 +0530

Hi Petr

> Is there a real apetite for work on this document?

No answer for this question, but see below...

> ever-changing protocol without readily available description ...

I can't tell you whether to implement RPZ or not, but maybe the
following will be useful from an implementation perspective.

Whether IETF adopts it or not, RPZ is has been an existing real protocol
in operational use for several years now (with implementations and data
(zone) providers). The old RPZ specification was obsolete and this draft
is the only current spec that describes RPZ as it is used today. For
this reason at least, BIND will follow this spec whether it is a dnsop
adopted document or is maintained outside IETF. If for some reason the
co-authors abandon it (highly unlikely as they seem to have a business
case for it), we at ISC will likely pick it up as it is a BIND feature.
(We were going to do so about 1-1.5 years ago when we found that the old
draft was outdated, and contacted Vixie about it.)

It follows that if you want to support the RPZ zone syntax that is used
in feeds provided by several vendors, this draft is the only current and
correct spec as of now.

No comment about whether dnsop should adopt it or about the
philosophical side.

		Mukund

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 6 Oct 2017 15:00:51 GMT

> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <[email-masked]>

> Is there a real apetite for work on this document?

The change described in Suzanne Woolf's mail that you quoted is
awaiting a "make is so" order from the chairs.

I'd like to see the document get an official number, but 
https://tools.ietf.org/html/draft-ietf-dnsop-dns-rpz-00
looks like stable online storage (pending that applicability text).

> ever-changing protocol without readily available description ...

RPZ is not currently an ever-changing protocol.  Some of the
controversy surrounding the document has been caused by Paul's and
my insistance on restricting the current document to a description
of the almost 8 year old notion of RPZ instead of fixing, improving,
or extending it.

If you will include hooks for an RPZ implementation in your shipped
code as opposed to modified source in a 'contrib' directory that
users must compile specially, I'd be happy to try to propose such
hooks.  In other words, I could try to make a patch for Knot Resolver
like the patch that I wrote for Unbound (without cost to NLnet Labs).
If you prefer, you could write the code.

Vernon Schryver    [email-masked]

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 6 Oct 2017 17:28:24 +0200

Hi.

> If you prefer, you could write the code.

The current very limited implementation of RPZ in knot-resolver [1] is
done via a couple dozen lines of lua code, i.e. only JIT-compiled.  The
approach might remain similar, perhaps a bit more modularized, but in
any case I expect it would be included by default, so I wouldn't fear
about users having to recompile.

[1]
https://gitlab.labs.nic.cz/knot/knot-resolver/blob/v1.4.0/modules/policy/policy.lua#L294

--Vladimir

---

From: Paul Vixie <[email-masked]>
Date: Fri, 06 Oct 2017 09:00:57 -0700

> about users having to recompile.

let me clarify. there is an rpz implementation for bind9 and unbound 
which is mostly outside the server itself. so, it's a duplication of 
effort for bind9, which has its own internal implementation of rpz, but 
it's new functionality for unbound, which does not have rpz built in.

this rpz implementation consists of a daemon, a command line tool, a 
shared library, and a shared memory (mmap'd file) segment. the api for 
the shared library is meant to be not just name server implementation 
(thus, it works on bind9 and unbound), but also policy implementation 
(thus, it could work for a policy system other than rpz, though we've 
not tested it.)

the implementation we have (farsight security) is not open source, but, 
the API is entirely unencumbered. thus, someone other than us could 
implement a shared library and associated software that spoke to this 
API and could be dynamically loaded by bind9, unbound, and any other 
impementation of that API.

patches to make knot-recursive speak this API are what vernon offered. 
those patches, like the API it speaks to, are entirely unencumbered, and 
would therefore be compatible with your license. in fact the patches to 
make knot-recursive speak to this API would be donated to you and would 
become your property and would have only your license.

farsight's implementation of this API is called fastrpz. we don't give 
it away to the whole community; only to people who operate passive dns 
sensors for SIE. we fully expect to see fully open source competitors 
for our implementation of this API from other members of the community 
in the fullness of time.

the API now has a name, the response policy service (RPS).

please contact vernon directly if you'd be willing to accept a donation 
of patches to make knot-resolver able to call the RPS API, and thus, 
able to dynamically load any shared library that implements the RPS API.

please contact me directly if any of you would be willing to operate a 
passive DNS sensor for SIE, in exchange for a right-to-use license for 
the fastrpz implementation of the RPS API, or perhaps data trades &etc.

-- 
P Vixie

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 6 Oct 2017 16:38:46 GMT

> From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <[email-masked]>

> https://gitlab.labs.nic.cz/knot/knot-resolver/blob/v1.4.0/modules/policy/policy.lua#L294

I wish I wouldn't offend people when I point out that a mechanism
that uses local zone files is not a very limited response policy
zone implementation.  Such things might be far better than real
"rpz", but they're not "rpz".  (I can make a case for them being
better although I don't buy it, perhaps because I'm biased.)

Overwriting public DNS data triggered by qnames has always been trivial,
but that is not "rpz."  Simply fire up a local authority server with
your own "DNS lies" and point your resolvers to it, perhaps with custom
"hints" files.  If you're running combined authority/resolver code
such as BIND, simply add some local zone files.  But such ad hoc
authority server schemes as well as the new so called "rpz" schemes
of adding local zone files to resolvers the lack features that motiviated
the original implementation of real RPZ including:

  - distributed policy zones, including from external organizations
      This sounds minor, but it is major.  It's related to why so few
      organizations maintain their own anti-spam DNS blacklists. 
      You could use FTP, rsync, HTTP, etc. and a cron job, but in
      practice you won't.  And if you did, it updates would have
      latencies of hours or days instead of seconds with real RPZ.

  - dynamically combine policy from multiple sources
      In theory this could be done with some perl, awk, or even
      Bourne shell code, but not in practice at scale.

  - policies triggered by the contents of A and AAAA responses or by
         the names or IP addresses of authorities
      The bad guys can and do register new domains faster than you can
      update your local blacklist, faster than they can hijack new IP
      addresses for those new domains, and faster than they'd like to
      establish new authorities serving those new domains.

  - no need to restart the resolver to reload the zone
      This not only minimizes end user disruption when the zones
      are reloaded but allows organization-wide policy changes with
      latencies measured in seconds.

In other words, hacking local zone file qname overrides into a
resolver is not hard (including CNAME and DNAME chains).  The horrid
code involves triggering on A or AAAA contents and authority names
and addresses...well there're also SOA timers, IXFR, AXFR, Notify,
and TSIG, but that code is less horrid than voluminous.

Please don't misunderstand me as saying no one else can or should
write real RPZ code.  Many people could and I really wish they
would.  That's why I spent a lot effort outside my comfort zone on
the I-D.  What bugs me are implementations of so called RPZ and RRL
that share only the acronyms with the BIND stuff.

---

From: Marek Vavruša <[email-masked]>
Date: Fri, 6 Oct 2017 11:13:46 -0700

Hi Vernon,

There's a functionality [1] to do all these things (and more), you
just can't read/write complicated rules from RPC compatible format
(DNS zone files). Feel free to contribute of course.

Marek

[1]: http://knot-resolver.readthedocs.io/en/stable/modules.html#dns-application-firewall

On Fri, Oct 6, 2017 at 9:38 AM, Vernon Schryver <[email-masked]> wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 6 Oct 2017 20:08:35 GMT

> From: =?UTF-8?Q?Marek_Vavru=C5=A1a?= <[email-masked]>

> (DNS zone files). Feel free to contribute of course.

On the contrary, as far as I can see from the table in 
http://knot-resolver.readthedocs.io/en/stable/modules.html
none the features that originally justified RPZ are present in the
Knot mechanism.  It lacks
   - distributed, simultaneous multi-source polices
   - IP triggers
   - full client-IP triggers
   - redirecting to walled gardens
   - NSDNAME and NSIP triggers (although those were added after my
       first versions by user demand)
   - walled gardens (according to the table, but I don't understand
       how that is missing)

The Knot mechanism might be a lot better than RPZ, but it is *NOT*
RPZ.  Because it uses a different rule source-resolver protocol, it
can be neither a subset nor a superset of RPZ.  Calling it "rpz" is
like calling the ancient DEC name scheme (I've forgotten its name) or
NIS (YP) "DNS."  Those things could do things that DNS cannot do.  The
DEC protocol was arguably better all around than DNS, but it was not
DNS, no matter how often or how hard its advocates tried to sell as DNS.

One might say "it's a subset without the bits that some mistakenly
claim are important and it uses an incompatible protocol but it's still
rpz," but that would be like saying a Chevrolet Spark is a subset of
a 40 ton tractor, or vice versa.
https://www.google.com/search?q=Chevrolet+spark
https://www.google.com/search?q=60+ton+tractor
That the Spark is more useful to more people and that most people
could not use a large tractor does not make one a subset of the
other.  They simply differ.

Again, the Knot mechanism might be better than RPZ, especially if it
were given a few of what seem to me like easy additions.  RPZ has
suffered from feaping creaturism; something simpler could be better.
But please don't call it RPZ, because it is not RPZ.