[RPZ] Answering my own RPZ question

[Paul Vixie]

On Tue, 10 Jan 2012 13:43:29 -0500
Bill Owens <owens at nysernet.org> wrote:

> On Fri, Jan 06, 2012 at 06:34:10PM +0000, Paul Vixie wrote:
> > On 1/5/2012 7:20 PM, Paul Vixie wrote:
> > > ... we'll fix this some day, probably by adding a new EDNS option
> > > to allow a stub to signal its desire for policy information, and
> > > the recursive would return the truth, the dnssec metadata that
> > > validates the truth, and a signed indication of what the policy
> > > based answer would be. this will require SIG(0) signalling since
> > > servers do not otherwise have signing keys. and it's a long term
> > > project that will have to involve IETF. ...
> > 
> > this is work that opendns and google should be sponsoring and
> > participating in, since it will allow them to offer value added
> > services to known subscribers.
> 
> I read that article, and my first reaction to the excerpted paragraph
> was that it sounded a bit overcomplex. Would it be reasonable for the
> filtering resolver to default to returning the policy based answer in
> this situation, without additional signalling? In other words,
> overload DO=1 to indicate both "I want DNSSEC records" and "I want
> policy based answers, if any"?

given the fight over the meaning of DO=1, there's an argument to be
made that the situation could simply not get worse. however, i ask you
to consider as you evaluate the complexity of the proposal, that no
stub currently sets DO=1 ever, and even with DANE i expect that most
stubs will mostly not set DO=1 except when validating an X.509 cert,
and that fully ubiquitous end-to-end DNSSEC is a ways off from now.

in other words the economic impact of RPZ on malicious actors will not
be measureably less because of the DNSSEC exemption in RPZ than it
would be without that exemption or with a knob to turn off that
exemption. and since the purpose of RPZ or any other security device is
to open the loop that makes malicious actions profitable rather than to
protect every subscriber/customer/citizen, i think we're in the weeds
here. if a malicious domain is only usable by validating stubs because
all nonvalidating stubs will not have a get-out-of-rpz-free card, then
RPZ still succeeds because the underlying activity is still rendered
unprofitable.

> We'd run the risk of confusing queriers that aren't upgraded to
> understand the presence of filtering, although since the policy based
> answer will be returned without a signature, I think they'd naturally
> distrust it. ...

just saying: operationally this is a far more complex proposal than a
"tell me the truth and also the policy, with proofs for each" protocol
option.

-- 
Paul Vixie