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

Brian Dickson <brian.peter.dickson@gmail.com> Mon, 25 March 2019 00:10 UTC

Return-Path: <brian.peter.dickson@gmail.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 4822612022E; Sun, 24 Mar 2019 17:10:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 suWIYYxcAZvZ; Sun, 24 Mar 2019 17:10:27 -0700 (PDT)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 8B9AE12022B; Sun, 24 Mar 2019 17:10:27 -0700 (PDT)
Received: by mail-qt1-x82a.google.com with SMTP id z16so8434725qtn.4; Sun, 24 Mar 2019 17:10:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=psNm504avbhSBDSUuFa+kC8Bnsssf70B2UyAO5GY/XE=; b=V5jX6cag0n4rWkR2CACcO/gRB/BSu1DZKc1cDOfy+4npYVaXzmaSn3GwOJePPiKXaB SEeGsAO1kSIgnN+8rHzmAkYFnyX7+6EGNS1bLwQBJUpe3IzrxKm6EQ4YsawqKBeXxH2r EmRK15IWcfBNrqIxpN9lcwuLUEfgC6Owwp++iUq4IcNS3wc2FzYS2Or+G/RbEKnS3V25 K3M8Lx7jjVcl+StSebUAB/6D7umU+gU4ESpyxbni0fZvSa641WBnzZa0aEFjNNO7+0g9 5HGlGDp86BiOJfJ04v3wmt2kngVaZ3QYujO9nDUFl/EgQcX/YZ6fIY8YEd9HOft1CYhU d7Pg==
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=psNm504avbhSBDSUuFa+kC8Bnsssf70B2UyAO5GY/XE=; b=LjYSbtDvwI0X76i+1N5jhQiUTNAT79h5byGe4aPFptmNIY52bskPVsQI21iGjinMCf 3u7do5yzP/eU/655lSD6WQvppdg87cXQM2u1CwYB9VbUoZ374j21J0nyPcTbH8zbGYN1 6VxZJApn9aObeQKE+flYaT39MwB92ZGSNuqtvM/iPfXaxRiDECsicx99obKfiAc2hLfi 2W57SOlJbqt/zn92ooVuqzSiXrJt+X5IWqJJ683ploJ8NIHa6jieHH3g08VU+ovWjj0k puu3yNod7URDA6QueJy61VR1Kftcfu2ZLC6cCzVVoAIk6NRRlGGtIODgvro0mLKLg3XH vhoA==
X-Gm-Message-State: APjAAAWfZ/jMF0Ujq3Q6hPVqmrAD417jIiIHM6hg8ICsAMM/CbMMpp55 GYI1McI48mceZcFZgMAUjP/IWb8rWQpm3w27Im73aFv7R+Y=
X-Google-Smtp-Source: APXvYqwyHOpw7CXdHgMk/etpuA5AOeknwJyRPR6ewE7dEq5uD8MwHyZX23uKsCyKhL0MQ1bGHz56Z48o0vrXaOAoAWU=
X-Received: by 2002:ac8:30ea:: with SMTP id w39mr18683955qta.351.1553472626549; Sun, 24 Mar 2019 17:10:26 -0700 (PDT)
MIME-Version: 1.0
References: <04C556AF-D3B3-41A5-B119-8FE5F81FB9A7@huitema.net> <1878722055.8877.1553241201213@appsuite.open-xchange.com> <CABcZeBPmpN-cEPK92QQW3bkvc41Cx5g7B_YuUXCJK3j1qF995Q@mail.gmail.com> <20190322.101434.307385973.sthaug@nethelp.no> <32A78B0C-52B6-46E5-A46F-D63D21DEC52C@sky.uk> <CAOdDvNqb2+4Az+g608QRjYt+ZdUt1L9GAc=MJM3-xd0ZNmeBEQ@mail.gmail.com> <1C720263-10E4-423B-B152-5673E115A4C1@gmail.com> <alpine.LRH.2.21.1903241755571.10798@bofh.nohats.ca>
In-Reply-To: <alpine.LRH.2.21.1903241755571.10798@bofh.nohats.ca>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Mon, 25 Mar 2019 01:10:10 +0100
Message-ID: <CAH1iCir+C-5uA3vFSEq8HykmrAD4L7Gf9zJM1OfLG_TW9SXdyQ@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: "doh@ietf.org" <doh@ietf.org>, "dnsop@ietf.org" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000012e9770584e0088e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/TxqkJpwM4rflZUa69M18kcpmq6Q>
Subject: Re: [DNSOP] [Doh] [EXTERNAL] Re: 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: Mon, 25 Mar 2019 00:10:32 -0000

On Sun, Mar 24, 2019 at 11:25 PM Paul Wouters <paul@nohats.ca>; wrote:

> On Sun, 24 Mar 2019, Brian Dickson wrote:
>
> > There is one important difference, which is that DoT uses a unique port
> number. This is important for network
> > operators in identifying encrypted DNS traffic, in order to ensure that
> implementation of security policies for
> > DNS don’t conflict with any other network policies (regardless of what
> those policies are.)
>
> The network cannot "ensure" this based on DNS. I can come on to the
> network with a DNS cache already, which is the functional equivalent
> of me refreshing my personal cache using a sneaky HTTPS connection.
> The network can never control my DNS cache. I won't let it.
>
> So while it was perhaps nice that network operators _could_ help in such
> a case, it was never a real defense against a smart network "abuser".
>
>
I am trying to keep conversation sub-threads specific to single variables.
In this case, I am interested in policy enforcement mechanisms, not what
the policy is or who it applies to.

The assumption in the above is that the network operator has some policy
(regardless of what it is) that it would like to enforce between some (or
possibly all) hosts, towards encrypted DNS services.
If the operator blocks all DoH, but does something less restrictive for
DoT, then the policies applied on DoT are the ones that have the desired
effect.

Yes, this is network-centric, or more specific, network-security-centric.

>From the perspective of the network policy enforcement, the applicable
rules involve 3-tuples of source, destination, and port 853 (plus TCP but
not UDP). Any such rules, when explicitly applied only to port 853, by
definition have no direct bearing on any destinations for port 443 (HTTPS).
These rules only need to be updated if/when new "permit" rules for new DoT
servers are added. This is a white-list model, which scales very nicely.

However, the blocking of specific DoH servers becomes an absolute
nightmare, in that the network operator needs continuously monitor
information from any number of sources (of various degrees of completeness,
trustworthiness, timeliness, etc), for new DoH servers, along with an
ongoing policy maintenance on (allow vs deny). This is, by its very nature,
a black-list model, which does not scale nicely, and consequently reduces
the overall security, from the perspective of the network operator (or
network security department of the enterprise network).

(See my previous message detailing *why* networks NEED to do this, at least
in the large enterprise.)

Chances are, the network segment you are on does not care one whit about
the DNS cache you have, and probably is happy to let you access whoever you
want for your encrypted DNS service.

I'm willing to wager, in the enterprise environment, they do have an
opinion on what transport they prefer you use for that: DoT.

This is mostly about scalability, and about the ability to detect abnormal
behavior distinct from regular user activity (malware, phishing, and other
use cases.)


> > IMNSHO, if both ports are reachable for a given provider of Do*, the DoT
> port MUST be used. DoH should only be
> > used with explicit informed user consent, and only when DoT is
> unavailable.. This supports the “dissident” use
> > case, without impacting any other aspects of privacy provided by DoT.
>
> If the network allows DoT, clearly it does not care about DoH being
> used? Since it will also not be able to read DoT to a remote server
> like the Quads. So I do not understand what is gained by such a
> policy.
>

It is about scale. If large numbers of users, across a variety of
platforms, all use only DoT, then restrictions about which DoT servers are
permitted can be applied.
Or, alternatively, access to new DoT servers can potentially alert the
appropriate security team(s) to investigate which machines have started
this new behavior, and get an early jump on things if this happens to be a
malware-infected device (for example).

Blocking specific DoT servers (or more typically, blocking all DoT servers
except those white-listed) allows end users to know that this blockage is
deliberate. Users can then make informed decisions about whether to accept
that blockage (e.g. due to enterprise policies, or perhaps ISP policies
where those are allowed according to contract and jurisdictional legal
frameworks), or to take unilateral action to bypass the blockage.

What is gained by preferring DoT over DoH, is scaling on the network
operator side, and clear indication of policy via DoT blocking.

Scaling for network operators is always an indirect win for users -- users
have to pay, directly or indirectly, for situations where technology does
not (and cannot) scale.


>
> Unless you meant "must use a local DoT server first", in which case we
> are again shifting the discussion towards when can or should you trust
> a network for anything but relaying IP packets. Because then you
> basically demand access to my decrypted DNS stream.
>

This is orthogonal to the network operators' policy. However, in the
enterprise environment, it may be the case that the local DoT server is the
only one not blocked. I would expect that the existence of that server
would be advertised (through whatever mechanism ends up being standardized,
such as DHCP).

You are correct, that is what the operator of any DoT (or DoH) gets: access
to your decrypted DNS stream.
If DoT access to all other servers is blocked, the choice then becomes, use
the local DoT server, or don't use their network (or perhaps don't use DNS).
This is the exact same situation as when port 53 is restricted,
intercepted, or content-tampered, except it adds DNS-to-client encryption.
Whether the DNS results can be trusted is one question.
Whether the privacy practices of the DNS operator is a separate question.
Both are important.

BTW - the trustworthiness of the responses is something that can be, to a
limited degree, mitigated by client DNSSEC validation, when the DNS zones
the client is interested are DNSSEC signed.

I would argue the lack of client DNSSEC validation is one factor in the
slow uptake of DNSSEC on the part of DNS registrants. Adding DNSSEC client
validation would eliminate that as a factor.


>
> Why should I ever use a starbucks DNS server, regardless of whether
> I use DoT or DoH or plain 53? On almost every network I connect to,
> I only want one service: "relay my (encrypted) IP packets". The rest
> of the services I obtain from trusted sources elsewhere, using this
> ephemeral network as an insecure transport only.
>

I don't see why everyone presumes that using Starbucks' networks is a
right, or the only option available.
I know they operate a lot of wifi networks, but how they do so isn't really
anything users of their networks have a direct say in.
Your argument says a lot more about use of encrypted data transport (e.g.
over VPNs), than it does about DNS.
Can't you just run your DNS queries over your VPNs as well? I don't see a
problem with doing so, at all.


>
> So your policy above that you propose really assumes a lot about the
> network, namely that you are considered hostile to the network and
> that you trust that network more than your own device. That's a very
> specific application. It basically never applies to me unless I join
> an enterprise network with an enterprise device, and then we have
> other ways for the enterprise to enforce things on their device.
>

I'm making an "IF THEN" argument, without specifically taking any position
on the conditional being evaluated.

Even if there are other ways, the position you are taking is making a
decision on their behalf.
You are expressing the opinion that because there is a specific way
available, that that way is reasonable to propose as the only mechanism
permitted.
I am arguing a position that enterprises are free to choose the mechanisms
they use for enforcing policies.

It should be noted (strongly) that device-side enforcement somehow assumes
the device itself is reasonably trust-worthy.
If the device-side enforcement is the only mechanism, then the scope of
device compromise events is much greater than the device itself.
If the network enforces (with or without device-side enforcement, i.e. it
does not preclude doing both in a belt+suspenders approach) policies, more
control over the impact of device compromise is achieved.
(This is particularly important in the case where data exfiltration over
DNS is attempted by malware using the local device's own available DNS
mechanisms. If DoH is available and not blocked, data exfiltration is
nearly trivial. If DoH is not available, and DoT is only possible to the
enterprise DNS servers, the enterprise is in a position to contain the
situation.)


>
> > The blocking of DoT to a given provider should be interpreted as an
> explicit policy. Users should be informed
> > that they may, and very likely will, be violating someone’s policy, if
> they choose to use DoH in that
> > circumstance, and that they may be violating laws by doing so, and
> should only do so if they are willing to
> > accept that risk.
>
> Again, this is the network operator centric view. There are many hostile
> networks that would block DoT just so that they could monetize (legally
> or illegally!) from my harvested DNS data. I can assure you the warning
> you want to write to users would be very different from the warning I
> would want to give those users. Which is why the IETF doesn't do
> banners towards endusers.
>

So, yes, I actually agree with you in this section.

I'm not saying that bypassing blocks should not be supported by software.
I am saying that bypassing blocks requires a lot of user information, user
consent, and should never be the shipped default for software.
I'm also saying that use of DoH should be the exception, used only when
there is no alternative, in a given scenario.
I'm saying DoH needs to be at least opt-in, never opt-out.

And I believe user preferences should never assume the user is willing to
accept degraded privacy options; the user should be able to provide a list
of acceptable DNS privacy operators, and if none are reachable, have two
options: don't use any other DNS services (and basically, don't use the
network), or explicitly attempt to bypass the mechanisms preventing access
to one of the acceptable DNS operators.

Placing DoT ahead of DoH, does not in any way degrade the connection
privacy if the DoT provider is accessible. It does, however, improve the
network operator's security posture.
Thus, for the user it is "a wash", and for the network operator "a huge
win".
I do not understand why advocating for DoT preference is a contentious
issue, if DoT is available.


>
> Besides, why should the network operator have a say about when I want my
> device to connect to my remote servers? Do you want my VPN client to
> throw the same warning around that it might be against the network
> operator's wishes to inspect all my traffic and it might be against the
> law to circumvent it? Then you also have to do that for _all_ TLS
> connections, and make the internet go back to port 80. Why is there a
> different expectation of website content monitoring versus dns content
> monitoring? You shouldn't have access to either.
>

That is an issue for network operators' policies, which is really
orthogonal to the mechanisms.

There are legitimate reasons that network operators would want to inspect
(via automated threat mitigation systems) all DNS traffic.
I would find it objectionable if any network operator did anything other
than the above, to DNS traffic.
DNSSEC is one way to keep DNS operators relatively honest, at least on the
"dns lies" front (monetizing NXDOMAIN by replacing NXDOMAIN responses with
forged answers).
Limitations on what network operators are allowed to do is a layer-8 or
layer-9 problem, not directly tied to the mechanisms, and should be treated
as such.

(And yes, I realize VPNs are also problematic from the enterprise
perspective, as they could also be used for data exfiltration -- but that
is why reasonable trade-offs in differentiated restrictions based on
security zones are, or should be, best practices for enterprises.)

On non-enterprise networks, I am pretty sure I don't want to see any of
your traffic, VPN or DNS or anything else.

IMHO, monitoring of dns queries should be divorced from PII, and should not
be routinely logged (especially not with PII), except perhaps on an
aggregate basis. Security monitoring, alerting, and logging, should itself
be restricted access, and safeguards should be put in place to prevent
abuse.

This doesn't change my position on the mechanisms required to permit
scalable security operations at the network level.


>
> > There is no reason DoH should be used if DoT works (towards the same DNS
> provider).
>
> If DoT works to dot.nohats.ca, which you cannot decrypt, why do you care
> whether I use DoH to that server or not?
>
>
The reason I care, is that I want to observe all the DoT connections on a
longitudinal basis. I want to see if/when new DoT servers show up,
especially on names that do not indicate peaceful operation.
And if I see a new DoT server show up with some really random name, in a
place I don't expect my networks' users to be using (like Asia somewhere),
with a very recently obtained free LetsEncrypt certificate, I might want to
block the DoT port toward that server, and possibly block all DoT servers
except for my local DoT server, for that client, so I can inspect the DNS
traffic itself.

Having the ability to limit the inspection of DNS traffic to incident
responses, is not only good for the general user population, but also for
the incident responders. If there is one DNS query flow showing up, it
makes analysis a heckuvalot easier, than sifting through a fire hose of DNS
traffic.

I also expect DoT traffic to be several orders of magnitude lower than
HTTPS traffic, where attempting to distinguish DoH from HTTPS traffic would
have immediate cost implications in flow volume and destination variety.

I care about you using DoT, not because I don't trust you, but because I do
trust you.

Brian