Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

From: Paul Wouters <[email-masked]>
Date: Sun, 1 Jan 2017 13:20:14 -0500 (EST)

On Sat, 31 Dec 2016, Ted Lemon wrote:

> There is no _way_ to make it easier for said outside forces to pressure providers.   They have the force
> of law on their side.   What we do makes no difference in that arena.   The arena in which it _does_
> make a difference is protecting people from losing their homes because they got suckered by some malware
> that got into their personal records on their computer.
>
> IOW, the argument you are presenting has nothing to do with the choice that faces us.   If you want to
> make the case for rpz being a bad thing, the argument you should be making would have to show why
> protecting people in this way is the wrong solution to the problem, and why some other solution to the
> problem (e.g., a blacklist in the browser) is less bad.
>
> Can’t we have that conversation, instead of these repeated assertions about things over which we have no
> control?

Some of us tried that and were told "that's not how RPZ works, we are
not changing how RPZ works".

The only thing I asked for is tracability and accountability, but not
witholding DNSSEC information but by passing it along in a different
section so that:

- RPZ still works as it does now for existing users/providers

- In the future RPZ filtering cannot be used as an out-of-the-box
   involuntary censorship tool.

- Accountability can be added by adding a different key of last
   mile trust anchor.

I'm interested in hearing technical reasons why this change cannot be
done, and lacking those, I would hope the WG does not adopt this document
if the authors are unwilling to make the changes to facilitate this..

Paul

---

From: Vernon Schryver <[email-masked]>
Date: Sun, 1 Jan 2017 22:43:08 GMT

> From: Paul Wouters <[email-masked]>

> not changing how RPZ works".

As I've repeatedly written, the purpose of the current draft is to
describe the current RPZ protocol.  The current draft and the protocol
it describes are not intended to and cannot prevent the specification
of other protocols, include protocols that might be called "RPZ."

> The only thing I asked for is tracability and accountability

As much tracability and accountability as can be hoped for is already
present with the RPZ SOA in the additional section.

>                                                               but not
> done, ...

Paul Wouters has not made his idea clear to me (but let's keep talk
about it public at least as far as I'm concerned).  My best guesses about
it conclude that putting RRs that as far as DNS clients could tell
are irrelevant to the answer section into the authority section would
make some clients unhappy.  (Since it's not my idea, never mind that
I suspect that fewer DNS clients might break if apparently irrelevant
RRs were added to the additional section instead of the authority
section.)

On the other hand, Paul Woulters' ostensible goal is presumably that
the organizations responsible for any rewriting to be identifiable
during the investigations of problems and then held accountable.  They
are
  - men hidden in the middle using mechanisms other than RPZ, but it
     would be silly to expect them to step forward to be traced or held
     accountable.
  - the people running the recursive resolver with RPZ that sent
     the rewritten response, but the IP address of the recursive
     resolver already identifies them
  - the people that provided the policy zone containg the rule that
     used to modify the response, but the SOA already in the additional
     section points to them and also identifies the version of the rule.

But these guesses of mine about the idea are irrelevant.  Someone
should write a technical proposal for the idea and submit it as an I-D
or here as words that could be added to the current RPZ draft.  That
someone is not me; I told Paul Wouters in response to his private mail
on Dec 22:

] Please write whatever Internet Drafts that are needed, but please
] understand that I have no current interest in a new kind of RPZ.
] ...
] No, your proposals for new rtypes and shifting A and AAAA RRsets from
] the answer section to authority section might be good and reasonable
] in another context, but they are irrelevant to a description of RPZ
] as it currently exists.

Vernon Schryver    [email-masked]

---

From: Barry Raveendran Greene <[email-masked]>
Date: Wed, 4 Jan 2017 14:17:39 +0800

> On Jan 1, 2017, at 6:00 AM, Ted Lemon <[email-masked]> wrote:
> 
> There is no _way_ to make it easier for said outside forces to pressure providers.   They have the force of law on their side.   What we do makes no difference in that arena.   The arena in which it _does_ make a difference is protecting people from losing their homes because they got suckered by some malware that got into their personal records on their computer.
> 
> IOW, the argument you are presenting has nothing to do with the choice that faces us.   If you want to make the case for rpz being a bad thing, the argument you should be making would have to show why protecting people in this way is the wrong solution to the problem, and why some other solution to the problem (e.g., a blacklist in the browser) is less bad.
> 
> Can’t we have that conversation, instead of these repeated assertions about things over which we have no control?

+1