[dssa] what topics are in-scope, and why

[Greg Aaron <gaaron@xxxxxxxxxxxx>]

Dear group:



We have a large list of problems/threats on the mind map.  Our Charter
provides some guidance that can help us decide which topics are and are not
relevant, or how.  We must have a common grasp of the differences, and be
able to articulate it outside the WG.



Our Charter says the WG is to work on: "The actual level, frequency and
severity of threats to the DNS....  The DSSA‐WG should limit its activities
to considering issues at the root and top level domains within the framework
of ICANN’s coordinating role in managing Internet naming and numbering
resources as stated in its Mission and in its Bylaws." [Italics mine.]



In other words:  we are not to look at every threat having to do with or
talking place via the DNS, or that impacts some party using the DNS.   We
are concerned with “the” DNS, i.e. threats to the system itself, and
relevant to ICANN’s role.



The GNSO’s Registration Abuse Policy Working Group (RAPWG, which Mikey and I
served on)  spent time exploring related scope issues.  Pages 20-24 and
50-54 of its report are of interest:
http://gnso.icann.org/issues/rap/rap-wg-final-report-29may10-en.pdf

I suggest that the following kinds of topics do not qualify.  They are not
issues at the root and top level domains within the framework of ICANN’s
coordinating role.  Instead they are issues that affect individual
second-or-third-level domain names, affect parties that are not critical to
root or TLD operations,  do not threaten widespread DNS disruptions or
subversions, etc.

•             domain hijacking

•             cybersquatting

•             phishing, spam, malware, and other malicious uses of domain
names.  (See the RAPWG report.)

•             IDN homographic attacks (this is phishing)

•             Operating system vulnerabilities in general

•             registrar service disruption (may affect many domains or
hardly any depending upon which registrar it is.  gTLD registrars don’t have
availability/uptime SLAs like registries do. If registrar downtime was a
threat to the DNS, then registrars would presumably have SLAs.  Instead,
registrars have escrow requirements, in case of failure or contract
breach/deaccreditation.)

•             protocol layers below the DNS



These kinds of problems seem relevant to me, among others:

•             flaws in the DNS protocol itself (e.g. the Kaminsky bug)

•             Alternate roots

•             Synthetic returns and TLD wildcarding: issues of universal
resolvability, subversion of DNSSEC

•             Root server vulnerabilities



The relevance of a threat depends on the target and impact.   A DDoS of
Amazon is not a topic for our WG, but DDoS attacks against root servers
are.  A successful DDoS attack against a small TLD would not be noticed by
most of the Internet, but a successful DDoS against the .COM/.NET registry
would be very impactful.   The “business and system failures” of a Bharti or
Comcast are not really fodder for us, but the business or system failure of
a root server operator or TLD operator seems relevant.   Vulnerabilities in
operating systems might be relevant in that it’s good practice for root and
TLD server operators to have diversity and reduce vulnerability to hacking
and bugs.   Similarly, criteria like “hardware” and “expertise” mean nothing
unless we’re saying how they are a relevant problem at a relevant place.



Thanks.  Hope this was helpful for provoking some further discussion.



All best,

--Greg







**********************************

Greg Aaron

Domain Security

Afilias

vox: +1.215.858.2257

gaaron@xxxxxxxxxxxx

**********************************

The information contained in this message may be privileged and confidential
and protected from disclosure. If the reader of this message is not the
intended recipient, or an employee or agent responsible for delivering this
message to the intended recipient, you are hereby notified that any
dissemination, distribution or copying of this communication is strictly
prohibited. If you have received this communication in error, please notify
us immediately by replying to the message and deleting it from your
computer.