On Tue, 19 Mar 2019 at 13: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> 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. I'm not particularly concerned about cooperative clients. Even if it's not possible today, the economics of large enterprises will force browsers et. al. to make their software configurable in some automated, mass-update way that works for 50k+ employee companies. I'll be able to use the same controls to force cooperative clients to use my resolver, whether that be DoT or DoH. It's the uncooperative clients that I'm concerned about, and the presence of DoH endpoints at the same IP:port pair as other web sites means that in order to deal with uncooperative clients, operators will have to block/proxy all external port 443 traffic in order to make sure malware can't get access to resolution they don't control. 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. > The distinction between blocking single pages vs. blocking whole domains isn't really relevant here since we're talking about DNS-based blocking in the first place. However, there's a similar problem between blocking domain resolution and blocking the IP address a domain resolves to. Right now operators can block access to malwareCnC.com even if it resides on the same web server as useful.website.net because of the way virtual hosting works. If operators have to replace their domain reputation feeds with address reputation feeds there's going to be less fine-grained control and collateral damage.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
