I was talking to my good friend Verner Entwhistle the other day when he suddenly turned to me and said "I don't think we need DNSSEC". Sharp intake of breath. Transpired after a long and involved discussion his case boiled down to four points: 1. SSL provides known and trusted security, DNSSEC is superfluous, 2. DNSSEC is complex and potentially prone to errors, 3. DNSSEC makes DoS attacks worse, 4. DNSSEC does not solve the last mile problem. Let's take them one at a time...
DNS rebinding attacks are real and can be carried out in the real world. They can penetrate through browsers, Java, Flash, Adobe and can have serious implications for Web 2.0-type applications that pack more code and action onto the client. Such an attack can convert browsers into open network proxies and get around firewalls to access internal documents and services. It requires less than $100 to temporarily hijack 100,000 IP addresses for sending spam and defrauding pay-per-click advertisers. Everyone is at risk and relying on network firewalls is simply not enough. In a paper released by Stanford Security Lab, "Protecting Browsers from DNS Rebinding Attacks," authors Collin Jackson, Adam Barth, Andrew Bortz, Weidong Shao, and Dan Boneh provide ample detail about the nature of this attack as well as strong defenses that can be put in place in order to help protect modern browsers.
ICANN has embarked on the IDN boat at the same time it wants to introduce DNSSEC and new gTLDs. This promises lots of fun. Or grey hair, depending how you look at it. First is the issue of country code IDNs. The ISO-3166 table, based on two letter codes, is a western convention. Some cultures do not use abbreviations or acronyms. Some do not use a character-based alphabet, but a syllabic one. Hence, the next logical step would be to represent the full country name in local script, rather than a transliteration of the ISO string... Imagine the case of India, where there are 1.652 languages, of which 24 are spoken by more than one million people...
One of my staff members pointed me to an article by Mikko Hyppönen in Foreign Policy. In this article Mikko argues that a new top level domain (TLD) like .bank for some reason would prevent on-line fraud, at least partially. Mikko seems to be arguing that with a dedicated TLD registry for financial institutions and a fee high enough to act as an entry barrier you would have a trustworthy bank domains that would be immune against today's phising attempts...
A revolution is taking place on the Internet, with new sites redefining how we interact online. The next-generation Internet is emerging in collaborative and interactive applications and sites with rich, varied media (images, video, music). As with many revolutions, this one is driven by the younger generation, which is adopting social networking sites like MySpace and video sharing sites like Google's YouTube. But the general shift is not restricted to the young, as more mature consumers and businesses alike are exploring the possibilities of collaborative, media-rich applications. This major shift in Internet applications has its unintended victims. One of them turns out to be the Domain Name System (DNS).
Seems that DNSSEC is being subjected to what an old boss of mine used to call the "fatal flaw seeking missiles" which try to explain the technical reasons that DNSSEC is not being implemented. First it was zone walking, then the complexity of Proof of Non-Existence (PNE), next week ... one shudders to think. While there is still some modest technical work outstanding on DNSSEC, NSEC3 and the mechanics of key rollover being examples, that work, of itself, does not explain the stunning lack of implementation or aggressive planning being undertaken within the DNS community.
One topic does not appear to have a compellingly obvious localization solution in the multi-lingual world, and that is the Domain Name System (DNS). The subtle difference here is that the DNS is the glue that binds all users' language symbols together, and performing localized adaptations to suit local language use needs is not enough. What we need is a means to allow all of these language symbols to be used within the same system, or "internationalization".
Last month, there was an exchange of letters between a gTLD administration and ICANN about DNSSEC deployment. This gTLD administration is PIR or Public Interest Registry, the gTLD administration for the .org TLD. Interestingly, PIR is a non-profit organization that makes significant contributions to ISOC (Internet Society) initiatives: thus, both ICANN and PIR are organizations dedicated to the well-being of the Internet.
In looking at the general topic of trust and the Internet, one of the more critical parts of the Internet's infrastructure that appears to be a central anchor point of trust is that of the Domain Name Service, or DNS. The mapping of "named" service points to the protocol-level address is a function that every Internet user relies upon, one way or another. The ability to corrupt the operation of the DNS is one of the more effective ways of corrupting the integrity of Internet-based applications and services. If an attacker can in some fashion alter the DNS response then a large set of attack vectors are exposed. ...The more useful question is whether it is possible to strengthen the DNS. The DNS is a query -- response application, and the critical question in terms of strengthening its function is whether it is possible to authenticate the answers provided by the DNS. DNSSEC provides an answer to this question.
The DNSSEC is a security protocol for providing cryptographic assurance (i.e. using the public key cryptography digital signature technology) to the data retrieved from the DNS distributed database (RFC4033). DNSSEC deployment at the root is said to be subject to politics, but there is seldom detailed discussion about this "DNS root signing" politics. Actually, DNSSEC deployment requires more than signing the DNS root zone data; it also involves secure delegations from the root to the TLDs, and DNSSEC deployment by TLD administrations (I omit other participants involvement as my focus is policy around the DNS root). There is a dose of naivety in the idea of detailing the political aspects of the DNS root, but I volunteer! My perspective is an interested observer.