[RPZ] Answering my own RPZ question

[Paul Vixie]

On 1/6/2012 1:18 PM, Emanuele Balla (aka Skull) wrote:
> On 1/6/12 12:28 PM, Jeff Chan wrote:
>> On Thursday, January 5, 2012, 11:20:32 AM, Paul Vixie wrote:
>>
>>> no. dnssec really is a get-out-of-jail-free card for malicious domain
>>> names. [...]
>>>  so, meanwhile, we'll use this "hole" in RPZ as an incentive to get
>>> more dnssec signing to happen, even if the signing is by bad people
>>> doing bad things with bad domains.
>> DNSSEC signing by bad guys (like SPF usage by bad guys) is a win
>> for the good guys since it helps identify bad guys.  If bad guy
>> keys can be identified, then their keys can be repudiated by the
>> good guys. 
> Except that bad guys can simply roll their new keys, one for each
> domain, the same way they currently do with anything else: it's not like
> they need to buy some certificate from a CA, they can do everything by
> their own at no cost.
>
> How are you going to identify the bad guy based on something he can
> choose and change at any time?
>
> IMHO there's no difference with plain DNS in this respect...

my opinion is the same. and the reason dnssec processing is superior to
policy processing is unrelated to the goodness of more signed domains,
even if those domains are malicious.

the spec is written like it is:

 3 - Subscriber Behavior

   RPZs must be primary or secondary zones. They can only be searched in a
   recursive server's own storage. By default, policies are applied only on
   DNS requests that ask for recursion (RD=1) and which either do not
   request DNSSEC metadata (DO=0) or for which no DNSSEC metadata exists.


...because from RPZ's point of view, if the querier could know we're
lying, we don't lie. the "could know we're lying" predicate is simply
that there is a signature for the truth and the client is indicating
dnssec readiness (DO=1).

very few stubs today set DO=1, so even if bad guys sign their domains,
this logic in RPZ won't make RPZ less operationally effective, even if
bad guys sign their domains.

the reason this approach may be raising eyebrows is that it's not
paternalistic. we're saying that if a requestor can handle dnssec and if
the domain owner can handle dnssec then there is no way to do policy
securely so we won't do it. this means RPZ is not a suitable mechanism
for enforcing national censorship laws (such as the proposed
SOPA-PIPA-PROTECTIP-COICA package now being debated in the united states
congress).

the fix is not to make policy enforceable in a paternalistic way, as in,
add signalling for "this isn't the truth, but you can trust me". rather,
the fix is to add signalling that allows the client to say, "i can
handle dnssec but i want to know not just the truth but what your policy
would be" and for the server to say "here is the truth and its
signatures, here is my policy and those signatures". the client can then
make an informed choice.

the informed choice by the client means they can decide to ignore policy
if they don't think their ISP is doing the policies they want, or they
can decide to pay attention to policy if they either trust their ISP or
they have switched to some other DNS provider who offers selectible
policy as a feature.

if you'd like to discuss this round-table fashion, i'll set up a
conference call number and i'll run a doodle poll on some dates and
times, inviting all members of this mailing list to participate. (signal
this to me privately, and i'll summarize.)

paul