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

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

On Mon, 19 Dec 2016 10:11:11 +0100 (CET)
[email-masked] wrote:

> > 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
> 
> The law instructs me to tell customers the lie that various Pirate Bay
> domains are not available. This is a lie because the domains *would
> be* available if the customer had used OpenDNS, Google Public DNS etc.
> 

when the domain registry tells you that example.com is not registered
it is not a lie either.

when a court tells you to resolve a domain in a certain way, this is
not a lie.

when there is an RFC that describers how to lie and then adds
deception, this is no longer something to negotiate or to discuss much.

We are typing an email, on a mailing list. it is what it is. we can
call it a zoomba on a zimba - but it still is what it is.

you still have not talked about lying, deceiving, stealing, etc.

Where is the line?

What is okay for a draft? describing a method of theft? 

( anyway, nowhere in this draft does it say anything about this method being
defined for the purposes of managing court orders or to comply with
law enforcement. )

> Anyway, I don't think we're going to agree on this matter.
> 

it is not about us agreeing on anything.

It is about us discussing ethics of this draft and the fact that it
defines lying and deception. 

Even if we do not agree about lying, deceiving and fraud, can we maybe
agree about where the ethical line then is? 

Is it okay to publish a draft defining a protocol on how to steal a resource? 
or maybe defining a protocol for phishing? 

where is the line and at what point is it now okay, for yourself?

Andre

---

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

> deception, this is no longer something to negotiate or to discuss much.

By this token any firewall is censorship and lies. Yet we still use them.

We have also documented ways to distribute blackholing via BGP for the
specific purpose of silencing traffic.

You don't stop something from happening by saying a standard is theft. 

So please realise this is something that people need. Best that they do it
in a standardized fashion.

> or maybe defining a protocol for phishing? 

It is very much a protocol against phishing. 

	Bert

---

From: Jim Reid <[email-masked]>
Date: Mon, 19 Dec 2016 09:50:18 +0000

> On 19 Dec 2016, at 09:38, bert hubert <[email-masked]> wrote:
> 

Indeed. And nobody’s putting a gun to Andre’s head to force him to “tell lies” with RPZ (or whatever).

---

From: ac <[email-masked]>
Date: Mon, 19 Dec 2016 11:50:02 +0200

On Mon, 19 Dec 2016 10:38:46 +0100
> You don't stop something from happening by saying a standard is
it is not even close to the same thing.

domain names include trademarks, bank names and so much more than
advertising a route or dropping ipv6

you are answering for something that has implied trust and that you do
not necessarily own or have any rights to. (implied fiduciary responsibility)

> So please realise this is something that people need. Best that they
> do it in a standardized fashion.
>

people also need tools to send out bulk emails. maybe bots. should we
start RFC's for that?

this is not about what you need.

it is about so much more and you may need to look deeper into what this
all means and may mean in the future.

right now though there is still a truth that nobody has countered, yet:

It is never okay to tell lies, to deceive or to steal.
 
> > Is it okay to publish a draft defining a protocol on how to steal a
> > resource? or maybe defining a protocol for phishing? 

your reply does not answer the question?

Andre

---

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

> people also need tools to send out bulk emails. maybe bots. should we

We did in fact. All those things work with standards we wrote. 

> all means and may mean in the future.

Maybe the internet was a mistake then. But I don't think we'll convince you.

Huge segments of the internet do think this is a good idea. And like other
standards, this could be used for bad purposes. But that doesn't mean we
shouldn't do it. 

So I'm afraid we won't make you happy if your bar is 'any standard that
could be used for bad things shouldn't happen'.

Cheers.

	Bert

---

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

On Mon, 19 Dec 2016 10:59:31 +0100
> On Mon, Dec 19, 2016 at 11:50:02AM +0200, ac wrote:
<snip>
> Huge segments of the internet do think this is a good idea. And like
> other standards, this could be used for bad purposes. But that
> doesn't mean we shouldn't do it. 
> So I'm afraid we won't make you happy if your bar is 'any standard
> that could be used for bad things shouldn't happen'.

I do not think that "huge segments of the Internet" thinks it is a good
idea to lie and to deceive.

To be clear and to boil it down: This draft publishes a method to supply
different answers to different users and to hide the truth of those lies to 
the same users.

Unless a registry, court or resource owner authorizes this, it is
lying, cheating, "fraudy" and definately deceptive. (like a cockroach
when exposed to light)

I think that if people knew what we were talking about and
truly understood the issues, there would be an uprising.

If "huge segments of the Internet" thinks it is okay to lie, cheat,
deceive and steal I guess I will still say that I do not agree.

Andre

---

From: [email-masked]
Date: Mon, 19 Dec 2016 12:18:42 +0100 (CET)

> different answers to different users and to hide the truth of those lies to 

So do for instance BIND views.

> lying, cheating, "fraudy" and definately deceptive. (like a cockroach

This is, ultimately, always a local decision.

In "my" network I have at times returned incorrect answers to queries
for <random>.domain - in order to mitigate the effects of "water
torture" attacks. Yes, this is definitely lying. The alternative is
to do nothing, and let the attack on the authoritative name servers
continue. I'm afraid your characterization above isn't going to change
this.

> truly understood the issues, there would be an uprising.

I think most people have little or no idea what DNS is about. However,
if they truly understood the issues, they would probably also understand
the need for RPZ.

Steinar Haug, AS2116

---

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

I cannot reply to you, off list, as your email is broken. So, for the list, my reply:

On Mon, 19 Dec 2016 11:34:16 +0000
Jim Reid <[email-masked]> wrote:
> > On 19 Dec 2016, at 09:50, ac <[email-masked]> wrote:
> > you are answering for something that has implied trust and that you
> > do not necessarily own or have any rights to. (implied fiduciary
> > responsibility)

> This is nonsense. You’re trolling. Please stop it.
> I hope can proceed with a technical discussion about this draft.
> 

If it were an IP Internet resource we were discussing you may actually
be correct.

The same ethical rules do not apply to names as do to numbers.

And, my objection is exactly to that: The discussion of that which is not ethical.

I do realize that there are problems that has to be solved and resolved,

but there has to be better solutions than to normalize lying and deception 

simply for our convenience.

Andre

---

From: ac <[email-masked]>
Date: Tue, 20 Dec 2016 06:42:02 +0200

In advance, I do apologize for me taking additional bandwidth

I received many interesting off list emails, many did not understand 
why ethics regarding IP was different from that of names. I incorrectly
assumed that everyone simply knew that there are differences.

This may also be a basic consideration why some DNS admins do not see
what they do as so much different than that which other admins do,

Maybe this needs to be said in more detail, instead of what I am
saying just looking like a belief or a point of view. 

> On Dec 19, 2016, at 2:28 AM, ac <[email-masked]> wrote:  
> > In your example, ethically, it is a problem that should be
> > addressed on IP, not on DNS  
> 

the reason why there is an ethical difference between Domain Names and
IP resources starts with the fact that domain names are other people's
actual intellectual (legal) property. There is also all the other
considerations, for example DNS is a question whereas some other
protocols are instructive, based on the answers to questions.

IP resources (RIR) are generally not registered as intellectual property
and so the ethical considerations regarding IP are different to that of names.

There is more, and the rest could be added so that the ethical side of DNS may 
become more highlighted.

Andre

---

From: Evan Hunt <[email-masked]>
Date: Tue, 20 Dec 2016 04:56:06 +0000

> and so the ethical considerations regarding IP are different to that of names.

Once again, I own my resolver and I own my web browser. I want my web
browser not to download malware. It's easier for me to configure my
resolver not to answer bad questions than it is to prevent my browser
from asking them. Neither "ethics" nor "intellectual property" (the
relationship between which is not, in my opinon, anywhere near as
obvious as it is to you) are considerations here.

If you wish to consider a physical analog, there may be a general principle
that one should not interfere with postal mail, but this is challeged by
the existence of the unabomber or the anthrax attacks.

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

---

From: ac <[email-masked]>
Date: Tue, 20 Dec 2016 07:30:43 +0200

On Tue, 20 Dec 2016 04:56:06 +0000
Evan Hunt <[email-masked]> wrote:
> > the reason why there is an ethical difference between Domain Names
> > and IP resources starts with the fact that domain names are other
> > people's actual intellectual (legal) property. There is also all
> > the other considerations, for example DNS is a question whereas
> > some other protocols are instructive, based on the answers to
> > questions.
> > 
> > IP resources (RIR) are generally not registered as intellectual
> > property and so the ethical considerations regarding IP are
> > different to that of names.
> 
You are quite correct, but the minute you answer questions for other
people the entire situation changes. 

Also, you cannot simply (legally) publish your t&c as you are not mandated 
to answer for third party property owners. In much the same way as you cannot 
create a contract with someone to rob a bank. 

To rip the dam from underneath the duck: You cannot legally resolve a
non google IP number as "google.com" just because your t&c says you can
do whatever you want.

Of course, nobody can stop you (except the property owner) much the
same as it is your gun, your getaway car and your gas - when you rob a
bank. 

> If you wish to consider a physical analog, there may be a general
> principle that one should not interfere with postal mail, but this is
> challeged by the existence of the unabomber or the anthrax attacks.
> 
In your example, you still require a court order, you do not have
standing to make a decision to intervene yourself.

in DNS, it is much more subtle, it is about honesty, morality and ethics.

Andre

---

From: Evan Hunt <[email-masked]>
Date: Tue, 20 Dec 2016 06:12:42 +0000

> people the entire situation changes. 

Not if they've contracted with me to answer their questions in a way
that protects them from malware, it doesn't.

> non google IP number as "google.com" just because your t&c says you can

If google.com is known to be sending malware or spam or other undesirable
content (which it isn't), then of course I can.  Or, instead of remapping
the answer, I can return NXDOMAIN.  This would not be theft; it would a
service provided to my malware-averse clientele.  If they don't want this
to happen then they should use some other resolver or run their own.

Now, if I remap google.com in order to *cause* my clients to receive
malware or spam, then yes, I agree that I am being evil, and I hope
everyone is using DNSSEC and SSL certificate validation and other such
mechanisms to detect and avoid this.

> in DNS, it is much more subtle, it is about honesty, morality and ethics.

I remember when I stood up at my first IETF meeting and asserted the
principle that the DNS should not lie.  I was 40 years old.  Just a
starry-eyed kid with a dream.

Even then, though, the context of my statement was that there were
technical considerations that made it regrettably necessary to lie
in certain operational environments - specifically, some networks at
the time were breaking when they received AAAA answers, so we'd added
an option to filter those. Such considerations take precedence over
absolute truthfulness.

"Not wanting to be recruited into a botnet" is another such consideration.
Paul and Vernon invented a useful tool to help address it, and I'm
in favor of documenting it.

---

From: "Allan Liska" <[email-masked]>
Date: Tue, 20 Dec 2016 01:23:10 -0500

in DNS, it is much more subtle, it is about honesty, morality and
ethics.

Andre

Your nonsense is starting to get annoying.  The whole reason that RPZ
exists is because there are a whole bunch of dishonest, unethical and
immoral people out there registering bad domains and attacking my
users. Tools like RPZ help me defend organizations against these
people, and frankly I don't care if I violate the rights of the
jackhole who registered bank0fammmerica.com to attempt to defraud my
users.  
RPZ is a necessary tool, and it makes a lot of security sense, and I
would much rather have a standardized and well document version of it
so everyone understands it. Go talk to the bad guys about honesty,
morality and ethics and let us know how that goes.  
allan

---

From: ac <[email-masked]>
Date: Tue, 20 Dec 2016 08:40:57 +0200

On Tue, 20 Dec 2016 06:12:42 +0000
> that protects them from malware, it doesn't.
ianal, my reply and opposition to the publication of the draft is that it is not ethical.

> > To rip the dam from underneath the duck: You cannot legally resolve
> > a non google IP number as "google.com" just because your t&c says
> > you can do whatever you want.
> If google.com is known to be sending malware or spam or other
> undesirable content (which it isn't), then of course I can.  Or,
> instead of remapping the answer, I can return NXDOMAIN.  This would

I do not see any problems with that, as you are not providing an actual answer 

> not be theft; it would a service provided to my malware-averse
> clientele.  If they don't want this to happen then they should use
> some other resolver or run their own.
> 
imho DNSSEC is the way to go, it obviates the need for RPZ and for DNS
ethcis and many other issues.

Andre

---

From: ac <[email-masked]>
Date: Tue, 20 Dec 2016 08:45:46 +0200

On Tue, 20 Dec 2016 01:23:10 -0500
"Allan Liska" <[email-masked]> wrote:
> > principle that one should not interfere with postal mail, but this
> is challeged by the existence of the unabomber or the anthrax attacks.
+++
<snip>

It is not really an argument to say just because someone else has no

ethics it is also okay for me not to have ethics.

This is now becoming off topic and not related to this draft.

Andre

---

From: Jim Reid <[email-masked]>
Date: Tue, 20 Dec 2016 12:46:27 +0000

> On 20 Dec 2016, at 06:40, ac <[email-masked]> wrote:
> 
> my reply and opposition to the publication of the draft is that it is not ethical.

In that case, I suggest the WG notes your objection and otherwise ignores it. You don’t have a veto anyway: nobody does.

The rest of us should now be able to get on with the job of assessing the technical and operational merit of the ideas in this draft. If you have a meaningful, relevant and constructive contribution to make to that discussion, go ahead. If you don’t, you can either be quiet or take those rants elsewhere. Thank you.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 Dec 2016 07:49:59 -0500

> ethics it is also okay for me not to have ethics.

Andre, you still haven’t given any reason why the IETF should care about your ethical beliefs.   I’ve asked you several times privately to either give us a reason to accept your ethical system that _we can understand_ or stop haranguing us about it.   The reason that you have given is nonsensical; the distinction you are drawing is nonsensical.

Although people do buy and sell domain names, what they are actually buying and selling is a contract right to the name, not the name itself.   This can be validated simply by noticing that if one fails to continue to renew a domain name, one loses it, and if one has a domain name that infringes on a registered trademark, and the owner of the trademark enters arbitration on it, one stands to lose it as well (although that isn’t always the outcome, of course).

The point is that while you may believe that domains names are property, and that a DNS server administrator who doesn’t honor that property right is stealing, nobody here agrees with you, and by and large the courts do not agree with you either.   If you wish to litigate this issue, you are talking to the wrong people.   You can continue to harangue us, but we aren’t going to change our minds. You can demand that the working group not accept this work because of your ethical beliefs, but it’s clear that nobody agrees with you, and a lot of people disagree, so that’s not going to get you what you want.

I know it’s not pleasant to be ignored, and I genuinely sympathize, but if you continue to harangue us, you will just be wasting the working group’s time, and you risk a formal pr-action, which would remove your posting rights for some period of time.   Please stop before someone has to do this.

Of course, the same goes for people on the other side of this discussion: Andre has obviously not convinced anyone; if he continues to post, there is no need to continue to reply.

---

From: ac <[email-masked]>
Date: Tue, 20 Dec 2016 15:19:08 +0200

On Tue, 20 Dec 2016 07:49:59 -0500
Ted Lemon <[email-masked]> wrote:
> The point is that while you may believe that domains names are
> property, and that a DNS server administrator who doesn’t honor that
> property right is stealing, nobody here agrees with you, and by and

 domain names are, factually, intellectual property, and expire and may be renewed much like other intellectual property.

> large the courts do not agree with you either.   If you wish to
> litigate this issue, you are talking to the wrong people.   You can
> continue to harangue us, but we aren’t going to change our minds. You
> can demand that the working group not accept this work because of
> your ethical beliefs, but it’s clear that nobody agrees with you, and
> a lot of people disagree, so that’s not going to get you what you
> want.
> 
I am not trying to convince anyone of anything. 

there is nothing that I want, except maybe, to learn. I do not have any agenda, motive 
or specific objective and have nothing to lose or to gain - at all.

> I know it’s not pleasant to be ignored, and I genuinely sympathize,
> but if you continue to harangue us, you will just be wasting the
> working group’s time, and you risk a formal pr-action, which would
> remove your posting rights for some period of time.   Please stop
> before someone has to do this.
> 
I am also not a child as I already have grand children, and after 30 years on the 
Internet, I am way past the point of worrying about threats to ignore me, being 
called a troll, being ignored or being threatened by sanctions.

> Of course, the same goes for people on the other side of this
> discussion: Andre has obviously not convinced anyone; if he continues
> to post, there is no need to continue to reply.
> 
again, I am not trying to convince anyone of anything. But, I have not
read anything in any thread, about this draft, that tells me why I am
making a mistake and that my objection on ethical grounds, is invalid.

maybe, instead of thinking about me as a troll? think about me as being
ignorant and tell me why I am wrong, directly.

Oh, and saying things like domains are not intellectual property, will
not cut it, as it is not factual. 

As in: You are wrong.

Also, telling me that "the courts" do not agree with me that domains are property, is similarly incorrect.

So, do you have anything factual or positive to contribute so that if I am truly ignorant I could educate myself and improve to become a better person?

Andre

---

From: "John Levine" <[email-masked]>
Date: 21 Dec 2016 00:02:37 -0000

>in favor of documenting it.

I would really prefer that the IETF not embarrass itself with a rerun
of the NAT fiasco, in which TCP/IP purists yelled and screamed and
insisted that NAT was evil, while in the real world it solved (still
solves) real problems, and everyone implemented it in various not very
transparent or compatible ways.

RPZ is ugly but it solves serious real world problems, and it's going
to be used all over the world regardless of what we do.  Just this
week I heard from a friend at a largish company that one of their
suppliers got hacked with the trendy new malware that hides in web
page images.  Without RPZ, approximately all of their Windows users
would have been infected, with RPZ none of them were.

If we want to offer advice and perhaps technical twiddles on how to
deploy RPZ to minimize surprises and make it easy to find and fix
mistakes, that would be swell.  Insisting that it's stupid and wrong
confirms the not ill-founded impression that dnsop is out of touch
with the real world.

So, yes, we should adopt this draft.

R's,
John

---

From: David Conrad <[email-masked]>
Date: Tue, 20 Dec 2016 17:24:30 -0800

+1

Regards,
-drc
(speaking only for myself)

> On Dec 20, 2016, at 4:02 PM, John Levine <[email-masked]> wrote:
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 20 Dec 2016 22:10:20 -0500

+1 
I agree this is ugly as ugly can be but that ship has sailed. 
For interoperability sake lets just publish this with a note that says something like this;

This is documentation of fielded useful protocol.
This is ugly protocol and it copying it is strongly discouraged. 

    Olafur 
> On Dec 20, 2016, at 8:24 PM, David Conrad <[email-masked]> wrote:
> 
> +1
> 
> Regards,
> -drc

---

From: ac <[email-masked]>
Date: Wed, 21 Dec 2016 07:49:29 +0200

On Tue, 20 Dec 2016 22:10:20 -0500
> This is ugly protocol and it copying it is strongly discouraged. 

-1 
Seemingly, I am still the sole and only -1 although there are serious
concerns expressed by many about not only the ethics, but the eventual
rise of a non open and non free Internet and many other valid comments
speaking out against the direction this is leading and enabling.

I once made a very cool tool, it improved the life of many people as it
allowed anyone to take over any pc running a certain operating system
with the sole and great purpose of helping more users. It too was
published, improved, altered and distributed widely

RPZ is like that.

It solves a serious problem and helps and is in wide use.

Quite obviously this draft is going to be published. I hope that by
eventually speaking out I have caused some people to think about what
they are doing, whom they are enabling and what this will be used for.

I also hope that what Olafur Gudmundsson said, may be considered and I
am very much +1 for that.

Just to explain my strong reactions somewhat better:

Look at the email headers of my email, I am an African.

My concerns are real, they are valid. I am not just some troll or
whatever sitting somewhere in his mothers basement and thinking
up new ways of wasting your bits. I am a dev/sys/ops with decades of
experience.

Consider that the following is very possible:

===
RPZ will be legitimized by this draft, it will be used and living human
beings may actually die because of server software.
===

And, this is my final word on this, I apologize if anyone feels that I
have wasted their time or offended them in any way. This was never my
intention.

Andre

---

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

On Mon, Dec 19, 2016 at 10:38:46AM +0100,
 bert hubert <[email-masked]> wrote 

> By this token any firewall is censorship and lies. Yet we still use

No, blocking a communication is harsh but is not a lie. Returning HTTP
code 451 (RFC 7725) is not a lie, the HTTP server clearly says "this
is censored".

In the case of the DNS, in the absence of a rcode equivalent to 451,
modifying the answers of the authoritative name servers is a lie. But
some are more or less serious lies:

* returning SERVFAIL is a mild lie (it is close from the behaviour of
  a firewall blocking communications, and it is compatible with
  DNSSEC)

* returning a false IP address is a very serious lie. This is what
  phishers and other miscreants would like to do, while we are
  supposed to defend the integrity of the DNS.

The draft allows both, and does not warn about the severity of the
different possible lies.

---

From: Tony Finch <[email-masked]>
Date: Thu, 22 Dec 2016 11:18:37 +0000

Stephane Bortzmeyer <[email-masked]> wrote:
> some are more or less serious lies: [snip]

I think it's wrong to look at this only from the point of view of protocol
signalling without taking into account the wider context.

For example, a web server can return a 451 response whose content conceals
from the end user that any censorship has occurred - the browser won't
make the HTTP status code clear. (For a non-malicious example, try
spotting the 404 on Wikipedia's "not found" page.)

In an RPZ deployment, if the substitute IP address is a hosts a web site
that explains the reason for the block, the admin is not trying to conceal
anything or mislead anyone, so it isn't a lie.

Protocol signalling can help, but it is a relatively trivial matter
compared to how the blocking technology is explained to the people who are
affected by it.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Lundy, Fastnet: West backing southwest later, 5 or 6, increasing 7, perhaps
gale 8 later. Rough or very rough. Showers. Good.

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 22 Dec 2016 15:36:38 GMT

> From: Tony Finch <[email-masked]>

> > some are more or less serious lies: [snip]

SERVFAIL signaling DNSSEC validation failure is the equivalent to an
HTTP 4yz failure status.  Neither is a full and open disclosure to end
users that censorship has occurred, because in both cases end users
only understand that the internet is broken.

But on the real Internet, HTTP 4yz results do not signal censorship,
because great firewalls, HTTP(S) proxies, and compliant PKI CAs are
used for invisible censorship, content injection, etc.

> anything or mislead anyone, so it isn't a lie.

Yes, please see the endlessly repeated references to walled gardens
in the draft.  A good way to use RPZ is to rewrite IP addresses to
local walled gardens.  ISPs do that now to reduce help desk costs.

> compared to how the blocking technology is explained to the people who are

I don't agree.  While my Aunt Mildred might understand the instructions
of a walled garden the next time she infects her computer, she'll never
understand RPZ, HTTPS proxies, or even firewalls.  Even if she had the
wit, she lacks the interest.

More important is that while DNS and HTTP lies can be used in open,
transparent, and virtuous ways, they won't be in the cases that justify
concern.  Perhaps that is why among the thundering about ethics, human
rights, honesty, evil, and that the draft must never ever in a million
years be accepted without warning text, no text has been proposed.  I
do not see how a principled stand for DNS honesty could accept any
warning text (or protocol signalling).

A better, more realistic, and more honest parallel to the concerns
about RPZ is the fight of governments against encryption.  RPZ and
encryption are just ideas.  It does not matter at this point whether
they might do more harm than good.  You can no more stop governments
and corporations from using DNS lies than governments can stop the use
of encryption.  They can't suppress the arithmetic of public key
encryption any more than you can make DNS server operators forget the
creative use of local zone files or keep all of the millions of code
jockeys like me from writing messaging apps and evil DNS code.  All
that you might do is to make encryption and RPZ less available for good.

Vernon Schryver    [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Thu, 22 Dec 2016 12:10:59 -0500 (EST)

> only understand that the internet is broken.

When using HTTPS, I can tell the 4xx failure is from a legitimate source
(the publisher) or a middle man proxy/filter system.

A SERVFAIL (or BOGUS/INDETERMINATE answer if chained to my own resolver)
does not tell me if this came from a legitimate source or an intermediary.

> used for invisible censorship, content injection, etc.

Which is why we now have Certificate Transparency ("trans" working group)
in RFC6962 and soon 6962bis, and DANE/TLSA. These are IETF efforts to
ensure that we can see a distinction between (optin) censorship and
MITM attacks.

> wit, she lacks the interest.

This is a red herring. No one is suggesting any visible changes for
Aunt Mildred. But what we do want is for experts to be able to determine
the type of censorship and the actor involved. So we have
accountability.

> warning text (or protocol signalling).

Some of us were not advocating for such text, although some text is surely
appropriate for the Security Considerations or Privacy Considerations
sections. Instead, I advocated for simple accountability by ensuring
the censored are able to determine the censor.

The IETF has undertaken some responsibility with respect to internet
protocols and their impact on society. If you want the IETF stamp of,
approval, those are the implications.

Paul

---

From: "John Levine" <[email-masked]>
Date: 22 Dec 2016 17:59:24 -0000

>wit, she lacks the interest.

Users do strange things.  People at large mail systems tell me that
their users constantly take obvious phishes and 419s out of the spam
folder and respond to them, so the mail operators do things like
rewriting the mail to make the links unclickable even if it's
moved back into the inbox.

If we make a mutant RPZ that signals when something's rewritten, I can
promise that some clever person who imagines that RPZ is 99%
censorship and 1% anti-malware, rather than the reality which is the
other way around, will write a "free speech resolver" that undoes the
changes so the malware goes straight into the user's browser.  Then,
of course, the users will blame us for not protecting them from
cryptolocker.

As many people have pointed out, censorship happens with or without
RPZ, and it is pure hubris to imagine that anything we do or don't do
with RPZ will change that.  On the other hand, we've seen plenty of
reports from operators with actual experience of RPZ protecting their
users from malware.  So let's do something pro-user for a change.

R's,
John

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 22 Dec 2016 18:38:29 GMT

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

> sections. 

I don't understand.  Do you think more text needed?  If so, please
provide samples.

>           Instead, I advocated for simple accountability by ensuring

Please say whether (and perhaps why) the added additional section SOAs,
DNSSEC validation failures, and comparing DNS results from multiple
recursive servers are insufficient.  Please note that if they are
insufficient and your simple accountability is required, then the RPZ
draft cannot be fixed.  This is not protocol development task; it is
a purely descriptive job.  RPZ fixes, improvements, or replacement
must wait for another document.

> approval, those are the implications.

Please specify, preferably with proposed words, the changes to the
draft that are necessary for the draft to published or say that you
think that the RPZ draft should not be published.

Please note again that we are talking about the protocol and mechanisms
described in the current draft.  Adding EDNS0 bits, new rtypes, and
moving RRsets to the authority section might make a better and more
acceptable document, but that document would not describe the protocol
and mechanisms at issue.  If the mechanisms and protocol now described
in the draft are unacceptable, then no document that describes them
can be acceptable.