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

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 27 August 2019 18:29 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 D54F712083E for <resolverless-dns@ietfa.amsl.com>; Tue, 27 Aug 2019 11:29:45 -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 TpxWGsCNwXdA for <resolverless-dns@ietfa.amsl.com>; Tue, 27 Aug 2019 11:29:38 -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 A5D0D12084D for <resolverless-dns@ietf.org>; Tue, 27 Aug 2019 11:29:34 -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 B8EEF3F540 for <resolverless-dns@ietf.org>; Tue, 27 Aug 2019 14:29:33 -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: <ae355776-a1bb-cf23-f380-133439661d1f@informatik.uni-hamburg.de>
Date: Tue, 27 Aug 2019 14:29:33 -0400
Content-Transfer-Encoding: 7bit
Reply-To: resolverless-dns@ietf.org
Message-Id: <9CB98019-37C7-41A6-87B1-ACF4A7B337ED@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>
To: resolverless-dns@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/xsOWdgClY3chZodH2W6LYNerYWY>
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:29:46 -0000

> On Aug 23, 2019, at 5:37 AM, Erik Sy <sy@informatik.uni-hamburg.de>; wrote:
> 
> In my view, DANE TLSA is an approach to do public key pinning.

The analogy is deeply flawed.  HPKP has keys pinned by *clients* that
may contact the server sufficiently infrequently to make stale keys an
intractable problem.  HPKP is also provides no protection on first
contact.

With DANE, on the other hand, the keys are published in the server's
DNS zone, and refreshed by the server operator's DNS administrator
independently of any client activity.  TLSA record TTLs are typically
an hour or less, and otherwise rarely more than a day.  A client that
implements DANE is protected on first contact.

> The web
> already collected a lot of experience with public key pinning as this
> can be also done using other protocols than DNS.

The inevitable failure of HPKP was obvious (to me and doubtless not
me alone) from the outset.  Stateful client-side key pinning does not
scale.

DANE does not share the problems of HPKP.  Yes some server operators
may be negligent and publish stale TLSA RRs, but *they* can fix this
promptly, just as they would with expired certificates (a TLSA record
is essentially a trust-anchor, it may directly designate a trusted 
leaf key or in many cases a trusted issuer).

Any perceived similarity between DANE and HPKP is largely the result
of lack of familiarity with DANE.

DANE is currently employed on 6000 SMTP MX hosts serving 1.22 million
email domains.  Only ~500 domains have stale TLSA records, and the
number should go down as more senders enable DANE, making broken
deployments more visible to negligent operators.

-- 
	Viktor.