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

Christian Huitema <huitema@huitema.net> Tue, 19 March 2019 17:37 UTC

Return-Path: <huitema@huitema.net>
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 115A8131495 for <dnsop@ietfa.amsl.com>; Tue, 19 Mar 2019 10:37:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 O8r9_rU9REFX for <dnsop@ietfa.amsl.com>; Tue, 19 Mar 2019 10:37:33 -0700 (PDT)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 2463E131175 for <dnsop@ietf.org>; Tue, 19 Mar 2019 10:37:33 -0700 (PDT)
Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx65.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1h6Ig6-0002c3-4m for dnsop@ietf.org; Tue, 19 Mar 2019 18:37:31 +0100
Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1h6Ify-0004gI-GN for dnsop@ietf.org; Tue, 19 Mar 2019 13:37:28 -0400
Received: (qmail 905 invoked from network); 19 Mar 2019 17:37:21 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.166]) (envelope-sender <huitema@huitema.net>) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for <dnsop@ietf.org>; 19 Mar 2019 17:37:20 -0000
To: Eliot Lear <lear@cisco.com>, Matthew Pounsett <matt@conundrum.com>
Cc: Ted Hardie <ted.ietf@gmail.com>, DoH WG <doh@ietf.org>, Paul Vixie <paul@redbarn.org>, dnsop <dnsop@ietf.org>
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> <A6C66F6C-2663-4AF0-B318-04CE66129D14@cisco.com>
From: Christian Huitema <huitema@huitema.net>
Openpgp: preference=signencrypt
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <0ea5c3ed-f0d9-8b95-515e-c555855a9c5c@huitema.net>
Date: Tue, 19 Mar 2019 10:37:08 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <A6C66F6C-2663-4AF0-B318-04CE66129D14@cisco.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="VN750uGYpYHVIJ8TAzr8qOOVUkaqMii6v"
X-Originating-IP: 168.144.250.215
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.17)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5iHCTjRzujY5H9a5CUljdn5602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO1HF+STREOMSVVRlQBhMBwlVjyn5UrUp4n4yKOOaq9AxeFiY6b90t/IF5TRGndBTalDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5CmLguVI7uaKQZnk5mHowEU5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhwZ+JqwRq4dm7gx9VmMD3oQl+86MkQJ6nrl0gGH3bP6cMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjMauXIUif1JzGdiG0o4ggCmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJE2d52fY0d/1mkgffWkdO 4QEiRQv+PVjjwa+Z5RFCOMR0q/8r+vli3P7r8BoPzXffG1JhEiAOdl0Bn/vyebShl921URBlOdpr 4SdBpem+Ij1qJvBXd7I82n0qpCzrPWiSwKPXNKNk2RVY2K5nyLgw1RWkNIWnHjoiI9QIik6sV5hq 8RGminksXtFq8ejOBuf1PiUt8a2Lj9MmCjDfgJI6+a9HWwMUNATk5aqJgNL5XJKDg5/bq7ChmPMN Ycw1QSmR+/lZ11nr952gjA7qwPBI/T6iRmOmRyo7k1YCyVu1VaNm4zuNRcgRKiGg7nXFaZTxCXRq rnqpvNj9xYi9OgZhihfVX7Nwkf86OVuF6l8Zp2++NTKQHNkjJg8xvPcdYB8Xv0lqRWmYZel4DctY KBjcJP27lItOpPwlvQ6ktwDuRituj6ZEfB9v4x8THVh0rVtlyOZYRaCjaXhrY3nerbmurCmoQsay Zkd2YakTHWoyevr4xM5tUrEfL92iWzfzWX2vc1ctxv2vDEIpeWV/lG6Wmg==
X-Report-Abuse-To: spam@quarantine9.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8YxeW9kIpFfgggX5jQ5OcNdNmKw>
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 17:37:36 -0000

On 3/19/2019 12:50 AM, Eliot Lear wrote:
>> On 19 Mar 2019, at 01:50, Matthew Pounsett <matt@conundrum.com
>> <mailto: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.

Configuration works well for functions like "phishing protection": the
device users in most cases want some form of protection, and then it is
a matter of how this protection is configured. It does not work so well
for functions like intrusion detection, such as figuring out whether a
device is trying to contact a botnet C&C, because we cannot expect the
infected device to be amenable to configuration.

Third party DNS/DoH providers could probably block resolution of
phishing names or  botnet C&C names using the same methods as
enterprises do today, but the enterprise network will not be informed
that one of its devices just tried to contact a botnet C&C. It would be
very nice if the IETF standardized a way to do that.

>
> 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.

Yes, one could imagine IP address or IP prefix reputation systems,
similar to the IP address block lists used to protect against spam. This
would work, and it would also provide intrusion detection signals when
an infected device starts contacting a botnet. The problem of course is
the gray line between "blocking phishing sites" and "blocking content
that I disagree with". The various attempts to block the whole of
Wikipedia in order to block some specific pages shows where this can lead.

-- Christian Huitema