On Jan 8, 2017, at 11:49 PM, Paul Wouters <p...@nohats.ca> wrote:
> 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 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?

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

Reply via email to