Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind
Wes Hardaker <wjhns1@hardakers.net> Thu, 30 April 2020 21:41 UTC
Return-Path: <wjhns1@hardakers.net>
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 B0E8D3A143C; Thu, 30 Apr 2020 14:41:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 dfOHYfMe13bP; Thu, 30 Apr 2020 14:41:35 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3083A1402; Thu, 30 Apr 2020 14:41:27 -0700 (PDT)
Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 0F6F72C97E; Thu, 30 Apr 2020 14:41:27 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Joe Abley <jabley@hopcount.ca>
Cc: Tim Wicinski <tjw.ietf@gmail.com>, dnsop <dnsop@ietf.org>, dnsop-chairs <dnsop-chairs@ietf.org>
References: <CADyWQ+FLrTy0gy8iCyAPsDpiumDNQHX4TGPni43ThA=W3fmZew@mail.gmail.com> <EB400743-8B25-45DA-B4BD-5B27F47AE9E3@hopcount.ca>
Date: Thu, 30 Apr 2020 14:41:26 -0700
In-Reply-To: <EB400743-8B25-45DA-B4BD-5B27F47AE9E3@hopcount.ca> (Joe Abley's message of "Thu, 23 Apr 2020 21:37:17 -0400")
Message-ID: <ybl5zdg4po9.fsf@w7.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/0fSBfrl5UJeuNxytxI_zI7pC8uk>
Subject: Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 30 Apr 2020 21:41:48 -0000
Hi Joe, Sorry for the delay (Paul and I did a bit of back and forth with text changes that took a bit longer, but made it better!) > This draft needs a more compelling problem statement, and a clear description of why other controls > (e.g. reputational, contractual) are insufficient. [It's also possible that the draft just needs a > clearer problem statement, rather than a more compelling one.] I've just pushed the -04 version of the draft that has a fairly major overhaul of the problem statement. I'd appreciate if it helps clarify the technical reasons why deployment of the bit would be beneficial in ways that are unrelated to contractual type controls. I'll include the first three sections below, which are the parts that really changed. > Perhaps more substantially, but with more rapid oscillation of hands, > I am concerned that this draft, if adopted, will gain legitimacy in > policy circles where it might actually do damage. I can't speculate whether zones would be under increased market pressure for a DNS feature you clearly indicate might be desired. I find this statement that "this looks too helpful to some people; let's not do it" fascinating :-) More seriously, if a customer base wanted to ensure their parent promised never to sign lower data with their key, there is nothing stopping contractual wording around that from existing today. This draft merely offers a technical solution to prevent parents from *successfully* signing lower data and having it be accepted by validating resolvers. > An example might be where there is contractual or market pressure to > require it for TLDs where its effect might be to cause suppressed > orphan glue to break otherwise functional delegations. I'd love to see some registration point cases where this technique would cause harm. It is an all or nothing solution, so if a zone had 1M customers and 1 of them needed to be signed by the parental key, then they couldn't set this flag. That being said, if they're truly serving client data, it would be strange that they couldn't just create a new delegation to handle the issue. Here's the next for the newly wording sections 1 and 3, that describe the problem (2 was keywords): ---- 1. Introduction The DNS Security Extensions [DNSSEC] use public key cryptography to create an hierarchical trust base with the DNSSEC root public keys at the top, followed by Top Level domain (TLD) keys one level underneath. While the root and most TLD zones are asumed to be exclusively delegation-only zones, there is currently no interoperable and automatable mechanism for auditing these zones to ensure they behave as a delegation-only zone. This creates a target for malicious use of these zones - either by their owners or through coercion. This document defines a mechanism for delegation-only zone owners to create a DNSKEY that indicate they will only delegate the remainder of the DNS tree to lower-level zones. This allows for easier delegation policy verification and logging and auditing of DNS responses served by their infrastructure. Specifically, this document introduces a new DNSKEY flag allowing zone owners to commit to only signing records relating to delegation. If a DNSSEC validator discovers any non-delegation zone data signed by a flagged key, this data can be interpreted as BOGUS. 3. The Deep Signing problem The hierarchical model of DNS and DNSSEC ([RFC1034], [RFC1035], [RFC4033], [RFC4034] and [RFC4035]) comes with the property that a zone at one point in the hierarchy can define, and therefor override, everything below it in the DNS tree. And this is possible to achieve on a per-client basis. For example, the owner of the DNSSEC root key could generate a specially crafted zone file that ignores the intended NS records for ".org" and "example.org". It could place a AAAA record for "www.example.org" directly into the specially crafted zone, with a corresponding RRSIG signed by the root DNSKEY itself. Validating resolvers would find this record perfectly acceptable, as it was signed by a key within the proper chain of trust (in this case, a root DNSKEY). This specially crafted zone could then even be served to specific clients in an effort to subvert a portion of the DNS ecosystem for a portion of the Internet. Similarly, the TLD "example" could circumvent company.example for certain clients. It is important to note that this can be done without changing the upstream DS record or trust anchor -- the DNSKEY is (again) already in the trust path and is merely signing deeper DNS records than the zone owner's clients may have expected it to sign. It is important to note that this "feature" has always been present. Since the creation of the DNS, it has always been possible to serve "split zones". Specifically, it is not a problem created by DNSSEC -- DNSSEC was not designed to protect against this use case. Exposing such targeted attacks requires a transparency audit infrastructure similar to what is deployed for PKIX ([RFC6962]). However, a DNSSEC version would need to log significantly more data, as all signed DNS data used by a DNSKEY must be recorded in order to prove that data signed by a parent zone's DNSKEY was out of expected policy. The very distributed nature of the DNS combined with the typically frequent zone resigning rate makes such transparency logs prohibitively expensive and nearly impossible to operate. Additionally, it would require zone owners to expose all their zone data to any public log operators, thereby introducing privacy implications and exposing all relevant DNS data to a public archive. This may be acceptable for some domains, such as the root, where DNS data is already considered public. However, other delegation domains have legal implications that prohibit them from participating in such a system. Furthermore, there is no signaling mechanism that lets validating resolvers know which zones are supposedly delegation-only, and what zones can be logged. Today there are over 1500 TLDs in the root zone, some of which may be considered delegation-only while others may not be. At the time of this writing, the list of entries in the public suffix list contains over 8800 entries as well, with 73 wild- card entries (prefixed with a "*") indicating that all of their (unknown number of) children are public registration points. In the absence of an interoperable mechanism (like this draft provides), it is infeasible that a validating resolver or auditing log could know which of these zones are delegation-only without individual policy statements from each of them. [todo: xref psl] 3.1. Affected parties and their roles Upon deployment of this specification, the following parties would be potentially benefit or be affected by: Authoritative parent: If (and only if) an authoritative parent is a "delegation only" zone, it could generate a DNSKEY with the DELEGATION_ONLY flag set, indicating a verifiable promise to the world that will not sign any records other than delegation records. Authoritative Child / Delegated Zone: child zones existing underneath a marked delegation-only zone get the added benefit of knowing their parent will not (and cannot) sign DNS records within the child's portion of the DNS tree using the marked DNSKEY. Validating Resolver: A validating that supports verifying the DELEGATION_ONLY flag is capable of rejecting or discarding any data from an authoritative parent that incorrectly signs non-delegation records too low in the DNS tree. If the validating resolver supports a (future-defined) DNSSEC transparency audit log as well, it may submit the appropriate data to a DNSSEC transparency log that appropriately tracks DNSSEC signatures. DNSSEC Transparency Log (optional future): a DNSSEC transparency log would create a non-modifiable trace of log entries submitted to it, for public verification, similar to [RFC6962]. What it chooses to accept into its log might be only certain zone data, or any zone with a marked DNSKEY. Note that without a DNSSEC Log, the DELEGATION_ONLY flag is still useful per the discussion in the Validating Resolvers role: the resolver will reject incorrectly signed, non-delegation data. However, malicious parent zones are still capable of creating two (or more) DNSKEYs, one with the DELEGATION_ONLY flag and one without. However, they would also have to publish those DS records as well, which is detectable by DNSSEC monitoring platforms, regardless of the existence of a DNSSEC Transparency Log. Any zone with multiple DS records that link to both a DELEGATION_ONLY marked and an unmarked DNSKEY would be considered suspicious (or at least in transition). Circumventing this through obfuscation would require the collusion of their parent as well. Finally, a DELEGATION_ONLY flagged DNSKEY for the root zone cannot be overridden easily, as it would require a trust anchor update in all validating resolvers. -- Wes Hardaker USC/ISI
- [DNSOP] Call for Adoption: draft-pwouters-powerbi… Tim Wicinski
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… Dave Lawrence
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… Paul Wouters
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… Petr Špaček
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… Joe Abley
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… Wes Hardaker
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… Wes Hardaker
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… Joe Abley
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… Brian Dickson
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… Paul Wouters
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… John Levine
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… Wes Hardaker
- [DNSOP] Fun with draft-pwouters-powerbind John Levine
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… Daniel Migault
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… Tim Wicinski
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… Linus Nordberg
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… John Levine
- Re: [DNSOP] Fun with draft-pwouters-powerbind Viktor Dukhovni
- Re: [DNSOP] Fun with draft-pwouters-powerbind Paul Wouters
- Re: [DNSOP] Fun with draft-pwouters-powerbind Viktor Dukhovni
- Re: [DNSOP] Fun with draft-pwouters-powerbind Melinda Shore
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… Wes Hardaker
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… Wes Hardaker
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… Joe Abley
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… Wes Hardaker
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… Mark Andrews
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… Joe Abley
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… John Levine
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… Joe Abley
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… John R Levine
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… Joe Abley
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… Bob Harold
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… John R Levine
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… Wes Hardaker
- Re: [DNSOP] Call for Adoption: draft-pwouters-pow… Tim Wicinski