<<<
Chronological Index
>>> <<<
Thread Index
>>>
gTLD Draft Applicant Guidebook - Evaluation Questions and Criteria - Module 2
- To: <2gtld-evaluation@xxxxxxxxx>
- Subject: gTLD Draft Applicant Guidebook - Evaluation Questions and Criteria - Module 2
- From: "Robert C. Hutchinson" <bob@xxxxxxxx>
- Date: Mon, 13 Apr 2009 13:56:13 -0700
Dear Mr. Dengate Thrush and Dr. Twomey,
Thank you for the opportunity to provide comments on the ICANN second draft
of the new gTLD Draft Applicant Guidebook.
One of my primary interests in ICANN's policy making is the operational
security and stability of the Domain Name System. Existing security
problems with DNS have been exploited by thousands of hackers to harm
untold millions of unsuspecting internet users. While many of the simple
DNS exploits have been patched with techniques to make cache poisoning
more difficult, the long term solution to improving DNS security has
always been the addition of cryptographic signatures to the DNS resolution
protocol, embodied in the technology known as DNSSEC. DNSSEC protocol
and technology has taken more than fourteen years of development and will
likely be ready to deploy at the root and TLD level sometime in 2010/2011.
In the Applicant Guidebook, Draft Evaluation Criteria section, support for
DSNSEC by new gTLD applicants is "OPTIONAL". Because this question is
optional, an applicant can simply skip this criteria if they have no plans
and no qualifications for eventual DNSSEC implementation. Moreover, if we
have competing applicants for the same (or similar) string, evaluators
would want to know more about applicants' relative capabilities and
experience in implementing security mechanisms such as DNSSEC in order to
select the most qualified applicant.
I therefore believe that a more accurate score of an applicant's awareness
of the planning and technical issues surrounding DNSSEC would be achieved by
removing the "OPTIONAL" designation for item 50, and updating the question
text to reflect ICANN's current plans to deploy DNSSEC.
According to the Mexico City Security and Stability presentations, DNSSEC
may be ready to deploy in the 2010 timeframe when the root is signed and
many of the existing TLDs will begin to sign their zones. It is therefore
important to the operational and business planning of new gTLDs that they
factor into their plans the cost and technical resources necessary to
fully implement DNSSEC within the next two years. Failure to explicitly
prepare new gTLD applicants for the cost and technology needed to implement
DNSSEC, will allow them the defense that they were not "informed" of the
requirement to support DNSSEC, and therefore will need more time and
treasure etc.
My recommended change to the Guidebook is as follows:
In the Draft Evaluation Criteria section on Demonstration of Technical &
Operational Capability -
Item 50 is currently described as:
OPTIONAL.
DNSSEC: if the proposed gTLD will offer DNSSEC as a registry service at
the time of launch, describe the policies and procedures the proposed
registry will follow, for example, how keying material will be securely
exchanged and stored. Describe how the DNSSEC implementation will comply
with RFCs 4033, 4034, 4035, and 5155.
Recommended new item 50 Question text:
DNSSEC: The proposed gTLD should plan to offer DNSSEC as a registry
service sometime in calendar year 2010 or 2011. DNSSEC implementation is
described in IETF RFCs 4033, 4034, 4035, and 5155. Describe the
applicant's plan for DNSSEC; signing the TLD zone domains and securely
maintaining DNSSEC keys across the registry and registrar service
interfaces.
The remainder of the item 50 criteria and scoring text would remain
unchanged.
Respectfully,
Robert Hutchinson
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|