Subject: [DNSOP] adoption mechanics and disclaimers wrt dns-rpz

From: Paul Vixie <[email-masked]>
Date: Sun, 19 Mar 2017 23:55:35 +0000

on sunday march 12, [email-masked] wrote as follows:

> I'd be happy to see the document proceed under two conditions:  1) it
> becomes a WG document, subject to IETF change control, and 2) that the
> disclaimer requested back on 20170103 be added to the document. To refresh
> the collective mind, here is the missing text:
> 
> applicability statement.
> 
> This draft is documents a process and method for intercepting DNS queries
> and fabricating responses to redirect the querier into a walled garden or
> enclave that is NOT part of the open Internet. Adoption and acceptance of
> this draft is an acknowledgement that the IETF, the IAB and ISOC reject the
> principles espoused at https://open-stand.org/about-us/principles/, in
> particular article 3.  Collective Empowerment insofar as the evolution of
> the DNS is concerned.

i was not subscribed at the time, so i'm working from the archives. the above 
quoted text is wrongheaded and its proposals unacceptable in several ways.

first, the document has been adopted, but is not subject to ietf change 
control. rather, the authors will attempt to modify the text to suit the 
consensus position of the WG, and at publication time, rights to create 
derivative works will be released to the IETF. so, the WG has domain over the 
meaning of the final document and the content of future documents, but not 
over the content of the final document. the authors want to work with the 
community to ensure that a consensus document is published, but we do not want 
to open the door to wrongheaded and unacceptable wordings typified by the 
above.

second, your disclaimer won't be added, and if the consensus of the WG is that 
it must be added, then the standardization activity of dns-rpz will fail. you 
are free to pitch your ideas, and the authors are free to try to accommodate 
those ideas, but the final arbiter of whether accommodation is necessary or 
has been accomplished is WG consensus, not the authors, and not any WG member.

third, ignoring completely the words and the wording of your proposed 
applicability statement, and focusing purely on the ideas it contains, let's 
dispense with the nonsequiturs and canards as follows:

* queries are not intercepted; they are processed differently and deliberately 
by an RDNS server which has voluntarily subscribed to explicit policy sources.

* response fabrication is in this case a service desired by the end-user and 
by the RDNS operator, thus, "fabrication" has improper connotation.

* redirection is by no means the only capability offered.

* walled gardens or enclaves may, or may not, be part of the open internet.

* adoption and acceptance does not acknowledge anything like what's shown. 
rather, it's an acknowledgement that the internet now does work this way, at 
the deliberate and voluntary behest of its RDNS operators and users, and that 
a specification document has two boons: in the short term, giving implementors 
and publishers a single authoritative reference for how dns-rpz works now; 
and, giving change control of the dns-rpz protocol itself over to the IETF 
upon this document's publication, so that the community can drive changes in 
the protocol henceforth.

i did not note any second or other voice in favour of this amendment, and due 
to the vacuous pseudo-mumbo alt-jumbo of the proposal, i predict there will be 
no other voice in favour of it.

so, the authors propose a replacement for the current 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.
>     Such modified DNS results 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 or end-user. These so-called "DNS Firewalls" are widely used in
>     fighting Internet crime and abuse.
>     
>     Like other mechanisms called "firewalls," response policy zones (RPZ)
>     can be used to block wanted SMTP, HTTP, and other data 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 any and all 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.

please chime in if you're for or against this proposed text, or if for some 
incomprehensible reason you are in favour of [email-masked]'s 
proposal from march 12 and want it to be further considered or debated.

the authors will work toward consensus, but not arbitrarily so.

vixie

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Mar 2017 00:06:49 +0000

fwiw, here is the text of an RPZ brief provided to the ICANN TEG in the recent 
copenhagen meeting. the text was edited by me, and all errors or omissions are 
mine:

> What are Response Policy Zones (RPZ)?
> 
> A Response Policy Zone (RPZ) is a way to convey DNS resolution policy
> from a security provider to a security customer. The RPZ format can
> identify DNS content by name, or by name server, or by resulting IP
> address; and it can be used to prevent a DNS resolver from reaching the
> DNS content in question, either fully, or indirectly via a honeypot or
> walled garden. Like all so-called "DNS firewalls", the use of RPZ is
> optional, and must be seen by its customers as a value-add, or else it
> will not be used. RPZ was originally prototyped in the ISC BIND9 name
> server, but has since become generally available.
> 
> Fundamentally, an RPZ is a set of rules that directs a recursive name
> server how to act if the answer to a query it resolves matches one of
> the rules in the RPZ. There are different kinds of matches that cause
> the recursive server to take different actions when a match occurs.
> The overall goal of an RPZ is to avoid interacting with certain domains,
> name server, or DNS results such as IP addresses depending on the purpose
> or policy associated with the RPZ. For example, an RPZ could implement
> a policy against visiting malicious domains (such as malware sites,
> phishing sites, etc.) to protect users.
> 
> An ingenious feature of RPZ is that the policy rules themselves are
> actually encoded as standard DNS resource records in a standard DNS zone
> (hence the word "zone" in the name). Since RPZs are normal DNS zones, they
> can be easily distributed using the standard DNS zone transfer protocol,
> which moves a DNS zone from one name server to another. In the typical
> configuration, a recursive name server operating wanting to implement a
> particular policy "subscribes" to a particular RPZ offered by their own
> security team or by an external security provider. The recursive server
> obtains the RPZ using a standard DNS zone transfer from an authoritative
> server operated by the provider. Notably, the RPZ information is not
> intended for direct lookup or consumption by users. Rather, a recursive
> server internally looks up record-sets in an RPZ to direct how it should
> deal with responses it receives during its normal resolution process.
> 
> To offer a specific example, Farsight Security offers an RPZ that
> contains newly observed domains. The theory behind this particular RPZ
> is that phishing sites and malware often use newly registered domains,
> since these domains have a very low probability of already being tagged as
> malicious in various security intelligence services. Once configured with
> this RPZ, a recursive server will effectively refuse to resolve any newly
> observed domains until an incubation period has passed, ensuring that
> users of that recursive server will be protected from these new sites
> long enough to give other reputation services, and takedown services,
> enough time to complete their work. Any connotation of "dangerous" with
> "newly observed" would have to exist in the eye of the resolver operator,
> and is purely subjective.
> 
> Recursive name server implementations that offer RPZ support include
> BIND 9 (Internet Software Consortium), Knot Resolver (cz.nic), PowerDNS
> Recursor (PowerDNS), and FastRPZ (a product of Farsight Security
> that operates with ISC BIND9 and NLNetLabs Unbound).  About a dozen
> RPZ-format security feeds are currently available, some commercial,
> some free. The list of implementations and providers can be found at
> https://dnsrpz.info/.

---

From: Ray Bellis <[email-masked]>
Date: Mon, 20 Mar 2017 04:51:08 -0700

On 19/03/2017 16:55, Paul Vixie wrote:

> please chime in if you're for or against this proposed text

It looks fine to me!

Ray

---

From: Warren Kumari <[email-masked]>
Date: Mon, 20 Mar 2017 16:15:44 +0100

On Mon, Mar 20, 2017 at 12:55 AM, Paul Vixie <[email-masked]> wrote:
> control.

Authors (and DNSOP),

It appears that this may have been a process violation here - RFC5378
Section 3.3. Right to Produce Derivative Works seems to say that the
IETF needs change control before a WG can formally adopt a document. I
believe that we missed the fact that this included "non-standard"
copyright boilerplate.

I / we are still investigating, and would appreciate it if the WG
gives us some time to figure this out.

W

> rather, the authors will attempt to modify the text to suit the
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Mar 2017 12:00:23 -0400 (EDT)

> gives us some time to figure this out.

I'm not a process expert, but I would think that this document is best
resubmitted as individual RFC (with boilerplate updated to reflect this),
and then immediately placed into a "Final Review" as specified in Section
4.7 of RFC 4846. The RFC-Editor should be informed that this document
has passed the technical review already in dnsops and that dnsops is in
favour of publication as individual rfc documenting as it describes a
valuable current used practise, so the document should proceed without
modifications to the specified protocol.

This also would address my issue of the WG adopting something it cannot
really change that could be abused for nationstate-level censorship.

However, such a change of submission should not lead to any more
substantive delays in publication. If this is not possible, then I will
retract my objection to publishing this as a WG document, and would only
request the authors update the initial sentence of the abstract to say:

 	This document describes an existing and widely deployed practise
 	for expressing and distributing DNS reply filters. This is
 	implemented using a DNS response policy inside a specially constructed
 	DNS zone, and for processing the contents of such response policy
 	zones (RPZ) inside recursive name servers.

Paul

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Mar 2017 17:11:12 +0000

> really change that could be abused for nationstate-level censorship.

if that's what has to be done, the authors will do it.

>  	zones (RPZ) inside recursive name servers.

well, so, it's not a reply filter, but your language as to "existing and 
widely deployed" can be added.

vixie

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Mar 2017 14:10:32 -0400 (EDT)

> widely deployed" can be added.

The two changes are related for me. One is the warning about it being a
DNS answer modifier (whether you call it a filter, firewall, or censor
tool) and the other is that this modification practise is widespread
and better done with interoperability in mind.

Saying "expressing DNS response policy" might be pedantically more
correct, but is really obfuscating what this tool does, and I think the
abstract should really convey what this is all about.

Anyway, I said "request the authors". It is not a demand. I'm sure you
fully understand my opinion and concern by now. I'll leave it to you to
accomodate that with any or no textual modification.

Paul

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Mar 2017 18:35:18 +0000

> accomodate that with any or no textual modification.

how about "This document describes a 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."

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Mar 2017 14:46:44 -0400 (EDT)

> that do not correspond to actual DNS zone content."

That sounds good. Thanks for accomodating me.

Paul

---

From: Melinda Shore <[email-masked]>
Date: Mon, 20 Mar 2017 10:51:18 -0800

> gives us some time to figure this out.

I was (and am) quite astonished that the working group would adopt
this as a working group deliverable under the circumstances.

Melinda

---

From: joel jaeggli <[email-masked]>
Date: Mon, 20 Mar 2017 19:18:16 -0700

> gives us some time to figure this out.
Hi,

It appears to be the case that the author's statement above necessarily
precludes adoption as a working group document. It is not uncommon for
documents to have terms applied to them  that are incompatible with
working group adoption. Those are sometimes altered on adoption,
processed as individual submissions, or through another stream (external
standards require special handling for example, rfc 5830). Applying the
tlp 5  section 6c limitations is obviously at the discretion of the
contributors and may be changed at any time.

thanks
joel