Re: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)
Michael Casadevall <michael@casadevall.pro> Wed, 21 March 2018 07:11 UTC
Return-Path: <michael@casadevall.pro>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8185C1201FA for <dnsop@ietfa.amsl.com>; Wed, 21 Mar 2018 00:11:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gk9NBLwRFf-K for <dnsop@ietfa.amsl.com>; Wed, 21 Mar 2018 00:11:03 -0700 (PDT)
Received: from casadevall.pro (casadevall.pro [45.33.112.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 007F7120454 for <dnsop@ietf.org>; Wed, 21 Mar 2018 00:11:02 -0700 (PDT)
Received: from [192.168.2.2] (cpe-68-174-119-246.nyc.res.rr.com [68.174.119.246]) by casadevall.pro (Postfix) with ESMTPSA id BD2281F730; Wed, 21 Mar 2018 07:10:58 +0000 (UTC)
To: Paul Wouters <paul@nohats.ca>
Cc: dnsop@ietf.org
References: <alpine.LRH.2.21.1803190813150.31565@bofh.nohats.ca> <20180319163434.GA25738@laperouse.bortzmeyer.org> <CA+nkc8CWtXOiXCVQf4iyJwBS1K4seLxsJmtZyRyz7yuCn+u8hQ@mail.gmail.com> <20180319194945.GG3322@mournblade.imrryr.org> <20180320112653.GA10054@laperouse.bortzmeyer.org> <alpine.LRH.2.21.1803200740520.29013@bofh.nohats.ca> <558f80ca-be06-1cdd-4406-14b5797cdb26@casadevall.pro> <alpine.LRH.2.21.1803200933160.30728@bofh.nohats.ca>
From: Michael Casadevall <michael@casadevall.pro>
Message-ID: <37700659-9332-37a2-4076-6301f87e0eec@casadevall.pro>
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: <alpine.LRH.2.21.1803200933160.30728@bofh.nohats.ca>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/IFFcbnzuKh_xaL4hL_sGdpOntmM>
Subject: Re: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=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 registration. 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 127.0.0.53. 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, Michael
- [DNSOP] New Version Notification for draft-pwoute… Paul Wouters
- Re: [DNSOP] New Version Notification for draft-pw… Stephane Bortzmeyer
- Re: [DNSOP] New Version Notification for draft-pw… Bob Harold
- Re: [DNSOP] New Version Notification for draft-pw… Viktor Dukhovni
- Re: [DNSOP] New Version Notification for draft-pw… Robert Edmonds
- Re: [DNSOP] New Version Notification for draft-pw… Paul Wouters
- Re: [DNSOP] New Version Notification for draft-pw… Paul Wouters
- Re: [DNSOP] New Version Notification for draft-pw… Robert Edmonds
- Re: [DNSOP] New Version Notification for draft-pw… Stephane Bortzmeyer
- Re: [DNSOP] New Version Notification for draft-pw… Paul Wouters
- Re: [DNSOP] New Version Notification for draft-pw… Michael Casadevall
- Re: [DNSOP] New Version Notification for draft-pw… Paul Wouters
- Re: [DNSOP] New Version Notification for draft-pw… Michael Casadevall