|
Only two years after signing the DNS root zone, the powerful lure of a secure global infrastructure for data distribution is starting to reveal itself. It is illustrated clearly by two proposed technical standardizations that seek to leverage secure DNS. To some degree these developments highlight the strength of DNS institutions and how they might fill gaps elsewhere in the Internet’s governance. But an increasing reliance upon and concentration of power in the DNS also makes getting its global governance correct even more important.
The first, more widely known, development is the IETF’s ongoing DANE effort. The DANE standard proposes to improve the Transport Level Security (TLS) protocol, which is used worldwide to secure communication between applications (e.g., a browser) and host machines (e.g., a website server). DANE enables administrators of domain names to specify TLS cryptographic key material in a resource record stored in a zone file. Using DNSSEC, an application could validate the resource record with the practical result that communication between an application and host machine is probably more secure—a good thing.
Perhaps the most interesting aspect of DANE is that it takes TLS key distribution out of the hands of the browser/certificate authorities and places it with DNS operators. The browser/certificate authority regime has been shown to be susceptible to attack and lacking in clear lines of accountability. In theory, if an administrator puts signed key material in the DNS, an application can validate it starting from the single trust anchor maintained by ICANN. Like DNSSEC, DANE depends on registrars, registries and Internet service providers not tampering with signed data provided by administrators. Pressure to tamper with data could come from numerous sources, e.g., interests in intellectual property protection, advertising, surveillance, etc. At the end of the day, it will be the DNS contractual regime, the laws that govern the involved parties, and the extent to which those institutions are transnationally interoperable that determines how DANE contributes to various global public policy goals like free expression and free trade in information services. Expect the differences between governments, and their response to domestic pressures, to challenge that interoperability.
The second, and in our opinion, more interesting development is the more recently proposed ROVER (Route Origin Verification) effort which seeks to address the problem of misconfigured routing announcements, whether accidental or intentional. Similar to DANE, ROVER proposes to improve the inter-domain routing by creating new resource records published in the secure reverse DNS (i.e., the in-addr.arpa zone). Similar ideas have been proposed previously, but never took hold. The records would allow network operators to indicate whether an IPv4 or IPv6 prefix ought to appear in global routing tables and identify authorized origin Autonomous System Number(s) for that prefix. This is the same data (i.e., Route Origin Announcements) which appears in the Resource Public Key Infrastructure (RPKI) being managed by some RIRs. ROVER would facilitate the comparison of validated records stored in the secure reverse DNS against route announcements being made on the Internet. Discrepancies could be flagged and lead to further action taken by the operator.
Again, the most interesting aspect is the interplay between technology and institutional power. The technical community has been debating the merits of Secure DNS vs. RPKI. The debate occurs in the shadow of the major, ongoing concern for network operators concerning RPKI, i.e., how it could allow certificate authorities (e.g., the RIRs) to impact routing. This concern is further complicated with Border Gateway Protocol Security (BGPSEC), which proposes incorporating cryptographic signing and validation of route announcements directly into the BGP. As an alternative, ROVER suggests leveraging the certified resource allocation data stored in the RPKI (or elsewhere) to create and validate route announcements in the secure reverse DNS. But it allows operators to independently apply that data to routing decisions. If a certificate authority revoked a certificate it would not impact routing unless the operator allowed it to. Less appreciated, however, is that ROVER potentially shifts route announcement data, typically stored in the decentralized Internet Routing Registries (IRRs) now, into the hierarchical secure DNS. Given this, the operation and governance of a few zones, namely .arpa and in-addr.arpa, becomes critical. Those zones are currently managed by ICANN. Its use for routing purposes may raise contention that too much power is centralized with this organization. In theory, as manager of the in-addr zone, ICANN could regulate network operators via contract, similar to the way it does some TLD operators. This will need to be examined more closely.
Sponsored byDNIB.com
Sponsored byIPv4.Global
Sponsored byVerisign
Sponsored byWhoisXML API
Sponsored byCSC
Sponsored byRadix
Sponsored byVerisign
Very interesting article. I’m not an engineer, so hope you’ll indulge me with some clarifications.
So could ROVER prevent route hijacks, even if BGP is not made secure? Same question in reverse - if BGPSEC is implemented, would ROVER be necessary?
I would have chosen a different title for this post. If the history of DNS shows anything, it’s that just building something will not change established behaviors without a lot of time and effort.
Look at how long DNSSEC languished, because there was no compelling business model to offset implementation costs. I’d bet registrars would say there still isn’t one.