On Sun, Dec 18, 2016 at 07:59:44PM +0000, Tony Finch wrote: > Scott Schmit wrote: > > This doesn't magically make it possible for this DNS firewall to forge > > DNSSEC-signed data, so if a validating end-system is going to have its > > behavior modified, it would need to opt in. > > That's not entirely true. An RPZ setup can lie regardless of whether a > client appears to be validating or not. If the admin's goal is to block > access to malicious sites, then a validating client will get a bogus > result or SERVFAIL, and the site will be blocked as intended.
If the admin's goal is to block access to malicious sites, then they want to block the traffic, not falsify DNS. If the goal is to warn users away from bad places, they can publish the list as a filter for end-system firewalls. If the goal is to censor the Internet and keep the rebellion from successfully gathering and planning their actions against the Galactic Empire, then this scheme works perfectly because it works without requiring end systems to be involved. And it's much easier than manually maintaining lists. And cross-vendor, too, so it's easier to manage the rules across organizations, companies, even country-wide. With a redirect capability at that scale, a (mis)configuration could also make it very easy to send DDoS attacks at particular sites. > > But it looks like the contents of this zone are intended to be kept > > secret from end-users. > > That depends entirely on the zone maintainer's policy. The admin can > easily allow clients to query or transfer an RPZ, and/or provide out of > band information about the zone on its web site. If allowing the zone contents to be kept secret wasn't a goal of this design, then it wouldn't be mentioned in the security considerations twice. It also wouldn't be a SHOULD that the list be access-controlled. Sure, an admin isn't required to keep it secret, but it's absolutely built into the design. An out of band mechanism is no substitute, as it allows for summarization or lying by omission: "We are only blocking access to criminal sites. If you're having trouble, the problem must be you." Meanwhile the filter also blocks legal-but-"subversive" organizations. > > So this, if implemented, is ultimately a DNSSEC-killer. > > I don't think so. Even the draft admits in 12.2 that the "break-dnssec" configuration setting is "common". So let's admit that this draft considers DNSSEC an obstacle to be overcome and that doing so will be typical. > DNSSEC is not able to improve the availability of the DNS. The point of > DNSSEC is to ensure that if you get an answer, you can be sure it is > authentic. If your local network wants to prevent you from accessing a > malicious site, DNSSEC can't stop them. You make a good point. Sounds like there's no need for the IETF to publish this as an RFC, since admins can already do this via other means. What does this make easier that should be made easier? What are the negative effects of that we'd rather avoid? -- Scott Schmit
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
