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

From: Scott Schmit <[email-masked]>
Date: Sat, 7 Jan 2017 17:54:56 -0500

On Thu, Dec 29, 2016 at 04:38:26PM -0000, John Levine wrote:
> >> Please see the previous gazillion messages from people who are using
> >> RPZ in production to keep malware away from their users.
> >> 
> >> Also see the previous gazillion messages noting that governments do
> >> all sorts of DNS censorship now and don't need RPZ.
> >> 
> >> Could you explain in more detail why you don't believe operators will
> >> continue to use RPZ to protect their users, and why you think hostile
> >> actors will do things with RPZ that they couldn't do now?
> >
> >I was specifically asking about the redirect/record replacement
> >behavior, not the nxdomain/blocking behavior.
> 
> Providers routinely use sandboxing to quarantine infected users both
> to protect their other users (malware can't contact C&C) and to force
> them to do something about it, since they can't see anything other
> than web sites with cleanup tools.  
> 
> I've talked to providers who tell me that this is the least bad way
> they've found to get their users to clean up infected boxes.  Even if
> a provider could afford to calli them on the phone, it doesn't work,
> first because users not unreasonably think it's a scam, and second
> because the malware doesn't bother them, only other people, so they
> blow off advice to fix it.

Thanks for explaining the use case.

> So I reiterate the same two questions.

Ok.

> >> Could you explain in more detail why you don't believe operators will
> >> continue to use RPZ to protect their users

I believe you that RPZ is well-intentioned, and I'm sure that operators
already using RPZ will continue to do so until it stops working or a
better method is available.

Eventually, if DNSSEC verification on endpoints becomes widespread,
operators will need to turn to other means or break DNSSEC in these
cases (but redirection will stop working).

> >> why you think hostile actors will do things with RPZ that they
> >> couldn't do now?

For the very reasons that the authors want to make this an RFC -- RPZ
isn't interoperable between DNS resolvers today.  Once this RFC is
published, it's clearly hoped that RPZ will be more interoperable and
thus widespread.

It's true that countries can legislate anything they want, and the
publication (or not) of an RFC won't change that.

But the enforcement of laws costs resources, and resources are finite --
so a country passing laws requiring network operators to filter and/or
redirect will have no choice but to prioritize enforcement of such laws
against other needs.

There are already plenty of examples of countries limiting their
enforcement of laws in recognition of implementation/enforcement costs.
(For an example, see Richard Clayton's message on Dec 29.)

If the implementation of laws is expensive, enforcement will also be
expensive.  If implementation of the law is cheap, enforcement is also
much more cheap, and such laws consequently become more attractive.
Having laws that cannot be effectively enforced on the books is
certainly possible, but I suspect countries avoid it to maintain their
credibility.

RPZ being interoperable would appear to make implementation of
filtering/redirection laws extremely cheap.  Previously, the government
would need to make a list of blocks and/or redirections and distribute
that list to network operators in some fashion.  By default, this would
probably be via some kind of document which would then need to be
translated into vendor-specific block/redirect lists.  This is slow and
expensive.  Then, to enforce that these lists are being used, officials
of the government would need to go around and check that the lists are
being used and kept up to date.  To do better, the government would need
to define some kind of standardized format and get its use implemented.
This isn't cheap either.

If RPZ becomes interoperable (it doesn't matter if it's "standard",
interoperability is standard enough), the government can just mandate
use of RPZ and maintain the block lists directly.  They can monitor that
ISPs are consulting the RPZ in real-time, so enforcement is trivial.
(Yes, the ISPs can query the list without enforcing it, but (a)
information about what blocked domains are being accessed is useful and
(b) that's no harder to check for, so it's irrelevant to the trade-off).

Rich and highly-motivated governments will probably operate the same
before and after RPZ becomes interoperable (though operating costs could
go down, freeing resources for other programs or better enforcement),
but other countries will find it easier to implement blocking and/or
redirection in their country, increasing the motivation to do so.

The blocking behaviors of RPZ will increase the load on networking
infrastructure if the blocked addresses are DNSSEC-signed and endpoints
validate the signatures.  The redirection behavior of RPZ breaks in the
face of DNSSEC validation if the records are signed, so it would be in
the interests of a country that really wants the redirects to break all
DNSSEC.  Then the end user faces a choice: no DNSSEC or no Internet.
They could try to use VPNs, but RPZ makes them easy to block nationally
once discovered as well as easier to find users attempting to use them.
(And if they're accessed by IP, that's even easier to block.)

Setting aside how governments may choose to use RPZ, there are security
risks to RPZ's deployment.

Without RPZ, malicious actors that want to effect large-scale
redirection of users would need to seek out the recursive resolvers of
their endpoints and subvert them all.  With RPZ, they only need to find
the comparatively fewer RPZ servers and subvert them instead.  If the
location of the RPZ server is advertised (for accountability and network
diagnostic purposes), then these addresses become available for
malicious actors to seek out and attack.  The redirection capabilities
of RPZ are especially interesting to malicious actors, as they can
become a means to take over a competing botnet's C&C network or redirect
users to malware.  If the location of the RPZ servers is hidden,
diagnosing network problems becomes much more difficult.  This has the
net effect of making the DNS less reliable.

The widespread use of captive portals has already made implementation of
endpoint DNSSEC validation difficult and has essentially inhibited its
implementation.  I believe that widespread use of RPZ could do the same.

All the above leads me to believe that RPZ is harmful to Internet
security and infrastructure, however well-intentioned it may be.

I do not support adoption of this draft.

-- 
Scott Schmit

---

From: Barry Raveendran Greene <[email-masked]>
Date: Mon, 9 Jan 2017 11:34:57 +0800

> On Jan 8, 2017, at 6:54 AM, Scott Schmit <[email-masked]> wrote:
> 

Bad guys are not going to take the time to use DNSSEC to build a path that can be followed to their place of operations.

So the argument that “DNSSEC deployment will obsolete the industry need for RPZ” does not match reality.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 8 Jan 2017 23:49:17 -0500 (EST)

> Bad guys are not going to take the time to use DNSSEC to build a path that can be followed to their place of operations.

It is actually the other way around. If an end-node performs DNSSEC
validation, it can only see RPZ modified answers as an attack. It is
in the interest of RPZ to give such clients the confidence that the RPZ
produced answer is not an attack but a handbreak action in the user's
interest.

I won't re-iterate my previous suggestion on how this could be done. See
the archive.

Paul

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Jan 2017 09:19:37 -0500

> produced answer is not an attack but a handbreak action in the user's

I think you missed what Barry was saying: you are correct that an end-node that performs DNSSEC validation will see RPZ on a domain that is signed as an attack.   The point Barry is making is that this only matters if they sign their zones, and they won't, because doing so produces a clear audit trail leading back to them.

I think this is actually not true: why is a DS record any more of an audit train than an NS record?   Nevertheless, let's be clear on what RPZ does and does not do.   I think the main reason attackers won't sign is that it's too much trouble, and provides no real benefit in the presence of an effective RPZ block.

Your point here, that in order for RPZ to function in the presence of widespread DNSSEC signing, there has to be some mechanism for authenticating RPZ answers _as_ RPZ answers, doesn't seem clearly true.   It may be perfectly functional for RPZ answers to look like an attack.   But it's certainly worth considering, and has been talked about earlier in this thread.   The question is, does it make sense to add code to the validating resolver to detect and validate an RPZ block, so the user can be informed that a block occurred, and who did it?   Would people actually code this up?   Would it be better or worse?

To me it seems like a bad idea: it's a larger attack surface, more complexity, a single point of attack: if I can compromise the RPZ keys, I can make an attack look like protection to the end user.   Ultimately, if we were to specify a solution for this, I think we doul actually be doing something harmful to human rights.   Isn't blocking the domain enough?

---

From: Paul Wouters <[email-masked]>
Date: Mon, 9 Jan 2017 10:14:27 -0500 (EST)

On Mon, 9 Jan 2017, Ted Lemon wrote:

> I think you missed what Barry was saying: you are correct that an end-node that performs DNSSEC validation will see RPZ on a domain that is signed as an attack.   The point Barry is making is that this only
> matters if they sign their zones, and they won't, because doing so produces a clear audit trail leading back to them.

Apple is getting ready to drop port 80 support. unsigned/unencrypted
transports are dying. I hope we are moving to a word where DNS without
DNSSEC will also be seen as bad. So yes, I am assuming in the future,
attackers will have to sign DNS and that domains without DNSSEC are seen
as "rogue domains that don't have clear audit trails".

> I think this is actually not true: why is a DS record any more of an audit train than an NS record?

Because it proves ownership of the domain. My nohats.ca DS record cannot
be modified by the UK ISPs forced to filter my domain. But they can
spoof NS records. See the recent discovery that Heathrow Airport runs a
MITM TLS server on torproject.org. Do we want them to run RPZ where they
can disappear torproject.org alltogether? No. Do we want them to run RPZ
to prevent travelers from getting malware installed? Yes.

>   Nevertheless, let's be clear on what RPZ does and does not do.   I think the main reason attackers won't
> sign is that it's too much trouble, and provides no real benefit in the presence of an effective RPZ block.

It's fine for "attackers" not to sign domains. That is not the point.

> Your point here, that in order for RPZ to function in the presence of widespread DNSSEC signing, there has to be some mechanism for authenticating RPZ answers _as_ RPZ answers, doesn't seem clearly true.   It
> may be perfectly functional for RPZ answers to look like an attack.   But it's certainly worth considering, and has been talked about earlier in this thread.   The question is, does it make sense to add code
> to the validating resolver to detect and validate an RPZ block, so the user can be informed that a block occurred, and who did it?   Would people actually code this up?   Would it be better or worse?

To me that is quite obvious "yes". If we allow the DNS protocol to
randomly rewrite DNS, then why _do_ we have DNSSEC?

> To me it seems like a bad idea: it's a larger attack surface, more complexity, a single point of attack: if I can compromise the RPZ keys, I can make an attack look like protection to the end user.  

Excellent! It means if the RPZ/DNS provider screws up, they are
accountable. And they will properly maintain such systems that
are golden opportunity for hackers to compromise. Also, the
danger you are describing "I can make an attack look like protection to
the end user" is exactly what the current RPZ spec already allows!
I guess you really meant to say "a compromised RPZ system can unblock
a malicious and previously blocked side". Well yes. You are describing
a weakness, not a strength, of the RPZ solution.

> Ultimately, if we were to specify a solution for this, I think we doul actually be doing something harmful to human rights.   Isn't blocking the domain enough?

Just blocking the domain is "too much". And in my view that _is_ the
human rights issue.

If we change this discussion and replace DNS and DNSSEC with BGP and
RPKI, would you still think it is fine to allow random parties to
change BGP announcements in a world of secure BGP so that users can
be prevented to go to certain IP ranges?

Paul

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Jan 2017 10:48:55 -0500

> as "rogue domains that don't have clear audit trails".

It remains the case that most service providers at present appear to believe that PKI is enough, and they don't think DNSSEC is worth the trouble.   Like you, I look forward to the day when this is no longer true, although I don't look forward to the attack that changes peoples' minds about this.

> to prevent travelers from getting malware installed? Yes.

We are talking at cross purposes.   We agree that the DS record proves ownership of the zone.   But it doesn't provide any more of an audit trail in terms of zone setup than does an NS record.   In terms of accurately identifying who set up the zone, it is completely useless.

> randomly rewrite DNS, then why _do_ we have DNSSEC?

Again, not the point I was making.   Of course we want the resolver to do validation.   The question is, do we want the resolver to have code in it to validate who did the RPZ block.   I think this would be a really bad idea, and would be seriously damaging to human rights.

> a weakness, not a strength, of the RPZ solution.

You are thinking like a IETF geek.   The average end user will know nothing of this.   To them, it will simply be the case that their computer says "this is a malware site."   They will not see the audit trail.   It doesn't matter if the ACLU can detect the attack: they could have detected the attack without the signature, and most likely had a clear idea of who did it.

What matters is that we have no provided a way for malicious site operators to lie to end users, who will not be able to detect the lie.  To be clear, the lie is "I am authorized to block zones on your behalf."

> Just blocking the domain is "too much". And in my view that _is_ the

We disagree here.   I have seen way too many people screwed over by malware to think that preserving a perfect uncensored view of the DNS is more important than blocking malware.   As long as we can tell that we have been given a filtered response, I think we have the best possible compromise, and if sites are not willing to put in the effort to sign their zones, that is their problem.

> be prevented to go to certain IP ranges?

If that IP range is being operated by a malware site or for example is going to redirect all of my traffic through a country that is sniffing my packets for intelligence purposes, then yes, it should be possible for the infrastructure to prevent the broken route from being installed, regardless of whether or not it has been signed.   This is the distinction between authentication and authorization that we all know so well: just because something is _authentic_ does not mean that it is authorized.

Taking that very clear distinction and turning it political is not helping anyone.

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 9 Jan 2017 15:51:31 GMT

> From: Ted Lemon <[email-masked]>

>                             I think the main reason attackers won't sign =
> is that it's too much trouble, and provides no real benefit in the =
> presence of an effective RPZ block.

Yes, but there is a reason more important than RPZ for miscreants to
sign their attacks.  It is the same reason that plenty of spam is sent
with valid STARTTLS, DKIM, and/or SPF signatures and why spammers were
the first significant SPF publishers.  A large fraction of their targets
support the silly notion that authenticated strangers differ from other
strangers and that a certificate of authentication from a third party
is a bankable guarantee of virtue.

>                   The question is, does it make sense to add code to the =
> validating resolver to detect and validate an RPZ block, so the user can =
> be informed that a block occurred, and who did it?   Would people =
> actually code this up? 

That's the rub.  RPZ has multiple independent interoperating
implementations, is widely deployed, and is in common use because the
customers of DNS recursive server implementators initially welcomed
it and now demand it.  Those customers are operators of DNS resolvers,
especially large operators who pay real money (as opposed to hot air)
for DNS server code, hire people to operate it, pay the secondary
bandwidth, training, bug and other costs, and pay for RPZ blacklists.

Where is the equivalent demand among resolver operators for doubling
the size of DNSSEC responses to contain both the original and the RPZ
rewritten rrsets including RRSIGs, and to pay the implied costs in
bugs, CPU cycles, bandwidth, training, security, etc?  People pay money
for code implementing what the draft describes, but as Ted Lemon asks,
who would pay for the suggested code in resolvers?  If it were free,
who would pay the costs of turning it on?
(You'd also need to convince RPZ blacklist providers to include RRSIGs
in their feeds, because you'd need signatures on rewritten responses.)

Such considerations are why so many users are behind resolvers that
validate DNSSEC but practically no domains are signed.  DNSSEC is a
good thing for operators of DNS clients, both resolvers and stubs, but
it is far more cost than benefit to operators of authority servers.
That's why we have the enduring, very discouraging picture at
http://scoreboard.verisignlabs.com/percent-trace.png
http://scoreboard.verisignlabs.com/

Such issues might also be why some of the most emphatic critics of RPZ in
this mailing list nevertheless send their critiques from unsigned domains.

Note that the vast majority of clients of RPZ rewriting resolvers are
stubs that don't do validation but trust header bits saying that a
resolver operated by a third party did the validation.  I think that's
wrong, evil, nasty, unethical, a Major Human Rights Issue, and blah
de blah de blah, but it's also something no one seems willing and able
to change.

Vernon Schryver    [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Jan 2017 12:05:16 -0500

> de blah de blah, but it's also something no one seems willing and able

*slow clap*

---

From: Philip Homburg <[email-masked]>
Date: Mon, 09 Jan 2017 20:53:30 +0100

>See the recent discovery that Heathrow Airport runs a

Just my crystal ball:
1) If the traver's laptop/phone uses Heathrow Airport resolvers then Heathrow
   Airport can mount a denial of service on DNS. So it does not matter if the
   malware zone is signed or not. If Heathrow Airport modifies the reply the
   traveler will be protected.
2) It makes sense to do local validation with something like getdns. If such a
   local validating resolver notices that DNSSEC validation fails ("Roadblock
   Avoidance") it may contact auth. DNS servers directly.
3) Heathrow Airport can move to deep packet inspection and also block
   direct access to malware DNS.
4) DNS is not really private so Google may offer their DNS services over HTTPS.
5) Governments may force Google to block popular sites, so users switch to
   other DNS resolvers, again over HTTPS.

After step 5, any benign malware filtering options are probably lost.

In that sense I don't care that much about the more philosophical arguments
arguments against rpz. If you care about DNS, run a local DNSSEC validating
resolver that does roadblock avoidance and possibly falls back to 
TLS or HTTPS to some trusted resolver.

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 9 Jan 2017 23:38:14 GMT

> From: Philip Homburg <[email-masked]>

>4) DNS is not really private so Google may offer their DNS services over HTTPS

See https://developers.google.com/speed/public-dns/docs/dns-over-https
but I don't know how clients bootstrap that API without classic DNS.

Regardless of that, what if Heathrow Airport deploys HTTPS proxies to
block child porn, drug, terrorist, and malware web pages as well as
attempts by corrupted laptops and smart phones to bypass blocks on
port 53 and reach evil or merely unfiltered DNS/HTTPS servers including
those run by Google?

> TLS or HTTPS to some trusted resolver.

Everyone should do that, if necessary without knowing they're doing
it, such as with the help of validating resolver code in broswers.
Something like that is required to stop the fraud that is commercial PKI.
(Google's two alternatives to DANE are great for the Alexa 500 and
maybe the Alexa 5000, but useless or worse for the Alexa 100,000,000.)

   ..............

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

] But I think the document itself is very useful, so it would be nice if
] it's made more publicly available in other form, e.g., some
] white-paper kind or at a popular blog site.

That will happen whether or not the text gets an RFC number.  (If it
doesn't get a number, of course I will remove the IETF mumbo-jumbo.)
The current de facto standard status of RPZ suggests finding sufficient
popular web sites for publication is not an issue.

Disclaimer: Many people including the other author want the draft to
get an RFC number.  But my considered reaction the threats to not
publish, the demands to not publish without what I see as ill conceived
or worse fixes, and various other sentiments is more like
"Please don't throw me in the briar patch."
https://www.youtube.com/watch?v=S7tyhpWiZyM

]                                 its not just ugly 

Yes, RPZ is a nasty, ugly, evil kludge that would not exist if I were
in charge of the Internet.

]                                                   but also has some
]   inherent flaws, such as that not all domain names can be represented
]   due to length limitation.

Yes, but do you know of a real life example cannot be rewritten because
the RPZ trigger name would be too long?

]                              In fact, not all existing implementations
]   of RPZ-like feature use this form as the primary way of rule
]   configuration (unbound is one example I happen to know of, and from
]   a quick look knot resolver also seems to adopt its own configuration
]   syntax).

Distributed blacklisting is one of or the most powerful aspect of RPZ.
I think (perhaps mistakenly) that the new blocking mechanism in
Unbound 1.6.0 lacks that aspect.

In addition, there is an RPZ patch for Unbound versions 1.5.4 through
1.6.0 that uses a separate daemon that acts like a slave master for
policy zones using AXFR/IXFR/NOTIFY.  However, I stopped maintaining
and deleted the patches for version 1.5.4 through 1.5.8 long ago.
Another caveat is that the work was for hire and so the daemon and its
interface .so are not open.  The patches to Unbound are open and have
been offered to NLnet Labs.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 10 Jan 2017 04:30:55 +0000

On Mon, Jan 09, 2017 at 03:51:31PM +0000, Vernon Schryver wrote:

> stubs that don't do validation

So far, and at present, correct.  Validating resolvers (unbound
and the like) are seeing deployment on servers first, including
some of the caches queried by said stubs.  (Far from representative
of course, My home OpenWRT router runs a validating unbound.)

> but trust header bits saying that a
> resolver operated by a third party did the validation.

But not this.  The stubs in question are generally security oblivious,
and don't in any sense "trust" that any validation happens upstream.

> I think that's

And this part is both irrelevant, and IMHO inappropriately dismissive
of legitimate concerns expressed upstream.  We won't all agree,
but we should be held to a higher standard on the manner of the
discourse.

--
	Viktor.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 10 Jan 2017 12:17:48 +0100

>but I don't know how clients bootstrap that API without classic DNS.

The nice this about Google is that they are too big to block.

It is not a problem to use plaintext DNS to connect to Google because the
CA system and possibly DANE will protect the TLS connection.

>port 53 and reach evil or merely unfiltered DNS/HTTPS servers including

I'm not sure what 'HTTPS proxy' means in this context. If a public wifi
at an airport can decode TLS traffic then we have a serious security hole.
(Of course SNI is a problem. Hopefully TLS 1.3 will improve that)

But the bigger problem is that most users don't really care about the
difference between a public wifi operated by an airport and a public wifi
operated by a criminal. And maybe the criminal just took over the wifi
router at a respectable restaurant.

So an ISP can null route traffic to known bad destinations (though people
may switch to TOR to even deny an ISP even that option) but anything that
goes beyond that (ISP access to DNS, etc) also provides great opportunities
to attackers.

It doesn't really help much if an airport blocks malware but the bar next door
doesn't.  So for any mobile device, you have to secure the device anyhow.
Then this extra protection by ISP mostly becomes another attack vector.

So at least for mobile devices it makes sense to make sure that all 
traffic on the wifi interface is encrypted and we keep the ISP out of the
loop as much as possible.

---

From: "Ralf Weber" <[email-masked]>
Date: Tue, 10 Jan 2017 15:55:55 +0100

Moin!

> redirect will have no choice but to prioritize enforcement of such laws
I don't know if you ever where involved in law creation, but I can assure
you, being involved in lobbying lawmakers to make sensible laws and also
implementing redirection via DNS which is common in a lot of countries,
that lawmakers give a damn about how much it costs providers to
implement the redirection.

When implementing redirection via DNS I've seen every sort of possible
input thrown at me from snail mail to EBDIC text files, pdf, you name
it. The funniest case was one country that had different branches of
the government issuing block lists one with a word document over ftp
and the other with XML over https. I would love to have had a common
format then and not re-invent the wheel on every new case.

BTW all of these implementations where in what one would consider
democratic countries in Europe (The nice thing about the EU is even
if you have a EU directive you still get 27 different laws to follow
if you are a pan european provider ;-). My point here is if you don't
like redirection and blocking via DNS (which IMHO is much better than
mandating DPI - unless you are a DPI vendor ;-) get involved in
politics and try to change that at OSI layer 9.

None of the stuff we discuss here will change any law or mandated
redirection, nor will it change the efforts of lots of sysadmins and
security researchers using the discussed technology to block bonnets
and bad guys to not infect subscribers.

It just would be nice if these poor sysadmins had some common tools,
but as said we've solved problems without that until now and as others
said RPZ actually might not be the best tool to express DNS policy
configuration, but given the current state of the discussion I have
serious doubt that the working group would consider working on that
at all.

So long
-Ralf