ICANN Global DNS-CERT Business Case: Improving the Security, Stability and Resiliency of the DNS - 12 Feb.
Thank you for the opportunity to comment on this effort. I hope you find the following comments constructive in your overall SSR efforts. Although I understand your desire to fill-in some of the gaps, perceived or otherwise, in improving responsiveness to DNS issues, the insertion of another entity and magnitude of your approach introduces inefficiencies at best and may politically hamper at worst. The Internet would be better served (with greater efficiently and without political ramifications) by simply improving DNS awareness of the various existing organizations with their established constituency relationships. In this way, constituencies can optimize the use of their limited resources to communicate through existing, already necessary, communications channels with CERTS or whatever. For example, encouraging an organization like OARC to improve upon their coordination and dissemination efforts amongst the experts who design, build, study, and maintain the DNS – and who continue to demonstrate a responsiveness to problems that no centralized system could match – would be a reasonable approach. It is this unique, distributed, a-political, already well connected cadre of DNS researchers and experts that have kept the DNS a reliable component of the internet’s infrastructure for over 25 years with a demonstrated track record of quickly solving DNS issues. With the rollout of DNSSEC, potential attacks will be further reduced further putting into question the need to create another entity. What follows are my section by section comments: Page 2 para 2 “Several external bodies…” – Who? Para 3 “…staff to orchestrate…” - Unnecessary. The last thing we need is more mid-level management. You’ve just inserted another layer. It didn’t work for the intelligence agencies for your own government and will not work here. This goes directly against the distributed nature of the Internet and smacks of a command and control structure that we have fought with so many other regimes against and stifles innovation. “…explicitly avoid duplication” - you say this but…why not have the effort in the CERTs? Why not fix them instead of increasing the complexity and exponentially increasing the inter-communications links? This smacks of ICANN relevance seeking. This is the natural progression of any organization and ICANN shouldn’t be blamed for this but the public should at least be given the truth to decide. There should also be clearly defined metrics to decommission the creation of any such entity should its control exceed its mandate and/or its value be found questionable. Particularly in the face of deployments such as DNSSEC, the day may soon come that the DNS just works as a minor, well operating, part of the internet infrastructure. Does not DNSSEC reduce the need for DNS-CERT? The DNS should just work. It does not need yet another organization to babysit it. If it does, it needs to be further fortified. This also goes against the decentralized nature of what makes the Internet an engine for ecommerce and democracy. Having another centralized agency that information need be reported to only slows down the fast response time to corrections the current system has demonstrated and has in place. Such centralization may also tempt US and other governments to gate/control or at least meddle in the private sector operated critical infrastructure. 1.2.1 bullet 1 – Is this not what the CERTs do? 2 – this is pretty well done already. Just see how quickly DNS problems get resolved – often without the public even noticing!! 3 - might have some value here. 1.2.2 – “…to its constituency” how would the DNS-CERT constituency be different from the CERT constituency? How large is this “constituency”? “..be fusing” – is this not OARC? “..evaluated by its stakeholders” – who exactly are these stakeholders. How can you guarantee these stakeholders will not be drawn from the small incestuous community that follows this particular element of the internet infrastructure. 1.2.3 – “…virtual response team” - is this not there already? Response time is exemplary now. As said above – many problems get solved before the public even sees them. …and yes…already coordinated across time zones. 1.3.1 – the motivations and logic here is not clear. 2.1.1 – “…widespread persistent failure” - where has this happened? Some examples would be instructive. Deployment of DNSSEC to the end nodes will protect much of this. 2.1.3 “..no single coordination point among the diverse…” - That is THE desirable feature!! ..unless the DNS-CERT effort is being driven by governments. Are you? 2.2.1 – CERT/CC is an excellent example of why we do not need to create another entity. 2.2.2 – “…the respective constituencies…” as part of the existing ecosystem. 2.2.3 – “..a CERT” might be better said as “the CERTs” 2.4.1 – “no central point” – there is. The CERTs. Again – putting all your trust in a single entity defeats the saving trait that the Internet is modeled after – decentralized control. There are already multiple central technical and coordination points (as email list, contact lists, venues, etc) that would already respond to such attacks. The distributed nature of the DNS makes it difficult for your hypothetical “wide-scale coordinated attack” to sustain significant damage. It would be instructive and helpful to understand what the attacks you have in mind are and how current and upcoming technologies will not address these attacks. Para 3 – Unfortunately I cannot agree with the italicized text as it is the result of an ICANN sponsored INVITATION ONLY meeting (the Symposium) supporting and ICANN sought goal. This doesn’t wash. Nice try though. I believe what we have now is sufficient. Lets not make DNS a mountain out of a molehill. Para 5 – “Certs worldwide …” – we should help the existing CERTS build DNS capabilities, not create another. 2.4.2 – How is your premise that an attack on DNS “could” result in significant and lasting economic consequences supported by “2009 Info Tech Sector Risk Assessment” ? A full reference to this document would be nice. The responders do NOT lack situational awareness. IN fact, they have demonstrated an excellent ability to respond as shown by the fact that the DNS has survived so well and that mitigation to attacks that have not even been widespread have been addressed and are being addressed before they even occur (cache poisoning). 2.5.3 – again by referring to the Symposium, you are referring to yourself and your own conclusions. This carries no weight. Organizations should start with contacting existing CERTs. Forcing organization to create additional links to another group for DNS problems only dilutes their already limited resources. 2.5.4 – “…leverage many existing efforts…” this is tired language in an attempt to insert another layer of indirection into an existing system that could simply be improved upon if needed. Same language as similar efforts such as IMPACT that only exist to empower superfluous intermediary organizations. ICANN should avoid becoming like the ITU. 184.108.40.206 – DNS was only a small part. The user and operating system as usual were the key reason for such infections. DNS did what it was supposed to do. Such unprecedented policing of the DNS should be discouraged and only a means of last resort. In the end, this coordination effort went pretty well without DNS-CERT. ...and even after high levels of awareness were attained, nothing happened and essentially was a situation of crying wolf as the FUD behind DNS-CERT might be. 220.127.116.11 – “would have enhanced the global response to this issue..” Not sure how much more than what was done was needed. Full press, reasonable cooperation, and yet no impact. 18.104.22.168 – solved by DNSSEC. ..and little in the way of real exploits doing this. 22.214.171.124 – “..it might have been”. It wasn’t because of the inter-organizational networks that are already in place. “..response coordination capability by a know trusted entity” – ICANN is not trusted by all. This again defeats the gains the distributed quality of the Internet has brought us by centralizing information control and soft power. A better approach is to better disseminate information to the various existing entities that each constituency already trusts. Assisting the CERTs via bodies like OARC, for example, would be much more effective while still retaining the distributed nature of the Internet. 2.6.3 – This is an odd example to point to as these attacks were based on social engineering and not any lack of DNS operational capabilities. You seem to be making a bigger deal of what I understood to be misplaced trust in bad actors that it was. This was made clear to the TLD owners and corrected without the need of any centralized authority and lessons appropriately learned. 126.96.36.199 – Market forces and other incentives form the strongest control in these instances. The threats here were due to poor business processes and lack of motivation to stay on top of such processes – NOT a lack of information. In any case organizations like OARC already serve, or with slight help can serve, as such information sharing clearinghouses for DNS. 2.6.4 – DNS was only a tangential component of this attack. Like most botnets, Zeus exploited operating system vulnerabilities. Again only a social problem involving bad behavior by a few registrars. This falls into existing registry compliance operations and maybe a revisit to the demarcation between registry-registrar responsibilities. There is no need to duplicate work here. 188.8.131.52 – As you point out, such small registrars are already overloaded. Such registrars would benefit more from registrar policy changes than from more information which they may have no incentive to seek. 184.108.40.206 – DNS is one of the areas where such situational awareness already exists. Issues on in the DNS are discovered immediately as demonstrated by the reliability of the DNS over the decades. It may benefit from slightly greater dissemination which can easily be implemented over existing relationships and mechanisms – NOT the creation of a whole new centralized entity that would tax the limited resources of organizations further. It is not clear what problem is trying to be solved with DNS-CERT. 220.127.116.11 – DNS issues should be better incorporated into the broader cyber community, and existing organizations such as OARC are already in place to do so via existing CERTs and other amplification avenues. DNS is a mature ecosystem with plentiful talent, experience and capacity that have a demonstrated track record of responding to and mitigating the effects of attacks. All that needs to be done is to expand those existing relationships to other parts of the IT ecosystem. Additional resources to OARC to repackage and add a “face” to that organization would address most of these problems - in an organization not encumbered by its governmental ties and pseudo-regulatory position.