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

Steffen Nurpmeso <steffen@sdaoden.eu> Fri, 16 August 2019 15:25 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 371B512081D for <resolverless-dns@ietfa.amsl.com>; Fri, 16 Aug 2019 08:25:40 -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, 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 Xk8RzEU-drTp for <resolverless-dns@ietfa.amsl.com>; Fri, 16 Aug 2019 08:25:36 -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 76D6C120846 for <resolverless-dns@ietf.org>; Fri, 16 Aug 2019 08:25:36 -0700 (PDT)
Received: by sdaoden.eu (Postfix, from userid 1000) id 9F2D216054; Fri, 16 Aug 2019 17:25:34 +0200 (CEST)
Date: Fri, 16 Aug 2019 17:25:32 +0200
From: Steffen Nurpmeso <steffen@sdaoden.eu>
To: Ted Lemon <mellon@fugue.com>
Cc: sy@informatik.uni-hamburg.de, resolverless-dns@ietf.org, Steffen Nurpmeso <steffen@sdaoden.eu>
Message-ID: <20190816152532.z1q1S%steffen@sdaoden.eu>
In-Reply-To: <1E5934E0-3A30-436F-B127-75F985DEFFF9@fugue.com>
References: <67d6cd75-ca8d-06cf-dd7a-b52d1416ab3f@informatik.uni-hamburg.de> <1E5934E0-3A30-436F-B127-75F985DEFFF9@fugue.com>
Mail-Followup-To: Ted Lemon <mellon@fugue.com>, 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/_sxlFOINOtgIJjpmMSWl7kYE3x4>
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: Fri, 16 Aug 2019 15:25:53 -0000

Ted Lemon wrote in <1E5934E0-3A30-436F-B127-75F985DEFFF9@fugue.com>:
 |Both of those papers talk about incompetence of operation, not about \
 |technical weaknesses. Competently operated DNSSEC will not have the \
 |problems these two papers describe. Are you aware of any technical \
 |problem with using TLSA to prevent PKI attacks, or is this just FUD?

Competence does not help if governments or companies enforce some
policy.  If they are willing to channel data and require
installation of a certificate in your CA pool, then the best you
can get is increased effort on their side, by introducing a shadow
DNS topology, unless i am mistaken.

I do not understand, and never (~18 years) did, why the complexity
of DNS is increased so much; instead of moving over to secure
transport that is.  And if you want to sign data bundles, then
those keys could also be used, they have the potential for it, do
they.  Repeatedly connect up to the root domain of your URL in
question, and collect certificates along the way, unless you have
the complete chain, which you can cache locally.  Especially if
you now even pump the data as such over an already open HTTP
channel.  But in general this looked to me the much more elegant
resolution (once i looked at DNSSEC and TSIG and said "no
(hopefully not)").  And much easier to implement, and by using
facilities of libraries which see many eyes.  And keeping the core
protocol clean.

What do you win more than (possibly) increased complexity on the
door through the wall?  But "leaving lonely people fight in dark
side streets as opposed to perceptable noise when someone enforces
entries in local CA pools"?
Just my one cent.

--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)