Re: [Resolverless-dns] Paper on Resolver-less DNS

Paul Vixie <paul@redbarn.org> Tue, 20 August 2019 07:03 UTC

Return-Path: <paul@redbarn.org>
X-Original-To: resolverless-dns@ietfa.amsl.com
Delivered-To: resolverless-dns@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A29120870 for <resolverless-dns@ietfa.amsl.com>; Tue, 20 Aug 2019 00:03:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 Unx0XtwyeMnd for <resolverless-dns@ietfa.amsl.com>; Tue, 20 Aug 2019 00:03:54 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CFA81200B3 for <resolverless-dns@ietf.org>; Tue, 20 Aug 2019 00:03:54 -0700 (PDT)
Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 9CC4E892E8; Tue, 20 Aug 2019 07:03:51 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: resolverless-dns@ietf.org
Cc: Anne Bennett <anne@encs.concordia.ca>
Date: Tue, 20 Aug 2019 07:03:35 +0000
Message-ID: <4328897.o8lPr2jyQz@linux-9daj>
Organization: none
In-Reply-To: <24529.1566231048@vindemiatrix.encs.concordia.ca>
References: <CAHbrMsBhR1yaLxQk7wZk54Jdf5nvkS03KC3UTae0Famu2+SV8g@mail.gmail.com> <9323236.5EVOHOzQma@linux-9daj> <24529.1566231048@vindemiatrix.encs.concordia.ca>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="nextPart1947839.oB0V7SU3dg"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/j8v1LkJ7SNfFML4Ee7zcPPE5T4o>
Subject: Re: [Resolverless-dns] Paper on Resolver-less DNS
X-BeenThere: resolverless-dns@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Resolverless DNS <resolverless-dns.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/resolverless-dns>, <mailto:resolverless-dns-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/resolverless-dns/>
List-Post: <mailto:resolverless-dns@ietf.org>
List-Help: <mailto:resolverless-dns-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/resolverless-dns>, <mailto:resolverless-dns-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Aug 2019 07:03:56 -0000

On Monday, 19 August 2019 16:10:48 UTC Anne Bennett wrote:
...
> AB>> I would think this to be an impossible task;
> 
> PV> this draft in another wg appears to be an attempt at such:
> PV> https://datatracker.ietf.org/doc/draft-sah-resolver-information/
> PV>
> PV> i don't know if it can meet the "reliably detected" threshold though.
> 
> I took a quick look at the above draft; it specifies a method
> for enquiring about "features of a recursive resolver", but
> gives no ideas or guidance as to what such features might
> consist of, aside from a brief sentence fragment in the
> abstract, "such as whether they perform DNSSEC validation or
> are available over transports other than what is defined in
> RFC 1035".

ah. that's my misunderstanding then. i thought "has policy" was one of the assigned 
indicators. it should be.

> It seems to me straightforward to use this mechanism to supply
> the information *that* a resolver applies filtering, but I don't
> see how it could reasonably *describe* the filtering, since
> such a description would essentially almost *be* the filtering.

i would not, and we could not, export that policy. it's often proprietary. only the existence 
of policy, which ought to disable any "app doing DNS" (ADD) from doing DNS, is needed.

> I think your polite assumption that it could be possible for
> resolverless DNS to respect a network operator's policies for
> DNS filtering is, well, polite.  ;-)

the resolverless people are, like the DoH people, noncriminals with good hearts lacking 
only some understanding of how criminals use the internet (and the subset of the 
internet called the web, and the fact that the web is a subset of something). i believe that 
they will write a spec that recommends respect for the choices made by system and 
network operators, and i believe that vendors will implement it that way. 

which means i believe that netflow will continue to be useful in finding malware, because 
it won't follow the rules. (for a great time, find somebody from sony and ask how much 
money they would pay in modern dollars to move to the timeline where they knew about 
north korea the day after they got in.)

> .... which brings us to:
> 
> ES>> we talked about possible privacy drawbacks of resolver-less
> ES>> DNS. However, did we talk about the privacy risks of using a
> ES>> traditional DNS resolver? They can monitor the entire browsing
> ES>> activities of a user and present the real privacy problem.
> 
> PV> DoT (RFC 7858) corrects that privacy problem and is being deployed.
> 
> I dispute the idea that DNS over TLS addresses the privacy
> problem of the resolver operator having access to all of a
> user's DNS queries.

i think our ships are passing in the night. "traditional dns resolver" means one you run on 
your campus, on your LAN, on your hypervisor, on your endpoint. this whole "public DNS" 
bullpucky is entirely non-traditional. 

see also:

https://www.darkreading.com/vulnerabilities---threats/benefits-of-dns-service-locality/a/
d-id/1333088[1] 

> That being said, I think that stating that traditional DNS has the
> "real privacy problem", and implying that resolverless DNS doesn't
> suffer from a similar problem, is disingenuous.

resolverless is questionless. no knowledge of user intent is leaked, only knowledge of 
user probable next steps. this is an important difference, though it's entirely 
noncompelling. my network policy is that i be able to monitor and filter DNS. if that 
means i end up outlawing some web browsers or some web server IP addresses because 
they want to sneak their DNS translations through as questionless unvalidated 
unmonitorable unfilterable assertions of pseudo-fact, then that's the war i'll be in. note, i 
won't choose it, but i won't shirk it either.

> If I ask a question and expect an answer, *someone* has to hear my
> question!  Who would I rather trust: an ISP whose services I pay for,
> or a commercial web site where most likely, I *am* the product?

again, resolverless means there are no questions. so while it's a huge problem for 
internet security unless it respects the existence of filtering by local resolvers and unless 
it respects the same-origin policy, it's a DIFFERENT problem than the one that DoH claims 
to solve using Big Lie techniques.

-- 
Paul

--------
[1] https://www.darkreading.com/vulnerabilities---threats/benefits-of-dns-service-locality/
a/d-id/1333088