Re: [Doh] [EXTERNAL] [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients

Eliot Lear <lear@cisco.com> Tue, 12 March 2019 14:04 UTC

Return-Path: <lear@cisco.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AAE130F04; Tue, 12 Mar 2019 07:04:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.511
X-Spam-Level:
X-Spam-Status: No, score=-12.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlBAlW6GDuZQ; Tue, 12 Mar 2019 07:04:29 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21C1130DCB; Tue, 12 Mar 2019 07:04:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18892; q=dns/txt; s=iport; t=1552399469; x=1553609069; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=SDpsdnUnoiR2VskE0HTwttpQ+OLYp01wBwtWH5/ndd8=; b=QAx83JTptCTTeN11dS9dGehmWdQbaHHMNxX+xKzBq95jg9bJdWK+Xedb M5JwlPnVOW3cQynUZdtF0zG6h/1oNNj3oDknbq82h1bQOEe+uoIwdMV/N o0piq8wONraQ/8Ywq0KVQnAaaAqEUTIUCaJOsq4eXrJJGO7yfr/nT1NVd g=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAABHu4dc/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYFhgRdQIRInhAqIeYxAJZI2hgmBZwgDAQEYAQmBD12?= =?us-ascii?q?CXgKEWzgSAQEDAQEJAQMCbRwMhUoBAQEDAQEBIUsDCAUHBAsRBAEBARUVAgI?= =?us-ascii?q?nKAgGExuDAgQBAYFdAw0ID65agSaBL4VFglADghoKBYEvgUmJRw4mgX+BESc?= =?us-ascii?q?ME4FOfoMeAQECGIECCAEJAQsHAQkEPhOCSzGCJgOKAQEZAw6HFpJsCYRbgnq?= =?us-ascii?q?JFYIrGYF5hWaLXZpfgm4CBAYFAhWBXiENGw0wcTMaCBsVOyoBgkETK4FTg2e?= =?us-ascii?q?FFIVAPgMwAQEBAY5uDxeBOlcWAQE?=
X-IronPort-AV: E=Sophos;i="5.58,471,1544486400"; d="asc'?scan'208,217";a="10636995"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Mar 2019 14:04:25 +0000
Received: from ams3-vpn-dhcp7163.cisco.com (ams3-vpn-dhcp7163.cisco.com [10.61.91.250]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x2CE4Oh1023542 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Mar 2019 14:04:25 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <2F7920EE-F04C-43E9-8194-B0000A0756F7@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_102A3198-12FB-4AFD-8E99-693AD8F24FF5"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Tue, 12 Mar 2019 15:04:23 +0100
In-Reply-To: <2D9C1616-EF47-4685-8155-99A718806EE9@sky.uk>
Cc: "doh@ietf.org" <doh@ietf.org>, "dnsop@ietf.org" <dnsop@ietf.org>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
To: "Winfield, Alister" <Alister.Winfield@sky.uk>
References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <eea64b30-aad0-a030-5360-1b1484f1d0e3@huitema.net> <CAPsNn2WhjHSEHJUEL8GB6X0d24fkajgPnY4YgkOQbXjyxb5q8Q@mail.gmail.com> <e62efaf3-4a35-4a52-5ed4-dee2e7fafe72@huitema.net> <69f989ba-0939-b917-b586-9e3af3fb8b74@redbarn.org> <CAPsNn2XNCzgAdfJtxBVboAe+d6sbCiV2fZv9185wm+HN+3zRdg@mail.gmail.com> <BYAPR16MB279065EE519680E7FC9A637CEA480@BYAPR16MB2790.namprd16.prod.outlook.com> <CAPsNn2Up1AtJJCdmu_9NC4jfzc-8dtE+QjUzRxMBUwaN44gvOg@mail.gmail.com> <76386691-c1aa-c48a-9b0d-67eb36a08a4f@redbarn.org> <36C6BE4B-5919-4658-9AF1-AB1572E5999C@cisco.com> <BYAPR16MB27900AFE0CCF4E7CF6A35F6CEA490@BYAPR16MB2790.namprd16.prod.outlook.com> <2D9C1616-EF47-4685-8155-99A718806EE9@sky.uk>
X-Mailer: Apple Mail (2.3445.102.3)
X-Outbound-SMTP-Client: 10.61.91.250, ams3-vpn-dhcp7163.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/PjUTcIUIidD8pr3nSS22-xgVrLY>
Subject: Re: [Doh] [EXTERNAL] [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Mar 2019 14:04:33 -0000

Hi,

> On 12 Mar 2019, at 14:11, Winfield, Alister <Alister.Winfield@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-bounces@ietf.org on behalf of TirumaleswarReddy_Konda@McAfee.com> wrote:
> 
>> -----Original Message-----
>> From: Eliot Lear <lear@cisco.com>
>> Sent: Monday, March 11, 2019 11:49 PM
>> To: Paul Vixie <paul@redbarn.org>
>> Cc: nalini elkins <nalini.elkins@e-dco.com>; Konda, Tirumaleswar Reddy
>> <TirumaleswarReddy_Konda@McAfee.com>; doh@ietf.org; dnsop@ietf.org;
>> Ackermann, Michael <mackermann@bcbsm.com>; Christian Huitema
>> <huitema@huitema.net>; dns-privacy@ietf.org; Vittorio Bertola
>> <vittorio.bertola=40open-xchange.com@dmarc.ietf.org>; Stephen Farrell
>> <stephen.farrell@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 <paul@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-privacy@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 phishing@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