Re: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)

Paul Wouters <> Tue, 20 March 2018 13:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23A3D1275F4 for <>; Tue, 20 Mar 2018 06:48:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ROAjvOtPuEPd for <>; Tue, 20 Mar 2018 06:48:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D469D124B17 for <>; Tue, 20 Mar 2018 06:48:38 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 405DmL6W01z3Hj; Tue, 20 Mar 2018 14:48:34 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1521553714; bh=6iTXFVjoKF64GLKWSl/AG5cYDwe0vRAt+v3gCd7OPcQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=qkjhTOUz1uXhxKf2lPh1eV67eDj4rMkoU8Ci5I6zkLgQrJJEoX40ExW5yf/GbPt/+ CPo/LaDE5F2oHwokCDhZqZ/E0cgSKyPMuawgFuDfRb3I0q16a5CiQP7KPEwA2BN9l+ DZYQ+zhC/KyPaquRWiuPhw53QdrvSQWhlCVD/xFA=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Wl-62X2WxBgU; Tue, 20 Mar 2018 14:48:27 +0100 (CET)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Tue, 20 Mar 2018 14:48:26 +0100 (CET)
Received: by (Postfix, from userid 1000) id CED90366701; Tue, 20 Mar 2018 09:48:25 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 CED90366701
Received: from localhost (localhost []) by (Postfix) with ESMTP id C3F6040008A0; Tue, 20 Mar 2018 09:48:25 -0400 (EDT)
Date: Tue, 20 Mar 2018 09:48:25 -0400
From: Paul Wouters <>
To: Michael Casadevall <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <> <> <>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <>
Subject: Re: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Mar 2018 13:48:41 -0000

On Tue, 20 Mar 2018, Michael Casadevall wrote:

> Certificate Transparency works because specifically because the entire
> certificate is uploaded, and (assuming a valid cert) a SCT is generated
> which can be verified by cross-checking it against the log servers
> public key.
> Without the RRtypes logged, I'm not seeing how you're supposed to be
> able to audit them. In the case where a KSK is compromised, you could

Neither this nor certificate transparency protects against a (non-known)
private key compromise. In the case of CA's there are multiple entities
that can create a certificate that need to be audited. In DNSSEC, it is
only the zone or its parents that could create a rogue TLSA record.

> I'm likely missing something obvious, by only logging DS/NS, it would be
> impossible to determine if a private key is misused to serve fraudulent
> records which in my mind is a bigger and much more likely/common threat
> since one can simply attack a target domain and not try to compromise
> the root.

This is similar to the TLS server private key being compromised without
knowledge. That is not what is being protected.

> From a technical point of view, aren't there TLDs that as authoritative
> for second level domains as well? The specification likely needs a way
> to denote how many levels deep delegation can go. This also would be
> true in the case of delegation_only being used at a level above both the
> root and TLD zones.

In trying to keep this as simple as possible, the idea was to make this
concept as simple as possible. Making a promise about "every zone cut"
is much easier then making a promise to point to some more complicated
policy that might change over time, and then you have to log/audit the
changes to that policy as well.

For instance, you could have the DNSKEY flag mean "look for the
DELEGATE RRtype policy" and in there specify exceptions for your empty
non-terminals, but it just makes everything much harder.

> I know historically .name only allowed registration of third-level
> domains until 2009, and .uk up until 2014. I'm unsure if any of the TLDs
> still restrict and/or is authoritative for second-level domains as well.

If you run .example and have registrations in *.com.example and
*.edu.example, then the easy way is to create real zones for edu.example
and com.example.

> At a minimum though, the one case I know off hand of a TLD being
> authoritative for a second-level domain is that ICANN requires new gTLDs
> are required to publish a wildcard for 90 days when they're added to the
> root zone to help catch any name collisions.

If the software allows signing the wildcard and setting the
delegation-only flag that would mean the wildcard must be
treated as BOGUS, that would not be a problem. It would still
cause problems to be found with name collisions, except now the
name SERVFAILs instead of resolving to Both will show
the name collision as a problem.