IETF Logo Mail Archive

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

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 27 August 2019 18:45 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 12EE0120861 for <resolverless-dns@ietfa.amsl.com>; Tue, 27 Aug 2019 11:45:32 -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 FUrFVQZ09O9G for <resolverless-dns@ietfa.amsl.com>; Tue, 27 Aug 2019 11:45:30 -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 F2FB2120133 for <resolverless-dns@ietf.org>; Tue, 27 Aug 2019 11:45:29 -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 488BA3F625 for <resolverless-dns@ietf.org>; Tue, 27 Aug 2019 14:45:29 -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: <b2b3e56a-c577-f08a-627a-f54e2e6fadb6@informatik.uni-hamburg.de>
Date: Tue, 27 Aug 2019 14:45:28 -0400
Content-Transfer-Encoding: 7bit
Reply-To: resolverless-dns@ietf.org
Message-Id: <FC1191C5-DA21-43B0-915F-D1E6CF7C0C81@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>
To: resolverless-dns@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/EJdPWs3tuVyfmdfDq82ka6XvcpA>
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 18:45:32 -0000

> On Aug 25, 2019, at 4:40 PM, Erik Sy <sy@informatik.uni-hamburg.de> wrote:
> 
> As for DANE, it would at best have the same strength/weakness of HPKP,
> but with the additional problems of DNSSEC."

False analogies tend to lead to irrelevant conclusions.

> In total, it seems like Chrome does not want to deploy DANE.

Yes, the browser vendors are presently not looking to implement DANE.
The initial deployment of DANE is instead happening in SMTP.

DNSSEC adoption is held back by process barriers at the registrant to
registrar interface.  We need a widely deployed less burdensome way to
initially publish and subsequently update zone KSKs.  I'd also like to
see better automation of ZSK rollover.

More work remains to be done to lower the barriers and increase the
incentives.  Ideally, more of the critiques of DNSSEC would be in
the form of positive contributions to improve the tools and promote
interoperable KSK management.

-- 
	Viktor.

v2.26.15 | Report a Bug | By Email | System Status