ICANN ICANN Email List Archives

[dns-cert-proposal]


<<< Chronological Index >>>    <<< Thread Index >>>

ICANN Global DNS-CERT Business Case: Improving the Security, Stability and Resiliency of the DNS - 12 Feb.

  • To: dns-cert-proposal@xxxxxxxxx
  • Subject: ICANN Global DNS-CERT Business Case: Improving the Security, Stability and Resiliency of the DNS - 12 Feb.
  • From: Dave Smiley <elimsad@xxxxxxxxxxx>
  • Date: Mon, 5 Apr 2010 21:24:07 +0000 (GMT)

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.

2.6.1.2 – 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.

2.6.1.3 – “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.

2.6.2.1 – solved by DNSSEC.  ..and little in the way of real exploits doing 
this.

2.6.2.2 – “..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.

2.6.3.2 – 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.  

2.6.4.2 – 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.  
3.2.1.1 – 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.
 
3.2.3.1 – 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.
 



      



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy