Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

Eliot Lear <lear@cisco.com> Tue, 19 March 2019 07:51 UTC

Return-Path: <lear@cisco.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245F01311BF; Tue, 19 Mar 2019 00:51:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 X2gan6shKPip; Tue, 19 Mar 2019 00:51:00 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AFC91274A1; Tue, 19 Mar 2019 00:51:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6134; q=dns/txt; s=iport; t=1552981860; x=1554191460; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=Y39Ho1Acxa113SbZ0GVOuin9B+CBF4Z2ZVdBwTokR9o=; b=TtuxlnZ8eQHpHKobnoA9QKLRFqCDIym7An8KhKgJo4gxPMkxDgmkZWfa Ygy9p79BJBhY/LtFl02MMeo5TiqAoYDsHyUAunmOFFh5xsFA/6UrhWsdA H7V98rizT9H0KazZnBbE9xArUdakFwd+hc3xvb0E2sBcQJHQYKBxnWFJa M=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BVAAACn5Bc/xbLJq1jGgEBAQEBAgEBAQEHAgEBAQGBZYEPgjohEieEC4h7jDMlkjyHcQgDAQGEbAKEfDgSAQEDAQEJAQMCbSiFSgEBAQMBI1YFCwsECgoqAgJXBhMfgwMBgW0IqVaBL4VGhGwPgS8BgUiJf4F/gTgME4JMiAsxgiYDilyHBJMHCYRhjkoZixKIS5sfgnACBAYFAhWBXiGBVjMaCBsVZQGCQT6BWBeOHz4DMIo1AQE
X-IronPort-AV: E=Sophos;i="5.58,497,1544486400"; d="asc'?scan'208,217";a="10827738"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Mar 2019 07:50:52 +0000
Received: from [10.61.226.181] ([10.61.226.181]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x2J7opdc006812 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Mar 2019 07:50:52 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <A6C66F6C-2663-4AF0-B318-04CE66129D14@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_1B84DB7B-41F0-4581-9A4A-D7D6CF962C9E"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Tue, 19 Mar 2019 08:50:50 +0100
In-Reply-To: <CAAiTEH_umx5Xqa24TywQ_BX_Lpo6piwRWPLWhADkh-PnM20vcg@mail.gmail.com>
Cc: Ted Hardie <ted.ietf@gmail.com>, dnsop <dnsop@ietf.org>, DoH WG <doh@ietf.org>, Paul Vixie <paul@redbarn.org>
To: Matthew Pounsett <matt@conundrum.com>
References: <155218771419.28706.1428072426137578566.idtracker@ietfa.amsl.com> <1914607.BasjITR8KA@linux-9daj> <CA+9kkMAYR19CCCLN00A5Oy_=9Z97FQogCz-vdC=M7Ffn47fTgQ@mail.gmail.com> <1900056.F7IrilhNgi@linux-9daj> <CA+9kkMCgmzjbPM+DTUYuS3OsT+wOCmsyaGPg6fPu=w-ibL=NrA@mail.gmail.com> <CAAiTEH_umx5Xqa24TywQ_BX_Lpo6piwRWPLWhADkh-PnM20vcg@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.102.3)
X-Outbound-SMTP-Client: 10.61.226.181, [10.61.226.181]
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Nu-rgcKgdL5HxBSPSzfQiAktkyk>
Subject: Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Mar 2019 07:51:03 -0000

Matthew

> On 19 Mar 2019, at 01:50, Matthew Pounsett <matt@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.

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.

It might also be possible to whitelist ANSWERs into iptables. I wrote the code for that for a dnscap plugin some years ago, and you could even play with it if you want (it’s on GitHub), but I’m not suggesting it’s a good general answer (it was intended for a very specific use case involving relatively few domains for (hopefully cooperating) IoT devices).  As you point out, it won’t tackle shared IP addresses, and quite frankly, little CPE gear won’t scale with a gazillion iptables entries (I’m not sure big gear would either).

Eliot