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

Matthew Pounsett <matt@conundrum.com> Wed, 20 March 2019 19:45 UTC

Return-Path: <matt@conundrum.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 BB1F512008F for <dnsop@ietfa.amsl.com>; Wed, 20 Mar 2019 12:45:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-com.20150623.gappssmtp.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 03HcOk3h-sGK for <dnsop@ietfa.amsl.com>; Wed, 20 Mar 2019 12:45:45 -0700 (PDT)
Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC3F7127873 for <dnsop@ietf.org>; Wed, 20 Mar 2019 12:45:45 -0700 (PDT)
Received: by mail-io1-xd43.google.com with SMTP id b6so3205928iog.0 for <dnsop@ietf.org>; Wed, 20 Mar 2019 12:45:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hTsr91n3iasDpnSIKMygLHqeh+MbNIGkKkemE5V+IZc=; b=v1FaYCP4le1roWmtaKF6xEVgfbCN0H4fBeIS/Vyi5u5SawogzXxUzlk8mPAZEVBxY/ Damhk1QJgQ/M7FaJ0ahAUGkNEMb3aKaufnhPyuf5UulJzaVu5Y9c3sexW6JcJCUqeLnp h8jr8EPJbDzomfIWHgYwoal073+VeFmxfG/Iqctcy8s5Zr4qvIpTIuCJMUbmwtLxlRzt mELhgr3gp7z5FHHjHgxZS1EtmIVYV4AGaGxjLycQAltSlkFghH+Ex/MR/LOQoc9fuwzA KBBnXkGeocRKiGVUQYem0XMwMbQOCgUobRUnbNlEtn/gAUKXHBsb8JXoxuaoQXcKlM5q IVdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hTsr91n3iasDpnSIKMygLHqeh+MbNIGkKkemE5V+IZc=; b=X6qUhpGcLUOPG/7xfDlMISkq2VbB10UNQpfQ2N/ZYxaE4HXb8CEM/mZOjWdNG2ZXr1 u8s8AAJQ4bCOiIwz3Q/lkQzdI+5HvpLtcsA3QKBdRZtQRDk6tmliz7/YFyxIJdtFMZxQ eqQuE1fKaKBLaJUquTSG/AZhVCOge+2+ITvlSiltii8Ut+dYIIRSS1weTDxRa9lrGy6O JWrZaPj0Xa40izAoGBWrMpKlc0glxAo2+fuGIl+8gQiq69dYgRRnYSPtKa+EwYcB2mc9 PITZcw6HyMRJCV82n1S81WLoF6kSpG7ZHOUmid094/0jAT3vFKzGZjPH9iOUJMg0FbKH a2FA==
X-Gm-Message-State: APjAAAWamgo7BzhoINC7+p6z/elliuHmg2LDVr5hyo0QLpFNLMAB5cPC KARddOzdobPWS+9MidnNYODd2Z8+9LKSmsboQueREw==
X-Google-Smtp-Source: APXvYqx5cXQM2sMkb5b6msPEUFxIWYX7L8/mlMpoYypM4t53UEGvk0QbzQdFS9jopw1NBE49Lgjw9AfCSEsWMbyVklQ=
X-Received: by 2002:a6b:6007:: with SMTP id r7mr6610906iog.124.1553111144894; Wed, 20 Mar 2019 12:45:44 -0700 (PDT)
MIME-Version: 1.0
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> <0ea5c3ed-f0d9-8b95-515e-c555855a9c5c@huitema.net>
In-Reply-To: <0ea5c3ed-f0d9-8b95-515e-c555855a9c5c@huitema.net>
From: Matthew Pounsett <matt@conundrum.com>
Date: Wed, 20 Mar 2019 15:45:33 -0400
Message-ID: <CAAiTEH9uTP5xJeux3w5jxqzJarAApA=e5uVDD=VyKqffLH-x-A@mail.gmail.com>
To: Christian Huitema <huitema@huitema.net>
Cc: Eliot Lear <lear@cisco.com>, Ted Hardie <ted.ietf@gmail.com>, DoH WG <doh@ietf.org>, Paul Vixie <paul@redbarn.org>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000016a11605848bdefc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DgWb3L0yXkNW9ozg57Z7OMxu1fw>
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: Wed, 20 Mar 2019 19:45:49 -0000

On Tue, 19 Mar 2019 at 13:37, Christian Huitema <huitema@huitema.net> wrote:

>
> On 3/19/2019 12:50 AM, Eliot Lear wrote:
>
> 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.
>
> 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.
>
Yes.  I'm not particularly concerned about cooperative clients.  Even if
it's not possible today, the economics of large enterprises will force
browsers et. al. to make their software configurable in some automated,
mass-update way that works for 50k+ employee companies.  I'll be able to
use the same controls to force cooperative clients to use my resolver,
whether that be DoT or DoH.

It's the uncooperative clients that I'm concerned about, and the presence
of DoH endpoints at the same IP:port pair as other web sites means that in
order to deal with uncooperative clients, operators will have to
block/proxy all external port 443 traffic in order to make sure malware
can't get access to resolution they don't control.

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.
>
The distinction between blocking single pages vs. blocking whole domains
isn't really relevant here since we're talking about DNS-based blocking in
the first place.  However, there's a similar problem between blocking
domain resolution and blocking the IP address a domain resolves to.  Right
now operators can block access to malwareCnC.com even if it resides on the
same web server as useful.website.net because of the way virtual hosting
works.  If operators have to replace their domain reputation feeds with
address reputation feeds there's going to be less fine-grained control and
collateral damage.