Hi,

> On 12 Mar 2019, at 14:11, Winfield, Alister <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 on behalf of 
> tirumaleswarreddy_ko...@mcafee.com> wrote:
> 
>> -----Original Message-----
>> From: Eliot Lear <l...@cisco.com>
>> Sent: Monday, March 11, 2019 11:49 PM
>> To: Paul Vixie <p...@redbarn.org>
>> Cc: nalini elkins <nalini.elk...@e-dco.com>; Konda, Tirumaleswar Reddy
>> <tirumaleswarreddy_ko...@mcafee.com>; d...@ietf.org; dnsop@ietf.org;
>> Ackermann, Michael <mackerm...@bcbsm.com>; Christian Huitema
>> <huit...@huitema.net>; dns-priv...@ietf.org; Vittorio Bertola
>> <vittorio.bertola=40open-xchange....@dmarc.ietf.org>; Stephen Farrell
>> <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> 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
>    
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdns-privacy&amp;data=02%7C01%7Calister.winfield%40sky.uk%7Cab5faa933f374ae7b72c08d6a6ada348%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C636879662059337184&amp;sdata=bba3bapIO3ffilylhoIj0x3zVkHYlNC4Gid96Ybx9Xo%3D&amp;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 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

Attachment: signature.asc
Description: Message signed with OpenPGP

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to