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

Michael Casadevall <michael@casadevall.pro> Tue, 20 March 2018 13:19 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 A2330127419 for <dnsop@ietfa.amsl.com>; Tue, 20 Mar 2018 06:19:14 -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 WbDfEL7_fajz for <dnsop@ietfa.amsl.com>; Tue, 20 Mar 2018 06:19:13 -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 0BDF71270AE for <dnsop@ietf.org>; Tue, 20 Mar 2018 06:19:12 -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 193801F730 for <dnsop@ietf.org>; Tue, 20 Mar 2018 13:19:11 +0000 (UTC)
To: 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>
From: Michael Casadevall <michael@casadevall.pro>
Message-ID: <558f80ca-be06-1cdd-4406-14b5797cdb26@casadevall.pro>
Date: Tue, 20 Mar 2018 09:19:06 -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.1803200740520.29013@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/noOILG_G9r01PfT1BCwqYlogJFo>
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:19:15 -0000


On 03/20/2018 07:44 AM, Paul Wouters wrote:
> The goal of the document is to make such malicious changes visible.
> 
> If the parent needs to replace NS/DS records, these are easily
> auditable identically to Certificate Transparency (rfc 6962bis)
> We only need to look (log) the DS/DNSKEY and we do not have
> to monitor all TLSA and other security RRtypes. Without this flag,
> we need to track and log every DNS RRtype that has public key material
> in it.
> 

Forgive my ignorance on the subject, but I'm having trouble following
how delegation_only flag actually helps in this specific case.

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
simply sign a new zone record, serve up fraudulent records and remain
unaware. CT as it's implemented in the x509 world (combined with
Expect-CT) specifically prevents unknown but validly signed certificates
from being used.

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.

Moving to the topic of the draft itself:

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

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.

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.

Michael