[RPZ] Promoting RPZ: feedback request

[Joe St Sauver]

Hugo Connery <hugonautical at gmail.com> asked: 

#I wish to gather feedback from the interested community
#about which efforts should be prioritized for encouraging
#greater uptake of RPZ.

>From my myopic POV, the issues that are deterring uptake RPZ are:


(1) RPZ suffers from naming issues. The key concept is that you can
filter bad sites via DNS, but (you'll laugh), many people don't know
what DNS is. Infographics are needed. A better name's needed (but
don't ask me, I'm not a communications guy)


(2) Limited number of publicly-available RPZ data sources. If you
want to increase uptake of RPZ, increase the amount of data that's
available. Data drives adoption more than anything else.

One model that I like for this is the sort of thing that's used
for some security projects that have both a paid/premium tier,
and a free tier: the paid/premium folks who are willing to write
a check get stuff hot off the press. Those of us who are poor
as a church mouse, get free access to the same thing N days 
later. (While it can be frustratng to wait N days, getting it 
even N days late is still typically FAR better than nothing,
and once you get used to it/hooked on it, many free riders end
up upgrading to get the premium as-it-happen releases, anyhow)

Oh, and why don't more people offer some sort of RPZ data? I think
at least some may be worried about litigation.


(3) Some may also worry that RPZ is related to that SOPA thing, and will
be used in non-consensual ways against them, perhaps blocking sites
that they DO really want to visit. People need to be reassured.


(4) The potential for false positives. A paranoid/practical worry is 
that someone's going to accidentally break something they shouldn't. 

At one point I started working on an invitational meeting 
dedicated toward addressing three all-too-often neglected questions
related to blocklists:

a) handling removal of stale data (hypothetically, assume you have a
block list that lists domains you've seen inj spam; you put the host 
IPs in the blocklist based on what you see, but how do you decide 
when to take them OUT?) 

Some people maintain a fixed size list, and do FIFO, reasoning that 
if a domain is (still) bad it will eventually get seen again, and get 
relisted, given good enough network instrumentation. Others allow 
anyone to request removal, again reasoning that anything bad will 
soon show up again and can always be thrown back in. Others just 
list stuff for a fixed tranche of time (perhaps a week) and then 
automatically remove it then. Others may be willing to remove stuff
that no longer resolves, but how are we to interpret SERVFAILs, say?
Yes, you could try to look up domains in whois to see if they're
gone, but that's rate limited (or may be non-existent for some ccTLDs)

Point is, this is all really pretty primitive.


b) Deconflicting/understanding/automating collateral damage assessment

By this I mean that even if the world's worst evil was on www.google.com
(not that I think it is) I don't think you could list it (ditto many 
other highly popular sites) -- the collateral damage would just be too 
severe.

The process of identifying stuff that's on your favorite top-N list of 
popular sites is easy, but what about stuff in regions where the top ten 
most popular sites may not be well tracked by mainstream favorite 
site tracking efforts?

Yeah, I know, reputation is hard. Still, you need to do it, and do it
right, for people to be willing to trust your data.

c) systematically handling augmentation of datasets from initial seed
data (e.g., hypothetically given an evil domain, what ELSE should also 
get followed and listed?) It's terrific if you can protect me against
potential future reuse of previously seen badness, but I want 
you to ALSO have a good enough crystal ball that you can protect 
me against related badness that is tied to previously observed
badness, too. 

If you deal with these three questions, the value of the data you serve
via RPZ increases immensely, increasing uptake.


(5) Product integration. Yes BIND and some other DNS server software
supports RPZ, but you need to get support for it even in obscure 
products you really wish didn't exist. Everything needs to support it.

What's already integrated also just needs to be dead bang simple to 
enable for the most common cases (tick a check box, or uncomment a 
line in a config file, tops)


(6) Testimonials. You need happy glowing faces telling the world about
how doing RPZ has helped eliminate infections and reduced help desk
calls, etc. Nothing horrible happened. It was easy. No one complained.
etc., etc., etc. 

We're herd animals, so let's hear some happy sounds from the rest of the 
herd.


(7) Make sure you're reaching the right audience. Presentations to network
engineers are great, but these days, many network engineers don't do DNS.
You need to reach the people who DNS. You also need to make sure that
the policy folks don't have a freak out. You definitely want to reach the
security community, and the help desk people, who see the fallout when
DNS is used to successfully attack users.


Anyhow, there's at least a few ideas for your consideration.

Regards,

Joe St Sauver (joe at oregon.uoregon.edu)
http://pages.uoregon.edu/joe/

Disclaimer: all opinions my own.