Skip to main content

Letter from Paul Twomey to VeriSign

Via E-mail and U.S. Mail

Russell Lewis
Executive Vice President, General Manager
VeriSign Naming and Directory Services
21345 Ridgetop Circle LS2-3-2
Dulles, VA 20166-6503

Re: Security and Stability Advisory Committee

- Review of VeriSign's Wildcard Implementation

Dear Rusty,

We are pleased that VeriSign has decided to "temporarily suspend" the core changes to the DNS and the related "SiteFinder" service (referred to collectively herein as the "Service Change") as of 4 October 2003, in response to the Internet community and ICANN's request for the full review of the related issues. As promised, we will now move quickly and carefully into a full technical and operational review of the matter.

This letter is written to explain the next steps in ICANN's technical review and evaluation of the Service Change, specifically as it involves ICANN's Security and Stability Advisory Committee (SECSAC) and the process that ICANN is pursuing so that we may reach conclusions regarding how to proceed in a timely fashion. This letter will respond only to the issues involving the technical review process and SECSAC activities and not to other issues raised in my correspondence to you of 3 October 2003 or the subsequent response by you relating to the same issues that evening.

As you are aware, in response to widespread expressions of concern from the Internet community, ICANN asked SECSAC and the Internet Architecture Board (IAB) to provide advice to ICANN immediately following the sudden introduction of the Service Change by VeriSign on 15 September 2003. SECSAC's responsibilities relating to this issue area are clear. In ICANN's ByLaws, Article XI, Section 2, Paragraph 2(a)(2) one of SECSAC's responsibilities is set out as follows: "To engage in ongoing threat assessment and risk analysis of the Internet naming and address allocation services to assess where the principal threats to stability and security lie, and to advise the ICANN community accordingly."

SECSAC has recently instituted two activities at the request of ICANN. These activities were commenced prior to VeriSign's agreement to "temporarily suspend" the Service Change, last Friday.

First, SECSAC collected information and sent a message to the ICANN Board of Directors on 22 September 2003 entitled "Recommendations Regarding VeriSign's Introduction of Wildcard Response to Uninstantiated Domains within COM and NET" (SECSAC Preliminary Recommendations). The SECSAC Preliminary Recommendations were issued one week after ICANN's request for a review and recommendation. The SECSAC Preliminary Recommendations of 22 September indicated among other things that:

"VeriSign's change appears to have considerably weakened the stability of the Internet, introduced ambiguous and inaccurate responses in the DNS, and has caused an escalating chain reaction of measures and countermeasures that contribute to further instability."

"VeriSign's change has substantially interfered with some number of existing services which depend on the accurate, stable, and reliable operation of the domain name system."

"Many email configuration errors or temporary outages which were benign have become fatal now that the wildcards exist. "

"Anti-spam services relied on the RCODE 3 response to identify forged email originators. "

"In some environments the DNS is one of a sequence of lookup services. If one service fails the lookup application moves to the next service in search of the desired information. With this change the DNS lookup never fails and the desired information is never found."

"VeriSign's action has resulted in a wide variety of responses from ISPs, software vendors, and other interested parties, all intended to mitigate the effects of the change. The end result of such a series of changes and counterchanges adds complexity and reduces stability in the overall domain name system and the applications that use it. This sequence leads in exactly the wrong direction. Whenever possible, a system should be kept simple and easy to understand, with its architectural layers cleanly separated."

The speed at which SECSAC evaluated the information available to them was commendable, and, as SECSAC noted itself, the work was preliminary and additional information was to be sought by SECSAC for its subsequent report to the board. Additional information gathering was also required in order to address the additional concerns raised in the document "IAB Commentary: Architectural Concerns on the Use of DNS Wildcards" issued by the IAB on 19 September 2003.

Secondly, SECSAC scheduled a special SECSAC Meeting, which is set for tomorrow, 7 October 2003 (referred to as the "7 October Meeting"), as formally announced by ICANN on 30 September 2003. Unfortunately, the Service Change was still up and running when the 7 October Meeting was scheduled. If this had not been the case it is likely that additional time might have been provided to allow for a full opportunity for the issues to be reviewed in one SECSAC meeting.

As the Service Change was suspended in such close proximity to the time of the scheduled meeting, we now believe that the SECSAC Meeting should continue as scheduled, but that the data can be collected in multiple parts.

ICANN is setting out that the 7 October Meeting shall remain on schedule, and that a second meeting should be held two weeks later or at such a time as VeriSign is ready to state its full technical position (referred to as the "Second Meeting"). VeriSign is also formally requested to release its testing data from before, during and after the Service Change and to do so well in advance of the Second Meeting.

SECSAC has assured ICANN that the 7 October Meeting will be held with all due fairness, and that VeriSign will be provided an opportunity to ask questions, and to make a presentation. Although questions have been raised regarding the presenters and agenda for the 7 October Meeting, it is important to note that the membership of SECSAC was established prior to this current matter. The SECSAC Members are sufficiently diverse to ensure fairness in developing the agenda and presentations for the 7 October Meeting.

Additionally, it is assumed that during the following two weeks or at VeriSign's election during the latter presentation to SECSAC, VeriSign may offer refutations of the evidence and statements collected and made during the 7 October Meeting. SECSAC will also requests that VeriSign offer the SECSAC Members and other members of the Internet community the opportunity to question and to provide evidence refuting VeriSign's presentation and data during and following the Second Meeting.

Following the Second Meeting, SECSAC will hold open a time period to collect such additional information as might be provided to clarify remaining issues and concerns of VeriSign, SECSAC and the Internet community as a whole. SECSAC will then issue its more formal recommendation to ICANN, which will then decide along with other analysis data and/or dialogue among the relevant technical experts, as may be required, to permit, deny or place additional conditions upon VeriSign before it authorizes a re-launch of the SiteFinder service.

We look forward to continuing dialogue with VeriSign throughout this process to ensure that all issues and technical evaluation information is fully considered and weighed appropriately. We also would like to request that VeriSign consider and propose the most appropriate date and location of the Second Meeting, as soon as practicable.


Dr. Paul Twomey
President and CEO ICANN

cc: Steve Crocker, SECSAC
John Jeffrey, ICANN
James M. Ulam, VeriSign

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."