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

[Vernon Schryver <[e-mail]>]

> From: Barry Raveendran Greene <[e-mail]>
> To: Paul Wouters <[e-mail]>

> Paul - changes to existing practice is a _new_ document. You take the existing, coded, and deployed specification in as an informational RFC. Then you start a new working group document for the full "IETF version."
>
> We've done this for many other protocols over the last several decades. Why the push back?

indeed.


> > The draft breaks DNSSEC. ...

As stated, that could be seen as inaccurate.  The current de facto
standard RPZ produces modififed DNS responses that are unsigned and
so do not verify, just as if the DNS resolver were an old, pre-DNSSEC
installation.  For better or worse, DNS clients that care about DNSSEC
(i.e. that verify or just check the header bit) are not fooled by RPZ
and so in that sense the DNSSEC protocol is not broken by the draft.

The "break-dnssec" option was not in early RPZ implementations.  I
added it in response to popular demand, and I suspect it is present
in most RPZ installations.  I chose the phrase "break-dnssec" to suggest
that you should think twice before turning it on.


> > I have proposed a method that would not change the RPZ response for a
> > non-DNSSEC client, but would add data for DNSSEC capable clients to be
> > notified the DNSSEC data was modified (and possibly state why) giving
> > DNSSEC capable clients a method to act differently, knowing the data was
> > changed for a reason and is not simply a DNS spoofing attack. It can be
> > added without breaking existing deployments. If the authors aren't willing
> > to do this, why should IETF rubberstamp a DNS protocol that breaks DNSSEC?

To somewhat mitigate rubberstamping, I'd be happy to add a simple
warning or prohibition on implementing or deploying RPZ, provided it
lacks political grandstanding and has working group consensus.

As for "fixing" RPZ+DNSSEC, the current draft specifies behavior only
for DNS recursive resolvers.  Nothing can be done in only the RPZ-using
DNS servers to securely notify clients about RPZ changes.  DNS clients
would need to be modified to look for the new signs of RPZ changes.
Exactly what those RPZ signs would be and what DNS clients should do
when they are present would have to be designed and documented.  The
scope of those client and server protocol changes would be much larger
than the scope of the current QTYPE=ANY proposal, and so more controversial
and time consuming, even if RPZ itself were not more controversial
than changing the de facto definition(s) of QTYPE=ANY.

Distinguishing a DNS spoofing attack pretending to be RPZ changes from
"honest" RPZ changes would require some sort of digital signatures,
but the trust anchor for those signatures could not be standard.  Those
non-DNSSEC-standard signatures might involve a DLV or maybe they could
use a key associated with the domain name in the RPZ SOA.  In cany
case, a complete design would be required.  That they would be
non-DNSSEC_standard implies that they could not be in the usual places,
lest pre-new-RPZ-but-verifying DNS clients see them...and those are
merely some problems that seem obvious for secure RPZ rewriting.

Note that RPZ changes are already signaled by the odd SOA specified
in draft, although it is intended only for human inspectors.  That SOA
is in the additional section, because putting it in the usual place
breaks some cases....which is another way of saying that merely adding
as yet unspecified RRSIGs to the authority section of RPZ modified DNS
responses is not something that should be without extended discussions,
plenty of real world testing, and more time than has been spent on the
QTYPE=ANY protosal.


Vernon Schryver    [e-mail]