> From: Barry Raveendran Greene <bgre...@senki.org> > To: Paul Wouters <p...@nohats.ca>
> 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 v...@rhyolite.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
