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

Steffen Nurpmeso <steffen@sdaoden.eu> Sat, 17 August 2019 20:20 UTC

Return-Path: <steffen@sdaoden.eu>
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 919FB120118 for <resolverless-dns@ietfa.amsl.com>; Sat, 17 Aug 2019 13:20:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 Eo8Ulr9W0EeZ for <resolverless-dns@ietfa.amsl.com>; Sat, 17 Aug 2019 13:20:51 -0700 (PDT)
Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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 A300B12007A for <resolverless-dns@ietf.org>; Sat, 17 Aug 2019 13:20:51 -0700 (PDT)
Received: by sdaoden.eu (Postfix, from userid 1000) id 018C816054; Sat, 17 Aug 2019 22:20:49 +0200 (CEST)
Date: Sat, 17 Aug 2019 22:20:48 +0200
From: Steffen Nurpmeso <steffen@sdaoden.eu>
To: Erik Sy <sy@informatik.uni-hamburg.de>
Cc: resolverless-dns@ietf.org, Steffen Nurpmeso <steffen@sdaoden.eu>
Message-ID: <20190817202048.7FUTd%steffen@sdaoden.eu>
In-Reply-To: <fe3af997-096d-82e8-b9c5-7e6c17558514@informatik.uni-hamburg.de>
References: <CAHbrMsBhR1yaLxQk7wZk54Jdf5nvkS03KC3UTae0Famu2+SV8g@mail.gmail.com> <16840451.Gnsi7N2eSB@linux-9daj> <71662803-f194-a921-84da-b8c9e8e32cb5@informatik.uni-hamburg.de> <6216510.zdPCGfSLMl@linux-9daj> <fe3af997-096d-82e8-b9c5-7e6c17558514@informatik.uni-hamburg.de>
Mail-Followup-To: Erik Sy <sy@informatik.uni-hamburg.de>, resolverless-dns@ietf.org, Steffen Nurpmeso <steffen@sdaoden.eu>
User-Agent: s-nail v14.9.14-31-g02ec9e48
OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt
BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs.
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/Wl8AIm1h9Qz9SRlsb2zaxwo2AB4>
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: Sat, 17 Aug 2019 20:20:54 -0000

Erik Sy wrote in <fe3af997-096d-82e8-b9c5-7e6c17558514@informatik.uni-ha\
mburg.de>:
 |On 8/17/19 07:39, Paul Vixie wrote:
 |> On Friday, 16 August 2019 21:52:40 UTC Erik Sy wrote:
 |>> On 8/16/19 23:02, Paul Vixie wrote:
 ...
 |>> Clients using a traditional DNS resolver do not care about a validation
 |>> of those DNS records.
 |> i have significant evidence to the contrary.
 |Can you please share your evidence?

 |>> In this thread, we talked about possible privacy drawbacks of
 |>> resolver-less DNS. However, did we talk about the privacy risks of using
 |>> a traditional DNS resolver? They can monitor the entire browsing
 |>> activities of a user and present the real privacy problem.
 |> DoT (RFC 7858) corrects that privacy problem and is being deployed.

That is cool, btw., and i truly had an eruption of joy once that
(these) RFC(s) came along!  I personally do not really understand
why this data (certificates) absolutely has to be stored in the
DNS itself, but that is me and i am talking from the view of
implementing the fully caching stub resolver that i once did.
And so many RFCs have been produced on that topic, and exist,
anyway.

 |The privacy problem is that a significant share of DNS resolvers monitor
 |the users' online activities, aggregate these data in user profiles and
 |use these profiles within behavioral advertising or share these user
 |profiles with other parties. Here [1], you can find a comparative
 |analysis of public DNS resolver privacy policies substantiating my claims.
 |
 |Transport encryption for DNS records does not mitigate the privacy
 |problem presented by DNS resolvers. Indeed, DoT facilitates the linking
 |of DNS queries to specific user profiles. Previously, machine learning
 |based on behavioral DNS pattern was required to reidentify a user after
 |a change of its IP address [2]. DoT and DoH allow the DNS resolver to
 |link user activities precisely based on TLS session resumption because
 |these protocols compensate the costs of a full TLS handshake across
 |several resumed sessions [3].
 |Thus, DoT and DoH do not contribute mitigating the privacy problem
 |centering around DNS resolver.

Collecting data is a real and hard so-called business (maybe "the
root of all evil to- ooday"), at least in the hard west, like the
U.S.[1].
 
  [1] https://www.schneier.com/essays/archives/2018/03/its_not_just_faceboo.html

So even if HTTP/2 does its best to hide more behind crypto, and of
course thinking about the issue and trying to give more privacy
back to users is honourable, people have their smart phone in
bedroom/toilet/car/funeral, their car is online, their household
appliances are online etc.  In April i bought my first new box in
ten years, and out of interest installed the default Windows, for
me the first since Windows 95B, and i got really frightened by the
questions and, yes, services that installation asked and/or
offered.  (It was possible to turn all off, iirc.)  In 2009
i bought an Apple (wanted one once in my life), and i still grim
when i think back and recall the hundreds of megabytes of data
a "software update" collection send over the internet; when
i compare with the much less than 10MB that an update of the Linux
and *BSD distributions take, and these are entire package
collections with tens of thousands of packages.
You have credit cards, and you use it.  Mind you, maybe you even
use amazon, facebook, twitter, paypal, or any such company, which
i do not.

Once this resolverless DNS came up already i seem to remember the
idea to create a kind of "mini per-connection tor", at least
regarding DNS data.  But then you have "islands" of caching
resolvers all along the way, to which you will be able to talk
encrypted via TLS/DTLS soon, hopefully.  (Hopefully in the sense
that i put trust everywhere, and thus also in the DNS endpoint
i am actually talking to.  I personally would have nothing against
TSIGs on data sent from it, too.  And if some HTTP/2 speaking
browser can use and verify DNS binary blobs coming over from the
HTTP server all i personally feel about that is that those
software monsters can do that and reuse the anyway open connection
they sit upon, because why not.  But i do not think it will heal
the world, i would guess that all it will possibly do, and maybe
only temporary even, is that it makes the mesh more broad.  At the
cost of increased complexity and even more technical aspects to
adhere to; but rather a HTTP than a DNS problem, me thinks.
I think that is what i wanted to say.)

A nice Sunday everybody!
Ciao from (and to) Germany,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)