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

Matthew Pounsett <> Wed, 20 March 2019 19:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9CD0512D550 for <>; Wed, 20 Mar 2019 12:45:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E1bLThDRVuEm for <>; Wed, 20 Mar 2019 12:45:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AC23012008F for <>; Wed, 20 Mar 2019 12:45:45 -0700 (PDT)
Received: by with SMTP id u12so3155855iop.11 for <>; Wed, 20 Mar 2019 12:45:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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=ih8mTD6whOnzLT6UhwdtQ+i5Crj417qKgLONO1dTmX+11mS/PMIshIsL01nV5c93ze yZXXh+KmmFqVwRZaqj9zhkC+iSEUF7DzS8wWs9Fl33y0Gc8NVLn3dl5hYuDK9eYWUUSy IDo3QEz/i73csJ7XBpi+bsn/V3SsCNp4XwHado/J6l61rPpsiupn/VzFmko49sg4f7Wa v5MWgaDcE0wZ9UxyhqfrcUQkFYw4I5KNgTy7/0tpRbQy9yfk1uG6zuFu6jbPmoBjxKJO rqbwVEb/XwqHuoRsRA/XBSFzC76Zh0wZdhjxbFUbCW5RMVTtbQ2cObAn8nKty1q9ZciZ Vd4g==
X-Gm-Message-State: APjAAAVaDnwUw/RzT+4kmqz0ExD2EKImUbn4XTc6svYtEqo68wKTDlDD Lvx4M97dj8zjwxWaHJOLU+Ze+2BYYEyvn6pq35DGSg==
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: <> <1914607.BasjITR8KA@linux-9daj> <> <1900056.F7IrilhNgi@linux-9daj> <> <> <> <>
In-Reply-To: <>
From: Matthew Pounsett <>
Date: Wed, 20 Mar 2019 15:45:33 -0400
Message-ID: <>
To: Christian Huitema <>
Cc: Eliot Lear <>, Ted Hardie <>, DoH WG <>, Paul Vixie <>, dnsop <>
Content-Type: multipart/alternative; boundary="00000000000016a11605848bdefc"
Archived-At: <>
Subject: Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Mar 2019 19:45:49 -0000

On Tue, 19 Mar 2019 at 13:37, Christian Huitema <> wrote:

> On 3/19/2019 12:50 AM, Eliot Lear wrote:
> On 19 Mar 2019, at 01:50, Matthew Pounsett <> 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 even if it resides on the
same web server as 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.