<<<
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
>>>
|