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

Michael Casadevall <> Wed, 21 March 2018 07:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8185C1201FA for <>; Wed, 21 Mar 2018 00:11:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gk9NBLwRFf-K for <>; Wed, 21 Mar 2018 00:11:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 007F7120454 for <>; Wed, 21 Mar 2018 00:11:02 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id BD2281F730; Wed, 21 Mar 2018 07:10:58 +0000 (UTC)
To: Paul Wouters <>
References: <> <> <> <> <> <> <> <>
From: Michael Casadevall <>
Message-ID: <>
Date: Wed, 21 Mar 2018 03:10:54 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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: Wed, 21 Mar 2018 07:11:04 -0000

Paul: Thanks for the explanation, it clears up a fair bit for me.
Replies inline.

On 03/20/2018 09:48 AM, Paul Wouters wrote:
> On Tue, 20 Mar 2018, Michael Casadevall wrote:
>> 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.

In my mind, the use case I was making was one of that of an intermediate
certificate being misused, but didn't quite make the mental leap to
equating that to the TLD/root zone. In that context, this proposal as
well as logging DS/NS changes makes considerably more sense to me than
it did before.

I still suspect there's value for full logging of all record types, but
that's a separate discussion.

>> 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.

See above.

>> 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 can appreciate simplicity in a specification. Obviously having a
hypothetical DELEGATE RRtype would considerable more work both in design
and actual implementation/validation. I'm just slightly concerned that
it might make real world deployment more difficult.

My point is here though is it might be a relatively simple extension to
say "I may delegate X levels down" vs. a rather complex system of
delegation/termination for cases where the TLDs disallow second level

I'm not qualified enough to say definitively if that's actually a
valuable enough case to be worth extending the specification, but I did
want to highlight it for consideration.

>> 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.

This likely should be noted as a operational consideration at a minimum
as it impacts how Name Collision tracking is done.

Thanks for your time,