Re: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)
Paul Wouters <paul@nohats.ca> Tue, 20 March 2018 13:48 UTC
Return-Path: <paul@nohats.ca>
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 23A3D1275F4 for <dnsop@ietfa.amsl.com>; Tue, 20 Mar 2018 06:48:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 ROAjvOtPuEPd for <dnsop@ietfa.amsl.com>; Tue, 20 Mar 2018 06:48:39 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D469D124B17 for <dnsop@ietf.org>; Tue, 20 Mar 2018 06:48:38 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 405DmL6W01z3Hj; Tue, 20 Mar 2018 14:48:34 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; 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 mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Wl-62X2WxBgU; Tue, 20 Mar 2018 14:48:27 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 20 Mar 2018 14:48:26 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id CED90366701; Tue, 20 Mar 2018 09:48:25 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca CED90366701
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (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 <paul@nohats.ca>
To: Michael Casadevall <michael@casadevall.pro>
cc: dnsop@ietf.org
In-Reply-To: <558f80ca-be06-1cdd-4406-14b5797cdb26@casadevall.pro>
Message-ID: <alpine.LRH.2.21.1803200933160.30728@bofh.nohats.ca>
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>
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: <https://mailarchive.ietf.org/arch/msg/dnsop/kkxjFpIWCX3jQyQ6o5v48SR_nbY>
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: 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 127.0.0.53. Both will show the name collision as a problem. Paul
- [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