Our last post explained the basics of how DNSSEC works. A security-aware resolver's ability to validate nameserver responses is accomplished by establishing an authentication chain from a known trust anchor(s) (i.e., a DNSKEY or signed DS record) to the zone which has provided the signed response. If a resolver is configured with a trust anchor(s) that exists higher in the DNS tree, e.g., the root's public key[1], it can theoretically verify any signed responses. This is because a path can always be constructed from the root to lower zones, assuming every zone in the path is signed and carries a Delegation Signer (DS) Resource Record for child zones. This architectural design highlights the critical importance of parent nameservers maintaining DS records and of signing those records to widespread deployment of DNSSEC across the Internet.
However, what happens in a scenario if portions of the DNS tree, and particularly the root, is not signed? A broken authentication hierarchy, where a parent zone does not support DNSSEC, creates the “islands of trust” problem. For instance, the .se zone (which launched commercial service recently) is signed yet it's parent is not. It is isolated from the rest of the DNS tree, an island. Therefore, the .se registry must provide a trust anchor to security aware resolvers and be responsible for the associated key management tasks (e.g., distribution, rollover to new key, etc.). Another example might be USG agencies, where implementation of DNSSEC is being driven by the need to be compliant with Federal Information Security Management Act driven standards. It is possible to deploy DNSSEC in zones the USG is responsible for (e.g., .gov, .mil) without securing the root. Another option[2] for dealing with the absence of signed DS records in the root is DNSSEC Look-aside Validation (DLV).[3] Originally put forth as an interim solution until the root was signed, DLV bypasses the normal DNS hierarchy and proposes one or more third parties maintain a registry of validated entry points to secure zones, thereby relieving the need to sign the root. In theory, the introduction of multiple DLV registries could be beneficial from a market competition standpoint.
Since DNSSEC allows for resolvers to store and use multiple trust anchors, incremental deployment using either of the scenarios above is possible. But while these alternatives remove the difficult political hurdles associated with signing the root zone file, it also changes who absorbs the deployment and ongoing costs of DNSSEC. Trust anchor management (and security policy decisions) would move away from ICANN and the root zone maintainer (currently VeriSign). E.g., the current DLV specification suggests that IANA assume this role. However, any new organization would still have to deal with the same operational questions and expense, namely key management and liability surrounding holding such a critical position in an authentication hierarchy. Perhaps more importantly, such an approach potentially eliminates efficiencies gained by maintaining a single or relatively few trust anchors for the secure DNS. Having numerous trust anchors would increase the burden of security policy evaluation and key updating for resolver operators (i.e., to ISPs running caching resolvers, and perhaps ultimately, to security-aware stub resolvers used by end-user applications). Arguably, it presents a situation that is simply not scalable across the entire Internet.
So what are we left with? The DNSSEC specification is based on a hierarchical model of trust, and ideally that means the root is signed, with an organization(s) overseeing the critical DS records and providing trust anchor(s) for security aware resolvers to use to validate them. Our next post will outline a new system for the management of a DNSSEC-enabled root. One that distributes authority more than the current method while avoiding the risks and pitfalls of an intergovernmental power sharing scheme.
[1] To be precise, the key mentioned above is actually the “key signing key” (KSK) for the root zone. In fact, in most cases each zone will manage two types of key-pairs, KSKs and zone signing keys (ZSKs). The ZSK key-pair is used to sign a particular zone's record sets and will be used frequently by resolvers in queries, while the KSK key-pair is used less frequently because it is used only to sign and authenticate a zone's ZSK.
[2] This is not exhaustive list of alternatives dealing with an unsigned root. Other non-hierarchical solutions have been suggested. E.g., one proposes out of band “web-of-trust” trust anchor distribution, another suggests islands cross-sign KSKs. Furthermore, it does not include trust anchor update alternatives the Working Group has considered, e.g. trustupdate-threshold, trustupdate-timers, and TAKREM.
[3] One implementation is currently run by ISC, makers of the market dominant BIND name serving software.
ISC just released the first version of it's security policies for the DLV implementation it runs. It's available at https://secure.isc.org/index.pl?/ops/dlv/dlv-pol-pract-v1.0.php
In summary, Brenden explains the two approaches to cope with a sparse DNSSEC deployment in the zone hierarchy, the manual configuration and DLV, and concludes, rightly, that root signature is the way to go.
This last Friday, I brought up two contributions to address these two issues. I should resist my personal modesty and say “significant contributions.” Actually, it's the synergy between the two that I find promising.
By the phrase “DNS root nameserver substitution for DNSSEC purposes,” I try to legitimize an alternate root operation in which the IANA root zone file contents is not put into question, except that DNSSEC support at the root is introduced.
The first contribution (http://www.ietf.org/internet-drafts/draft-moreau-srvloc-dnssec-priming-00.txt) applies SLP, the Service Location Protocol (RFC2680) to facilitates the DNS resolver configuration within an SLP administrative domain (not to be confused with a DNS domain), that is, a scope in the universe of DNS *resolving* entities, e.g. a multinational corporation, a government, a campus, or perhaps a consortium of ISPs.
This can be done in a two-tiered arrangement, where a first tier does the DNSSEC signature and key management, and a second tier operates the substitute nameservers. A smaller number of operators in the first tier than in the second tier. The first tier deals primarily with cryptographic key management, the second tier runs root nameservers on the public Internet. The first tier may spawn many SLP administrative domains., the second tier may be more focused.
So, a clever deployment of SLP deploys a signed DNS root! Without waiting for ICANN. Without a single alternate root facing the global Internet scaling issue. So far, so good.
The second contribution (http://www.connotech.com/optin_for_dnssec.pdf) is an opt-in scheme for direct delegation, say from the signed root zone to a signed example.com zone. In contrast with the DLV scheme, this new form of delegation does not require any on-line nameservers, just a few additional DNSKEY and signature entries in two signed zones.
The R&D department at Verisign contributed to the latest addition to the DNSSEC protocol suite, known as NSEC3, notably to promote an “NSEC3 opt-out” provision in the protocol. The huge size and growth of the .com zone might have been a show stopper for DNSSEC without NSEC3 opt-out. My opt-in proposal altogether circumvents a lack of DNSSEC support in large TLDs.
Sounds magic? Well, there is a limitation, and deployment does not come without pain simply because the community does not have to wait for ICANN and large TLDs.
. The limitation is a known loophole in the DNSSEC security services: the opt-in proposal has a similar caveat as NSEC3 opt-out with respect to the DNSSEC security service called “authenticated denial of existence” – the attractiveness of the original DNSSEC deployment scenario is intact.
. The provisioning of opt-in delegations is comparable to the provisioning of secure delegation from a secure parent zone. No free lunch here.
. Circumventing large TLDs requires a signed zone, so the SLP deployment remains in the todo list.
ICANN has a monopoly for TLD registrations. Verisign has a dominant market position, if not a monopoly, as the .com registry. It is perhaps a good thing that initial registration of SLD (second-level-domains like example.com) in the DNSSEC service be done by a service entity enjoying the artificial monopoly created by may patent application. The whole thing is about reaching a critical mass; initial market fragmentation would be counterproductive.
For those who ideologically oppose patents, I refer to the conclusion of a committee chaired by late Georges Washington. Unfortunately, the comment period for this committee is closed, see http://www.archives.gov/national-archives-experience/charters/constitution_transcript.html#1.8.8. Actually the US constitutional basis for the patent system had a significant impact on the current international intellectual property regime; we just live with it.
The status of each contribution is self-explained from the respective documents. I think it is too early to tell how either one, or their synergy, may withstand review and critique, and in which form they may move forward.