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

Ted Lemon <mellon@fugue.com> Fri, 16 August 2019 15:54 UTC

Return-Path: <mellon@fugue.com>
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 282E71207FC for <resolverless-dns@ietfa.amsl.com>; Fri, 16 Aug 2019 08:54:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 Ya6HuB21aW3y for <resolverless-dns@ietfa.amsl.com>; Fri, 16 Aug 2019 08:54:12 -0700 (PDT)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 6383312029C for <resolverless-dns@ietf.org>; Fri, 16 Aug 2019 08:54:12 -0700 (PDT)
Received: by mail-qk1-x730.google.com with SMTP id g17so5072613qkk.8 for <resolverless-dns@ietf.org>; Fri, 16 Aug 2019 08:54:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=mldCPyapcgn9G947hVwaIJyQ45F+5eXGhK+el1tvLJ8=; b=mlOZPOtJLw6RVjN8us0kOw2022tCeTdaTQjXTKC0+t9fOoG2DdcT8gUpmrUaz18pSJ s8C/kQiC235yBZ0ox4nOSaaSdYAD29N4gcDDqVFMWEm5dWCGZP2XE+x0j1eUCpFa+U3F Pmz7RNTJZvJjnPwT1ilk0LTyac3M130RoZm5SBXwdxt/Jd9O0lIaI2awDZlsaSa51dIW sVbF8nhNaBxto59pIBDHJBOG4uiWwrp2+EB7EdFSMZFemY6gP6sbDtzdAT1Cjw/fqkHN SqmJUt6V+IhNeMcjhNZJ5UbAb96SGvxUesSVO2CZtcvtEBWnHCruck8J7bCsEmjxvg8b T/Bg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=mldCPyapcgn9G947hVwaIJyQ45F+5eXGhK+el1tvLJ8=; b=Sg5CPknt6FWxRky6VDWQUdExKQRm+mhmDaPzyeo27Cd6jlXSxWrTXWxW5IYRFHK4cO yik4hiZgNgUg/ACKyXVIGfAb/zeqRW7hqsic2SZczw9W05rnJLuVBUX7A0nDR3e2X6R1 nlmaFaGz0R9CNzRV/XiehWjv/0SQGWSwgRCgoViFZ4xvQe/qCj4XaojKxE2dPPRLH4Cd 1rtkuhyqaWo6xYsOlrj+J0y/amXRTjYMLTzcP53Ltp2SEhxMW3rlw8EqH7zr3+4FVBc1 QLWxYa4mHULNRpico7z+7fgU8rumruavPi2FAdhJUFf4+T6StTat5Gpp3KT8VsKLgPxr LF2w==
X-Gm-Message-State: APjAAAW2vjKHqW/7rfMf23h/zi3DCkBDW8BhQXTY0Jd6z/HClLTz10mb E0DZeaHDcleSAWSAjMuP0PLYVg==
X-Google-Smtp-Source: APXvYqyL0dYiDng908XTgug2SuSZdMY7rybUaXrvuP+ScBHz0szfbti08swemv8lNH6VIrz8JETocA==
X-Received: by 2002:a37:b381:: with SMTP id c123mr9628433qkf.349.1565970851498; Fri, 16 Aug 2019 08:54:11 -0700 (PDT)
Received: from [10.0.100.56] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id h26sm3311206qta.58.2019.08.16.08.54.10 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Fri, 16 Aug 2019 08:54:11 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-C6FB4F8E-880A-4397-908E-38865D37826F"
Content-Transfer-Encoding: 7bit
From: Ted Lemon <mellon@fugue.com>
Mime-Version: 1.0 (1.0)
Date: Fri, 16 Aug 2019 11:54:10 -0400
Message-Id: <954B86B4-92A2-411A-9F45-C87CF0A4985A@fugue.com>
References: <20190816152532.z1q1S%steffen@sdaoden.eu>
Cc: sy@informatik.uni-hamburg.de, resolverless-dns@ietf.org
In-Reply-To: <20190816152532.z1q1S%steffen@sdaoden.eu>
To: Steffen Nurpmeso <steffen@sdaoden.eu>
X-Mailer: iPhone Mail (17A568)
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/A-lMc-rtbbXRDalI0iyKRimtYOM>
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:54:15 -0000

DNSSEC lets you check that the cert you have been offered is for a key that the site actually uses. Of course DNSSEC can be blocked, but it can’t be blocked undetectably.  So with DNSSEC you can at least know that you are under attack and decide whether to proceed. 

It’s also true that sometimes state actors openly break PKI, and that we can’t do anything about that systemically. But when state actors or others secretly break PKI, having a way to detect that is very beneficial. 

Sent from my iPhone

> On Aug 16, 2019, at 11:25, Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
> 
> 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)