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

[David Conrad]

Andre,

On Dec 20, 2016, at 9:49 PM, ac  wrote:
> 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.

No, it's not.

There is a rather striking difference between a tool I choose to deploy on my 
network that helps protects my users from external threats and a tool that 
allows an external entity to intrude on my users. If you do not understand 
this, there is a bigger problem to address.

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

RPZ is legitimized by its use, not by the documentation describing that use.  
Proverbially sticking your head in the sand does not remove the carnivores that 
are eyeing the rest of your body.

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

It would appear your intention is to school the ignorant masses in the errors 
of their ways. Personally, I'm always a bit nervous when someone decides they 
know what's best for me or the folks I might provide services for.

Regards,
-drc
(speaking only for myself)



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Vernon Schryver]

] From: Mukund Sivaraman 

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

 ..


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

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?


Vernon Schryverv...@rhyolite.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mukund Sivaraman]

On Fri, Dec 30, 2016 at 11:45:23AM +, 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


signature.asc
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mukund Sivaraman]

Hi Vernon

On Fri, Dec 30, 2016 at 11:45:23AM +, Vernon Schryver wrote:
> > From: Mukund Sivaraman 
> 
> > > 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
> 
> 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.
> 
> 
> > > Some minor nits:
> > >
> > > - 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?
> 
> 
> > > - Maybe include that "zz" label in v6 encoding can also appear on
> > > - 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.

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.

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

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 

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

[Vernon Schryver]

> From: Mukund Sivaraman 

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

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.


> > Some minor nits:
> >
> > - 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?


> > - Maybe include that "zz" label in v6 encoding can also appear on
> > - 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.


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

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.


Vernon Schryverv...@rhyolite.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mukund Sivaraman]

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


signature.asc
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Vernon Schryver]

> From: Paul Wouters 

> Some of us were not advocating for such text, although some text is surely
> appropriate for the Security Considerations or Privacy Considerations
> sections. 

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

>   Instead, I advocated for simple accountability by ensuring
> the censored are able to determine the censor.

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.


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

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.


Vernon Schryverv...@rhyolite.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Wouters]

On Thu, 22 Dec 2016, Vernon Schryver wrote:


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.


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.


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.


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.


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.


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.


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.


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


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Vernon Schryver]

> From: Tony Finch 

> Stephane Bortzmeyer  wrote:
> >
> > 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: [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.


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

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.


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

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 Schryverv...@rhyolite.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

Stephane Bortzmeyer  wrote:
>
> 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: [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    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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John Levine]

>I hereby, with full knowledge and prior consent, *refuse* that my ISP
>(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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[sthaug]

> > adding complexity in the middle of any system increases the size of an
> > attack surface.
> 
> +1 This was described in detail several times (see for instance this
> report
> )
> and we already saw its consequences for the security and stability of
> the Internet
> 
> (in danish)
>  (in
> french)

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Stephane Bortzmeyer]

On Mon, Dec 19, 2016 at 10:38:46AM +0100,
 bert hubert  wrote 
 a message of 25 lines which said:

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

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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Stephane Bortzmeyer]

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

> adding complexity in the middle of any system increases the size of an
> attack surface.

+1 This was described in detail several times (see for instance this
report
)
and we already saw its consequences for the security and stability of
the Internet

(in danish)
 (in
french)



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Stephane Bortzmeyer]

On Mon, Dec 19, 2016 at 09:09:42AM +,
 Evan Hunt  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.



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John Levine]

In article  you write:

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

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

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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Scott Morizot]

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  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.
>
> (FWIW, I’m in favor of adoption, for precisely this reason.)
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Wouters]

On Wed, 21 Dec 2016, John Levine wrote:


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


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
isn't it.


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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John Levine]

>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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ray Bellis]

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[william manning]

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

On Mon, Dec 19, 2016 at 8:58 PM, william manning 
wrote:

> 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?
>
> On Mon, Dec 19, 2016 at 7:35 AM, Vernon Schryver  wrote:
>
>> ] From: Scott Schmit  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 
>>
>> > 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.
>>
>> 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 

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

[ac]

On Tue, 20 Dec 2016 22:10:20 -0500
Olafur Gudmundsson  wrote:
> +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 

-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


 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Olafur Gudmundsson]

+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  wrote:
> 
> +1
> 
> Regards,
> -drc
> (speaking only for myself)
> 
>> On Dec 20, 2016, at 4:02 PM, John Levine  wrote:
>> 
>>> "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.
>> 
>> 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
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[David Conrad]

+1

Regards,
-drc
(speaking only for myself)

> On Dec 20, 2016, at 4:02 PM, John Levine  wrote:
> 
>> "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.
> 
> 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
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John Levine]

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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[ac]

On Tue, 20 Dec 2016 07:49:59 -0500
Ted Lemon  wrote:
> On Dec 20, 2016, at 1:45 AM, ac  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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

On Dec 20, 2016, at 1:45 AM, ac  wrote:
> 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.

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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Jim Reid]

> On 20 Dec 2016, at 06:40, ac  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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[ac]

On Tue, 20 Dec 2016 01:23:10 -0500
"Allan Liska"  wrote:
> On 12/20/2016 at 12:31 AM, "ac"  wrote:
> > 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.
+++
> 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


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


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[ac]

On Tue, 20 Dec 2016 06:12:42 +
Evan Hunt  wrote:
> On Tue, Dec 20, 2016 at 07:30:43AM +0200, ac wrote:
> > You are quite correct, but the minute you answer questions for other
> > 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.
> 
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 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.
> 
> 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.
> 
imho DNSSEC is the way to go, it obviates the need for RPZ and for DNS
ethcis and many other issues.

Andre

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Allan Liska]

On 12/20/2016 at 12:31 AM, "ac"  wrote:
> 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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Evan Hunt]

On Tue, Dec 20, 2016 at 07:30:43AM +0200, ac wrote:
> You are quite correct, but the minute you answer questions for other
> 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.

> To rip the dam from underneath the duck: You cannot legally resolve a
> non google IP number as "google.com" just because your t 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 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  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.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[ac]

On Tue, 20 Dec 2016 04:56:06 +
Evan Hunt  wrote:
> On Tue, Dec 20, 2016 at 06:42:02AM +0200, ac 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.
> 
> 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.
> 
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 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 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





___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[william manning]

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?

On Mon, Dec 19, 2016 at 7:35 AM, Vernon Schryver  wrote:

> ] From: Scott Schmit  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 
>
> > 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.
>
> 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
> > built into the design.
>
> If it matters, please point out the words in the draft that prompt
> that mistaken notion.
>
>
> Vernon Schryverv...@rhyolite.com
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Evan Hunt]

On Tue, Dec 20, 2016 at 06:42:02AM +0200, ac 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.

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 -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[ac]

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Vernon Schryver]

] From: Scott Schmit  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 

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

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
> built into the design.

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


Vernon Schryverv...@rhyolite.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[ac]

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 +
Jim Reid  wrote:
> > On 19 Dec 2016, at 09:50, ac  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









___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[ac]

On Mon, 19 Dec 2016 10:59:57 +
Tony Finch  wrote:
> ac  wrote:
> > To legitimize the telling of lies and to define protocols that hides
> > 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.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[sthaug]

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

So do for instance BIND views.

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

This is, ultimately, always a local decision.

In "my" network I have at times returned incorrect answers to queries
for .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.

> I think that if people knew what we were talking about and
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

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.

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.

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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

ac  wrote:
>
> To legitimize the telling of lies and to define protocols that hides
> 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    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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[ac]

On Mon, 19 Dec 2016 10:59:31 +0100
bert hubert  wrote:
> On Mon, Dec 19, 2016 at 11:50:02AM +0200, ac wrote:

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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ralf Weber]

Moin!

On 19 Dec 2016, at 8:28, ac wrote:

On Mon, 19 Dec 2016 07:53:42 +0100
"Ralf Weber"  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.

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

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.


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.



this is exactly the same argument the authors of other software uses
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?

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.

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.


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.

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.


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


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?

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[bert hubert]

On Mon, Dec 19, 2016 at 11:50:02AM +0200, ac wrote:
> > 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?

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

> it is about so much more and you may need to look deeper into what this
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[ac]

On Mon, 19 Dec 2016 10:38:46 +0100
bert hubert  wrote:
> On Mon, Dec 19, 2016 at 11:24:33AM +0200, ac wrote:
> > 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.
> 
> 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. 
> 
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? 
> It is very much a protocol against phishing. 
> 

your reply does not answer the question?

Andre

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Jim Reid]

> On 19 Dec 2016, at 09:38, bert hubert  wrote:
> 
> So please realise this is something that people need. Best that they do it
> in a standardized fashion.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[bert hubert]

On Mon, Dec 19, 2016 at 11:24:33AM +0200, ac wrote:
> 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.

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.

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

It is very much a protocol against phishing. 

Bert

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[ac]

On Mon, 19 Dec 2016 10:11:11 +0100 (CET)
sth...@nethelp.no 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[bert hubert]

On Mon, Dec 19, 2016 at 09:09:42AM +, Evan Hunt wrote:
> On Mon, Dec 19, 2016 at 10:42:35AM +0200, ac wrote:
> > it still is never okay to lie and to deceive.
> > [...]
> > This is simply about ethics. 
> 
> 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.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Evan Hunt]

On Mon, Dec 19, 2016 at 10:42:35AM +0200, ac wrote:
> it still is never okay to lie and to deceive.
> [...]
> This is simply about ethics. 

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 -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[ac]

On Mon, 19 Dec 2016 09:16:28 +0100 (CET)
sth...@nethelp.no 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. 
> > In your example, ethically, it is a problem that should be
> > addressed on IP, not on DNS
> > 
> > It is never okay to tell lies.
> 
> Unfortunately the real world isn't that simple.
> 
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 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


/*
> 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

*/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[ac]

On Mon, 19 Dec 2016 09:16:28 +0100 (CET)
sth...@nethelp.no 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. 
> > In your example, ethically, it is a problem that should be
> > addressed on IP, not on DNS
> > 
> > It is never okay to tell lies.
> 
> Unfortunately the real world isn't that simple.
> 
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




> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[sthaug]

> > 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. 
> 
> In your example, ethically, it is a problem that should be addressed on IP, 
> not on DNS
> 
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[ac]

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


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

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.  

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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ralf Weber]

Moin!

On 19 Dec 2016, at 6:05, ac wrote:

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[ac]

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

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





___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Adrien de Croy]

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


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.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Scott Schmit]

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

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.

> > But it looks like the contents of this zone are intended to be kept
> > 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.

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.
> 
> I don't think so.

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.

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

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


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

Scott Schmit  wrote:

>

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



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.


> But it looks like the contents of this zone are intended to be kept

> 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    http://dotat.at/  -  I xn--
  zr8h punycode



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[ac]

On Sat, 17 Dec 2016 18:27:51 GMT
Vernon Schryver  wrote:
> > From: ac 
> > 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?
> 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

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
 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Scott Schmit]

On Fri, Dec 16, 2016 at 01:53:52PM -0800, internet-dra...@ietf.org wrote:
> 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.

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


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Vernon Schryver]

> From: ac 

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

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 Schryverv...@rhyolite.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[ac]

On Sat, 17 Dec 2016 08:05:36 -0500
Ted Lemon  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?


> On Dec 17, 2016 00:38, "ac"  wrote:
> > and so we all go down the slippery slope.
> > On Fri, 16 Dec 2016 13:53:52 -0800
> > internet-dra...@ietf.org 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.
> > >
> > > 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/
> > >
> > > ___
> > > DNSOP mailing list
> > > DNSOP@ietf.org
> > > https://www.ietf.org/mailman/listinfo/dnsop
> >
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
> >

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[ac]

and so we all go down the slippery slope.


On Fri, 16 Dec 2016 13:53:52 -0800
internet-dra...@ietf.org 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.
> 
> 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/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[internet-drafts]

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/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop