Hi Christian, > On 19 Mar 2019, at 18:37, Christian Huitema <huit...@huitema.net> wrote: > > > > On 3/19/2019 12:50 AM, Eliot Lear wrote: >>> On 19 Mar 2019, at 01:50, Matthew Pounsett <m...@conundrum.com >>> <mailto:m...@conundrum.com>> wrote: >>> >>> Somewhere up-thread it was suggested that there are other reasonable steps >>> that a network/security operator can take to maintain the controls over >>> resolution that we have today, but so far I haven't seen them enumerated >>> anywhere. >>> >> >> I had stated that one can use an MDM to manage the endpoint’s use of DoH. >> This doesn’t eliminate the possibility of malware, but does reduce >> misconfiguration in the enterprise, and provides for some protection against >> infection by blocking known bad names. > Configuration works well for functions like "phishing protection": the device > users in most cases want some form of protection, and then it is a matter of > how this protection is configured. It does not work so well for functions > like intrusion detection, such as figuring out whether a device is trying to > contact a botnet C&C, because we cannot expect the infected device to be > amenable to configuration. >
Yes. > Third party DNS/DoH providers could probably block resolution of phishing > names or botnet C&C names using the same methods as enterprises do today, > but the enterprise network will not be informed that one of its devices just > tried to contact a botnet C&C. It would be very nice if the IETF standardized > a way to do that. > I don’t see why they wouldn’t, and I could easily envision them being obliged to do so in the future. >> >> In addition, there’s at least a heuristic for detection: compare data plane >> activity against ANSWERs. If you’re seeing activity to addresses that don’t >> match (modulo some noise), you know an alternate resolver is active on that >> device. And while it’s possible for malware to mimic queries to Do53 for >> Good sites versus what it really wants to access, you start tarnishing the >> rep of the IP address as and when you detect the problem through other means >> (AV s/w, honey pots, binary inspection, et al). That leaves it with cloud >> providers to sort their wagons. > Yes, one could imagine IP address or IP prefix reputation systems, similar to > the IP address block lists used to protect against spam. This would work, and > it would also provide intrusion detection signals when an infected device > starts contacting a botnet. The problem of course is the gray line between > "blocking phishing sites" and "blocking content that I disagree with". The > various attempts to block the whole of Wikipedia in order to block some > specific pages shows where this can lead. In the enterprise this is not a problem. In the consumer space, it is a big problem. This goes back to the fundamental issue of whether or not the user has given meaningful consent and what happens when they do not. We should be at least mindful of the game of Chicken being played here with governments. Lessig’s Law is bounded by the fact that governments have a lot more guns than most of us do (with some notable and amusing exceptions). The point of my message was not to go into this discussion, however, but to talk about what is possible, rather than what is necessarily desirable. The sharing of threat intel is something that could be reasonably governed by contract in this scenario. Think about that a bit. Eliot
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
