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 mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
