Re: DNSSEC architecture vs reality

Andrew McConachie <> Tue, 13 April 2021 08:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7AD353A0C44 for <>; Tue, 13 Apr 2021 01:46:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id l0MIMLPIEwY3 for <>; Tue, 13 Apr 2021 01:46:28 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 35B593A0C40 for <>; Tue, 13 Apr 2021 01:46:28 -0700 (PDT)
Received: by with SMTP id g5so17935294ejx.0 for <>; Tue, 13 Apr 2021 01:46:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=+ZbDDGHA8CceL5Vm1NwHyjV7mqvhB4/Vafgip8xJI1s=; b=VoBcnT47svvxFnuuRDATSvs1pR9EUw6u2gX6nzYvyyZjRHw3bsdiTZgr+u/1HM6NLB SpNivOaQxx8BSDPpbyih/oNDOiHyXmS9I1WrHG2VBvc1P/OH+ZbOzBTYSP07YU6qKlH2 QX/0cCmD5Ogvjqw72hhrhmQ660XZhBCWZUnPqLvcl7C7uht5HnWLHJSgceiYMV2X+a6b N5QQOMfgjs2uC2k+ByBnWEDx8KpxWsvtY2R7ply2KxmTBNT7sw/I6F254srkP++ppBKD nFu6ZI0xz5YgOhY5Y5YnKbbd5+qWYjsHuuMtE37TY3+AO8lJPL2kaZgq49qDY6DB8kR7 vBHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=+ZbDDGHA8CceL5Vm1NwHyjV7mqvhB4/Vafgip8xJI1s=; b=os62qBRUExPd6zt4RPjupF+8MQn89c19aT810I5quDkQc8zFc8SsOKJk72Q9082AVH CrZ4oNIev8i5X9G+Z9K/o36MtNrRd2AFxDukaK7Vnw6+rv3bLlZRSgZ5ugNu0v2BawHI +dPEnw3k/Sd9lhK5SVMM4xq0/Rf7W71Ez5j5B+FVTq0NZTqXC+tTViOpc+Ac/ygdfXhr VpcEeFxB089WFA690xDgXrpKAQijY9WJmerix6xToKH+2BDIdY+Bh0Awg24T5SQt1bqJ nzf0k8VSJBG1zm/CPyRsu8Im/ad/ztu09d5GQCkDr668VAowaBR52YPZ45cHf9EHxu0k nkLg==
X-Gm-Message-State: AOAM531+fblCH41MICTERuNetp3zK/VnlJuiz8tMbBae0s2yW8nc5joV x2lG+DC3Fmtjy5bLGqqcGSR0cstdtb7zbU6m
X-Google-Smtp-Source: ABdhPJw5j0Jbf4HusvsmxPZ9jFCHPPGT2rwQNYTEfbqkwEY6pfagaaj4Q1sLfpOuPdOV2nM6axI2jg==
X-Received: by 2002:a17:907:264f:: with SMTP id ar15mr12794580ejc.484.1618303585692; Tue, 13 Apr 2021 01:46:25 -0700 (PDT)
Received: from [] ([2a02:a212:9285:29f0:b9a8:4c39:6094:68b3]) by with ESMTPSA id mj7sm5337878ejb.39.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Apr 2021 01:46:25 -0700 (PDT)
From: "Andrew McConachie" <>
To: "Nico Williams" <>
Cc: "Michael Thomas" <>,
Subject: Re: DNSSEC architecture vs reality
Date: Tue, 13 Apr 2021 10:46:24 +0200
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <>
In-Reply-To: <20210412222748.GW9612@localhost>
References: <> <> <> <> <> <> <> <> <20210412221435.GV9612@localhost> <> <20210412222748.GW9612@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown
Content-Transfer-Encoding: 8bit
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Apr 2021 08:46:30 -0000

On 13 Apr 2021, at 0:27, Nico Williams wrote:

> On Mon, Apr 12, 2021 at 03:17:32PM -0700, Michael Thomas wrote:
>>> (1) may have been because of (2), and I believe (2) was because of
>>> internal technical and political issues.  I.e., I would not consider 
>>> it
>>> dispositive that Google seemed to like DANE then gave up on it, 
>>> though
>>> that and why they did certainly is germane.
>> Yes, that's what I would assume as well. Build it and they will come 
>> has a
>> sterling track record of failure in IETF.
> Building a technical spec is not enough, indeed.  DANE hasn't 
> succeeded
> yet, and neither has DNSSEC.  But DANE is starting to gather steam (in
> no small part due to Viktor's efforts) in the realm of SMTP.  The fact
> that DANE was early for its time doesn't mean that the single root and
> unyielding name constraints aren't appealing or appealing enough to 
> make
> a more serious try now.
> As noted, the tooling for DNSSEC has been substantially improved in
> recent years.  Implementations of DANE do exist now.  There are a 
> number
> of missing elements, such as a TLS extension to staple DANE that
> supports authenticated denial of existence.  We're making progress
> though.  It may seem slow, but there may be a preference cascade at 
> some
> point.  It may only take enough user-agent, and registrar / domain
> hosting services to provide this functionality to make it popular.

There’s been too much focus on getting browsers to implement 
HTTPS/DANE. These days HTTPS is used for all kinds of stuff that has 
nothing to do with the web. Take the Fediverse for example. ActivityPub 
uses HTTPS for server-server communication in a manner similar to how 
MTAs use SMTP. There are plenty of other examples.

My point is that if people want to see HTTPS/DANE deployments grow they 
should start hacking HTTPS/DANE validation into the numerous open source 
projects that act as HTTPS clients. Find communities of geeks to act as 
early adopters, and simply ignore the politics of large browser vendors 
as they’re obviously a lost cause.