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

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Tue, 12 March 2019 15:31 UTC

Return-Path: <TirumaleswarReddy_Konda@mcafee.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2351310BA; Tue, 12 Mar 2019 08:31:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 c5ekruE620Zs; Tue, 12 Mar 2019 08:31:39 -0700 (PDT)
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3373413106C; Tue, 12 Mar 2019 08:31:38 -0700 (PDT)
X-NAI-Header: Modified by McAfee Email Gateway (5500)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1552404497; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-ms-exchange-senderadcheck:x-microsoft-antispam-message-info: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=aCaTgYhdkL9H96k2GKgBJFoW5Crd8hr1EfNElz ffUoY=; b=TVecrWjWnRenswgKAs/U5Y/QYb0bk51YZ3dVcugQ WxNeBSSHHDz7Dq95d4sqe3VM595CNCdkSPR1FoV/+lqyl8EYpg kI+Crin2M4P6+CVb4UuNj21mipKPsOOrDyFzKfhrzuBpzuyHig mYVfh+6FEGIfqvQHZgjjJffl+5tdd7A=
Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 0713_d065_6d26dfdb_15f9_41e8_b370_cd7052d7e84c; Tue, 12 Mar 2019 09:28:17 -0600
Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 12 Mar 2019 09:31:14 -0600
Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 12 Mar 2019 09:31:14 -0600
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 12 Mar 2019 09:31:12 -0600
Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2775.namprd16.prod.outlook.com (20.178.233.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.13; Tue, 12 Mar 2019 15:31:12 +0000
Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39%2]) with mapi id 15.20.1709.011; Tue, 12 Mar 2019 15:31:12 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Eliot Lear <lear@cisco.com>, "Winfield, Alister" <Alister.Winfield@sky.uk>
CC: "dnsop@ietf.org" <dnsop@ietf.org>, "doh@ietf.org" <doh@ietf.org>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Thread-Topic: [dns-privacy] [EXTERNAL] [Doh] [DNSOP] New: draft-bertola-bcp-doh-clients
Thread-Index: AQHU2NykUOnXbuK5C0u7DjEHW45Cb6YIG/zg
Date: Tue, 12 Mar 2019 15:31:12 +0000
Message-ID: <BYAPR16MB2790DC9ABC4B4CF2ACC36638EA490@BYAPR16MB2790.namprd16.prod.outlook.com>
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> <2F7920EE-F04C-43E9-8194-B0000A0756F7@cisco.com>
In-Reply-To: <2F7920EE-F04C-43E9-8194-B0000A0756F7@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.2.0.6
dlp-reaction: no-action
authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com;
x-originating-ip: [49.37.203.5]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bdf094dd-cb17-4180-9c8e-08d6a6ffc257
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2775;
x-ms-traffictypediagnostic: BYAPR16MB2775:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <BYAPR16MB2775EA69C39864CE4A489185EA490@BYAPR16MB2775.namprd16.prod.outlook.com>
x-forefront-prvs: 09749A275C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(346002)(39860400002)(136003)(376002)(32952001)(13464003)(199004)(189003)(54094003)(51444003)(790700001)(3846002)(6116002)(229853002)(316002)(93886005)(54906003)(110136005)(68736007)(26005)(476003)(25786009)(45080400002)(256004)(5024004)(14444005)(71200400001)(71190400001)(5660300002)(6436002)(6306002)(9686003)(55016002)(54896002)(4326008)(2906002)(52536013)(66574012)(236005)(53936002)(6246003)(53546011)(80792005)(6506007)(72206003)(14454004)(966005)(606006)(186003)(33656002)(7696005)(76176011)(99286004)(97736004)(478600001)(7736002)(446003)(102836004)(81166006)(81156014)(8676002)(106356001)(8936002)(74316002)(486006)(105586002)(11346002)(66066001)(86362001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2775; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 9rl9RLrr5ci4kBhMTeP0XLIM1MYx84OapMvvIrx2a4iI0VoXCtAw7eLsf+BPunWp4wJPJlkYvt5X++9X3wdFSXLsCfs2amS4Gq784nTi+Zu0xKvHPlODKck0Zj5z2AK6UB9u5YerO76xRnTM7JmR+4FgGqJdPOBrKZydeO97sSMPtq2KF03N4kELJkXPhNtaRRi014QnC40jkwIO1/Qm2lbhEH7BT4CBthnk33eH/T4aVq6Y/8JZYByE6ssn36hXQO3LM+mcZbWv1BQWsjLJN/Aj94zqFxCzyYPeV+qHNkTP91W8cr9PYFFtFd15FhBZ210VyMheBIN6jjQePEaptQV6iE+PdkP+Uh6bWU0lTsj1gKl3Ccstlhp2z5t5/aSpngbiw3OH1r6GyfdugWiX+0cE0ajnB0A6qWdXI02oWEk=
Content-Type: multipart/alternative; boundary="_000_BYAPR16MB2790DC9ABC4B4CF2ACC36638EA490BYAPR16MB2790namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: bdf094dd-cb17-4180-9c8e-08d6a6ffc257
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2019 15:31:12.4745 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR16MB2775
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level:
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0.1
X-NAI-Spam-Version: 2.3.0.9418 : core <6501> : inlines <7032> : streams <1815501> : uri <2811445>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/K-fAwpNh6sHUf-8KAzuYd9R6-hE>
Subject: Re: [dns-privacy] [EXTERNAL] [Doh] [DNSOP] New: draft-bertola-bcp-doh-clients
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Mar 2019 15:31:43 -0000

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-bounces@ietf.org> On Behalf Of Eliot Lear
Sent: Tuesday, March 12, 2019 7:34 PM
To: Winfield, Alister <Alister.Winfield@sky.uk>
Cc: dnsop@ietf.org; doh@ietf.org; dns-privacy@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.Winfield@sky.uk<mailto: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<mailto:dns-privacy-bounces@ietf.org> on behalf of TirumaleswarReddy_Konda@McAfee.com<mailto:TirumaleswarReddy_Konda@McAfee.com>> wrote:


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