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

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 27 August 2019 21:39 UTC

Return-Path: <ietf-dane@dukhovni.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 CF734120113 for <resolverless-dns@ietfa.amsl.com>; Tue, 27 Aug 2019 14:39:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 tsWXh2wEjk2t for <resolverless-dns@ietfa.amsl.com>; Tue, 27 Aug 2019 14:39:49 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8042812004D for <resolverless-dns@ietf.org>; Tue, 27 Aug 2019 14:39:49 -0700 (PDT)
Received: from [10.200.2.180] (sdzac10-108-1-nat.nje.twosigma.com [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id B3BAB3FC1F for <resolverless-dns@ietf.org>; Tue, 27 Aug 2019 17:39:48 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <f093a605-6e7d-0237-df5c-441d6789c66f@erik-sy.de>
Date: Tue, 27 Aug 2019 17:39:47 -0400
Content-Transfer-Encoding: 7bit
Reply-To: resolverless-dns@ietf.org
Message-Id: <54892F22-27E4-4444-9CC8-2D9E84A9668F@dukhovni.org>
References: <CAHbrMsBhR1yaLxQk7wZk54Jdf5nvkS03KC3UTae0Famu2+SV8g@mail.gmail.com> <4568720.uvMTqBdgP4@linux-9daj> <fb12f102-714d-95cc-c6cc-0871a2df9f50@informatik.uni-hamburg.de> <34813218.VKkrhzyXsx@linux-9daj> <ae355776-a1bb-cf23-f380-133439661d1f@informatik.uni-hamburg.de> <1171283855.590.1566558699991@appsuite-gw1.open-xchange.com> <a8d9398b-4fea-0a1e-3fa7-5954d001f9ea@informatik.uni-hamburg.de> <1405682425.665.1566561941610@appsuite-gw1.open-xchange.com> <220061a8-608c-0a87-4656-213c87979284@informatik.uni-hamburg.de> <849BE7D4-A07E-496B-B413-E1C979390DA8@osterweil.net> <b2b3e56a-c577-f08a-627a-f54e2e6fadb6@informatik.uni-hamburg.de> <f093a605-6e7d-0237-df5c-441d6789c66f@erik-sy.de>
To: resolverless-dns@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/3ArgvPvT7wVC-KTl5udykm8LVQQ>
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, 27 Aug 2019 21:39:52 -0000

> On Aug 27, 2019, at 5:18 PM, Erik Sy <email@erik-sy.de> wrote:
> 
> It seems to me, that both of you are OK with the risk of DNSSEC + DANE
> TLSA leading to hard failures.

I also deny beating my spouse...  Seriously, the premise of the question
"are you OK with the risk of DANE leading to hard failures" is flawed.
Hard failures are the purpose of security mechanisms.  Of course I am
OK with a security mechanism that may deny access, that's not the
right question.

The right question is whether a given mechanism is sufficiently robust
to be usable.  HPKP fails that criterion, but DANE does not suffer the
same design flaws.

Like anything not yet widely deployed for years, DANE still requires
some operator experience and improved tooling (monitoring and
deployment) to further reduce opportunities for operator error, but
there is no fundamental obstacle to robust DANE deployment as there
was with HPKP, and DANE is already considerably more robust in
practice.

> I share the view of Chris Palmer, that
> the security improvements of Public Key Pinning (PKP) in browsers are
> not worth the caused usability issues.

HPKP is irrelevant to the discussion.

> I like to point out, that resolver-less DNS can be extended to support
> DNSSEC + DANE TLSA as a validation mechanism for DNS records. Thus, in
> case browser vendors decide to support DNSSEC + DANE TLSA the browsers
> can receive the corresponding records also via resolver-less DNS.

Actually, we've been down that road already (TLS DNSSEC chain
extension fiasco).  There is no clean way to provide downgrade
resistance in such a protocol, or even properly ensure that
answers are in bailiwick.  I doubt you are proposing that servers
MUST always return a full DNSSEC validation chain for the returned
RRsets (or denial of existence proofs for the associated DS RRs).

My take is that cache-poisoning-as-a-service is unlikely to be a good
idea.

-- 
	Viktor.