On Thu, Dec 29, 2016 at 04:38:26PM -0000, John Levine wrote: > >> Please see the previous gazillion messages from people who are using > >> RPZ in production to keep malware away from their users. > >> > >> Also see the previous gazillion messages noting that governments do > >> all sorts of DNS censorship now and don't need RPZ. > >> > >> Could you explain in more detail why you don't believe operators will > >> continue to use RPZ to protect their users, and why you think hostile > >> actors will do things with RPZ that they couldn't do now? > > > >I was specifically asking about the redirect/record replacement > >behavior, not the nxdomain/blocking behavior. > > Providers routinely use sandboxing to quarantine infected users both > to protect their other users (malware can't contact C&C) and to force > them to do something about it, since they can't see anything other > than web sites with cleanup tools. > > I've talked to providers who tell me that this is the least bad way > they've found to get their users to clean up infected boxes. Even if > a provider could afford to calli them on the phone, it doesn't work, > first because users not unreasonably think it's a scam, and second > because the malware doesn't bother them, only other people, so they > blow off advice to fix it.
Thanks for explaining the use case. > So I reiterate the same two questions. Ok. > >> Could you explain in more detail why you don't believe operators will > >> continue to use RPZ to protect their users I believe you that RPZ is well-intentioned, and I'm sure that operators already using RPZ will continue to do so until it stops working or a better method is available. Eventually, if DNSSEC verification on endpoints becomes widespread, operators will need to turn to other means or break DNSSEC in these cases (but redirection will stop working). > >> why you think hostile actors will do things with RPZ that they > >> couldn't do now? For the very reasons that the authors want to make this an RFC -- RPZ isn't interoperable between DNS resolvers today. Once this RFC is published, it's clearly hoped that RPZ will be more interoperable and thus widespread. It's true that countries can legislate anything they want, and the publication (or not) of an RFC won't change that. But the enforcement of laws costs resources, and resources are finite -- so a country passing laws requiring network operators to filter and/or redirect will have no choice but to prioritize enforcement of such laws against other needs. There are already plenty of examples of countries limiting their enforcement of laws in recognition of implementation/enforcement costs. (For an example, see Richard Clayton's message on Dec 29.) If the implementation of laws is expensive, enforcement will also be expensive. If implementation of the law is cheap, enforcement is also much more cheap, and such laws consequently become more attractive. Having laws that cannot be effectively enforced on the books is certainly possible, but I suspect countries avoid it to maintain their credibility. RPZ being interoperable would appear to make implementation of filtering/redirection laws extremely cheap. Previously, the government would need to make a list of blocks and/or redirections and distribute that list to network operators in some fashion. By default, this would probably be via some kind of document which would then need to be translated into vendor-specific block/redirect lists. This is slow and expensive. Then, to enforce that these lists are being used, officials of the government would need to go around and check that the lists are being used and kept up to date. To do better, the government would need to define some kind of standardized format and get its use implemented. This isn't cheap either. If RPZ becomes interoperable (it doesn't matter if it's "standard", interoperability is standard enough), the government can just mandate use of RPZ and maintain the block lists directly. They can monitor that ISPs are consulting the RPZ in real-time, so enforcement is trivial. (Yes, the ISPs can query the list without enforcing it, but (a) information about what blocked domains are being accessed is useful and (b) that's no harder to check for, so it's irrelevant to the trade-off). Rich and highly-motivated governments will probably operate the same before and after RPZ becomes interoperable (though operating costs could go down, freeing resources for other programs or better enforcement), but other countries will find it easier to implement blocking and/or redirection in their country, increasing the motivation to do so. The blocking behaviors of RPZ will increase the load on networking infrastructure if the blocked addresses are DNSSEC-signed and endpoints validate the signatures. The redirection behavior of RPZ breaks in the face of DNSSEC validation if the records are signed, so it would be in the interests of a country that really wants the redirects to break all DNSSEC. Then the end user faces a choice: no DNSSEC or no Internet. They could try to use VPNs, but RPZ makes them easy to block nationally once discovered as well as easier to find users attempting to use them. (And if they're accessed by IP, that's even easier to block.) Setting aside how governments may choose to use RPZ, there are security risks to RPZ's deployment. Without RPZ, malicious actors that want to effect large-scale redirection of users would need to seek out the recursive resolvers of their endpoints and subvert them all. With RPZ, they only need to find the comparatively fewer RPZ servers and subvert them instead. If the location of the RPZ server is advertised (for accountability and network diagnostic purposes), then these addresses become available for malicious actors to seek out and attack. The redirection capabilities of RPZ are especially interesting to malicious actors, as they can become a means to take over a competing botnet's C&C network or redirect users to malware. If the location of the RPZ servers is hidden, diagnosing network problems becomes much more difficult. This has the net effect of making the DNS less reliable. The widespread use of captive portals has already made implementation of endpoint DNSSEC validation difficult and has essentially inhibited its implementation. I believe that widespread use of RPZ could do the same. All the above leads me to believe that RPZ is harmful to Internet security and infrastructure, however well-intentioned it may be. I do not support adoption of this draft. -- Scott Schmit
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
