Re: [DNSOP] Call for Adoption: draft-pwouters-powerbind

[Wes Hardaker <[e-mail]>]

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