MDM may or may not be acceptable even in Enterprise networks. For instance, today network security services are using ML techniques to identify malware flows without acting as a TLS proxy. MDM is also not an option to secure devices in the home networks, especially consumer IoT devices.
Cheers, -Tiru From: dns-privacy <dns-privacy-boun...@ietf.org> On Behalf Of Eliot Lear Sent: Tuesday, March 12, 2019 7:34 PM To: Winfield, Alister <alister.winfi...@sky.uk> Cc: dnsop@ietf.org; d...@ietf.org; dns-priv...@ietf.org Subject: Re: [dns-privacy] [EXTERNAL] [Doh] [DNSOP] New: draft-bertola-bcp-doh-clients Hi, On 12 Mar 2019, at 14:11, Winfield, Alister <alister.winfi...@sky.uk<mailto:alister.winfi...@sky.uk>> wrote: MDM is also a red-herring given >90% of devices world-wide aren't managed so anyone talking of MDM riding to the rescue of DoH client configuration is walking around with blinkers on. Firefox has published a specific policy interface just for this purpose. I think the point, and perhaps others could correct me, is that the MDM serves as evidence that the owner of the device is authorizing a configuration change. And the use case I am discussing is the enterprise use case. Your #s do not take that into account. Even inside company networks there are servers not under MDM; Servers seem an unlikely use of DoH from an application in particular. locally developed applications that might in future pull in a DoH resolver; In that case, the enterprise administrator is aiming the shotgun at his or her own foot. I propose not to solve that problem, but rather to help them with tools to do the right thing. BYOD; visitors; malware and so on. It is certainly not best practice for visitors to be granted access to internal access; instead they typically are given guest access. BYOD is a different story. Here DoH may add pressure on those bringing their own devices to have to place them under MDM control. That pressure already exists, by the way. DoH just adds to it. So whatever you think a reasonable solution for client configuration has to start with unmanaged clients. That last one malware is why the corporate response may well be 'MITM' the traffic so we can protect the data, people and systems using our network. What DoH discovery and presentation looks like is complex issue that will take some discussion. Just one small example, I might want to use the local networks DNS if and only if it provides anti-malware protection and has a reasonable privacy policy but use a static one if not. Or perhaps on a child's device it's okay if there is filtering in place suitable for children. I have previously written here that meaningful consent (a’la Sasse, Acquisti, et al) is a key issue. With your example, Alister, you are essentially asking about number of attributes from the DNS server; some of which would have to be ascribed by others rather than simply self-asserted. And then you have to make all of that information consumable and actionable by a normal person. Good luck. Just establishing an operational model in which split DNS is handled correctly will be enough of a challenge, but is worth exploring. And that is why much of this smells like research to me. If there are willing partners, I think that would be a great avenue to tread down. Eliot Alister On 12/03/2019, 05:43, "dns-privacy on behalf of Konda, Tirumaleswar Reddy" <dns-privacy-boun...@ietf.org<mailto:dns-privacy-boun...@ietf.org> on behalf of tirumaleswarreddy_ko...@mcafee.com<mailto:tirumaleswarreddy_ko...@mcafee.com>> wrote: -----Original Message----- From: Eliot Lear <l...@cisco.com<mailto:l...@cisco.com>> Sent: Monday, March 11, 2019 11:49 PM To: Paul Vixie <p...@redbarn.org<mailto:p...@redbarn.org>> Cc: nalini elkins <nalini.elk...@e-dco.com<mailto:nalini.elk...@e-dco.com>>; Konda, Tirumaleswar Reddy <tirumaleswarreddy_ko...@mcafee.com<mailto:tirumaleswarreddy_ko...@mcafee.com>>; d...@ietf.org<mailto:d...@ietf.org>; dnsop@ietf.org<mailto:dnsop@ietf.org>; Ackermann, Michael <mackerm...@bcbsm.com<mailto:mackerm...@bcbsm.com>>; Christian Huitema <huit...@huitema.net<mailto:huit...@huitema.net>>; dns-priv...@ietf.org<mailto:dns-priv...@ietf.org>; Vittorio Bertola <vittorio.bertola=40open-xchange....@dmarc.ietf.org<mailto:vittorio.bertola=40open-xchange....@dmarc.ietf.org>>; Stephen Farrell <stephen.farr...@cs.tcd.ie<mailto:stephen.farr...@cs.tcd.ie>> Subject: Re: [Doh] [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients Hi Paul, On 11 Mar 2019, at 19:12, Paul Vixie <p...@redbarn.org<mailto:p...@redbarn.org>> wrote: nalini elkins wrote on 2019-03-11 10:26: Tiru, Thanks for your comments. Enterprise networks are already able to block DoH services, i wonder if everyone here knows that TLS 1.3 and encrypted headers is going to push a SOCKS agenda onto enterprises that had not previously needed one, and that simply blocking every external endpoint known or tested to support DoH will be the cheaper alternative, even if that makes millions of other endpoints at google, cloudflare, cisco, and ibm unreachable as a side effect? That or it will require a bit more management at the MDM level. I’m hoping the latter. And I hope that one output of all of these documents will be a recommendation regarding MDM interfaces. I don't think MDM is required to use the DoT/DoH servers provided by the local network. -Tiru Eliot _______________________________________________ dns-privacy mailing list dns-priv...@ietf.org<mailto:dns-priv...@ietf.org> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdns-privacy&data=02%7C01%7Calister.winfield%40sky.uk%7Cab5faa933f374ae7b72c08d6a6ada348%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C636879662059337184&sdata=bba3bapIO3ffilylhoIj0x3zVkHYlNC4Gid96Ybx9Xo%3D&reserved=0 -------------------------------------------------------------------- This email is from an external source. Please do not open attachments or click links from an unknown or suspicious origin. Phishing attempts can be reported by sending them to phish...@sky.uk<mailto:phish...@sky.uk> as attachments. Thank you -------------------------------------------------------------------- Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
