|
As an advisory committee, our focus is to give ICANN and the community our best advice regarding security and stability issues for the domain name system and the addressing system. We are not a standards, regulatory, judicial or enforcement body; those functions belong elsewhere.
As we all know, VeriSign is in the process of suing ICANN on a number of matters, including ICANN’s response to their registry change last September. Although VeriSign now contends that a number of us on the committee are “Site Finder co-conspirators” the next steps are really up to the ICANN board, the ICANN staff and the many members of the technical and operating community who run the domain name system.
I’ll be happy to interact with the members of the community here on CircleID as time permits.
I think the best way to start is with the executive summary of the report titled “Redirection in the COM and NET Domains, A Report from the ICANN Security and Stability Advisory Committee (SSAC)”. These findings and recommendations were developed after extensive inputs by email and in two public meetings in October 2003. The transcripts of those meetings are available from the ICANN web site.
At the end of this summary below, I’ve added some comments on the proposed next steps.
Executive Summary
On 15 September 2003, VeriSign, Inc. changed the way that NET and COM registries responded to lookups on nonexistent—or uninstantiated—domain names. In so doing, the company changed the way that the domain name system (DNS), a fundamental component of the Internet architecture, provides services for two large top-level domains. VeriSign’s action was aimed at the World Wide Web but had unexpected effects on the other parts of the Internet. VeriSign refers to this set of changes as the introduction of its Site Finder service, focusing attention on the functionality provided to Web users who mistyped domain names and were routed to VeriSign’s servers. The specific technical change substituted a “synthesized response” for an error message, and applications that relied on the original error code unexpectedly failed. At ICANN’s insistence and after widespread protest from the technical community, VeriSign suspended the Site Finder service on 4 October 2004.
This report by the Security and Stability Advisory Committee (SSAC), an advisory committee to ICANN, describes VeriSign’s actions of September-October 2003 and the technical community’s responses to those actions and then analyzes the sequence of actions and reactions from the perspective of security and stability of the Internet. The Committee then presents its findings and recommendations. The Committee’s primary focus is not Site Finder, per se. Rather, our focus is two-fold: that core registry operations were modified, thereby changing existing services, and that the change was introduced abruptly without broad notice, testing, refinement or community agreement.
The Committee finds that VeriSign’s actions did not have network-shattering effects but did violate fundamental architectural principles and well-established codes of conduct and good practice intended to ensure stability. Users’ decisions and control were preempted and users were potentially subjected to violations of their privacy. Local responses, patches and work-arounds reduced overall coherence. Services that had been functioning satisfactorily were disturbed and the direct and indirect costs of these disruptions were imposed on third parties. Specifically:
Finding (1): VeriSign introduced changes to the NET and COM registries that disturbed a set of existing services that had been functioning satisfactorily. Names that were mistyped, had lapsed, had been registered but not delegated, or had never been registered in DNS were resolved as if they existed. As a consequence, certain e-mail systems, spam filters and other services failed resulting in direct and indirect costs to third parties, either in the form of increased network charges for some classes of users, a reduction in performance, or the creation of work required to compensate for the consequent failure.
Finding (2): The changes violated fundamental Internet engineering principles by blurring the well-defined boundary between architectural layers. VeriSign targeted the Site Finder service at Web browsers, using the HTTP protocol, whereas the DNS protocol, in fact, makes no assumptions - and is neutral - regarding the protocols of the queries to it. As a consequence, VeriSign directed traffic operating under many protocols to the Site Finder service for further action, and thus, more control was moved toward the center and away from the periphery, violating the long-held end-to-end design principle.
Finding (3): The mechanisms proposed by VeriSign to ameliorate the undesirable effects of their diversion on protocols other than HTTP put VeriSign in the implementation path of every existing and future protocol that uses DNS. For every such protocol, it would be necessary to consult with VeriSign to figure out how to simulate the response of the protocol to “no such domain.” This is an unacceptable invasion of clear layering.
Finding (4): Despite a long period of internal research and development, the system was brought out abruptly. The abruptness of the change violated accepted codes of conduct that called for public review, comment and testing of changes to core systems; this process exists to ensure that changes are introduced with minimal disruption to existing services and hence with minimal disruption to the security and stability of the Internet. It also precluded the possibility that administrators, IT departments, ISPs and other intermediaries on whom end users rely might be adequately prepared to deal with the consequences.
Finding (5): In response, workarounds and patches were introduced quickly, cumulatively reducing the overall coherence of the system and again violating the established practices of public evaluation, testing, discussion and review before core services are implemented and deployed. These workarounds further blurred the functional layers intrinsic to the Internet’s robust architecture and in some instances created additional—and unintended—harmful effects.
Finding (6): Information about intended e-mail senders and receivers was necessarily accepted by VeriSign’s servers without the knowledge or consent of either sender or receiver. VeriSign strenuously denied retaining this information.
Finding (7): The behavior of end users redirected to the Web site was observed by a program embedded in the Site Finder service, and users could neither accept it, reject it nor substitute another, similar service for it.
Finding (8): The cycles of changes and responses collectively undermined expectations about reliable behavior and in so doing reduced trust in the security and stability of the system. On the basis of these findings, the Committee makes the following recommendations:
Recommendation (1): Synthesized responses should not be introduced into top-level domains (TLDs) or zones that serve the public, whose contents are primarily delegations and glue, and where delegations cross organizational boundaries over which the operator may have little control or influence. Although the wildcard mechanism for providing a default answer in response to DNS queries for uninstantiated names is documented in the defining RFCs (Requests for Comment), it was generally intended to be used only in narrow contexts (for example, MX records for e-mail applications), generally within a single enterprise, and is currently used in top-level domains that are generally small and well-organized.
Recommendation (2): Existing use of synthesized responses should be phased out in TLDs or zones that serve the public, whose contents are primarily delegations and glue, and where delegations cross organizational boundaries.
Recommendation (3): There exist shortcomings in the specification of DNS wildcards and their usage. The defining RFCs should be examined and modified as necessary with a focus on producing two results: first, clarification of the use of synthesized responses in DNS protocols; second, provision of additional guidance on the use of synthesized responses in the DNS hierarchy.
Recommendation (4): Changes in registry services should take place only after a substantial period of notice, comment and consensus involving both the technical community and the larger user community. This process must (i) consider issues of security and stability, (ii) afford ample time for testing and refinement and (iii) allow for adequate notice and coordination with affected and potentially affected system managers and end users. Thirty years of experience show that this strategy ensures robust engineering and engenders trust in the systems and the processes surrounding their maintenance and development.
Sponsored byIPv4.Global
Sponsored byRadix
Sponsored byCSC
Sponsored byVerisign
Sponsored byDNIB.com
Sponsored byVerisign
Sponsored byWhoisXML API
Keep up the good work, Steve. Don’t let the paper tiger VeriSign try to bully the committee.
One point VeriSign likes to attempt to make is that the report lacked “data” to back its positions. However it was very clear from the nearly 20,000 signatures (or “conspirators”, in VeriSign-speak) on the Stop VeriSign DNS Abuse petition that there was overwhelming opposition to SiteFinder. Furthermore, nearly all the correspondence and comments were negative. Not just mildly negative, either—folks were vehement in their opposition to VeriSign’s abusive behaviour.
Have you tried to get VeriSign to comment? They’ve tried to brush aside those comments, pidgeon-holing them as unrepresentative, but I think the comments are far more persuasive than the unscientific and biased polling they had conducted (everyone knows how easy it is to get a desired result through “framing” the series of questions; one can get any desired result, as demonstrated vividly in a classic episode of Yes, Prime Minister).
Has the SSAC considered recommending to the Board that a “Consensus Policy” be enacted, to ensure with certainty that wildcards cannot be introduced, as registries must comply with consensus policies?? I’m sure it would get the supermajority required from the various constituencies of the GNSO (save for the VeriSign-dominated gTLD registries constituency).
One other thing—has there been any effort exerted by ICANN to get back the money VeriSign received from their abuse of wildcarding?
Dear Steve,
I was hoping that ICANN would establish a forum for public comments on your Report. But this forum will do.
I represent one of the 15 other tld’s (PW) that use the wildcard mechanism: the group is listed in one of the report’s footnotes.
The SSAC report clearly represents a thorough investigaton and analysis of Verisign’s use of the wildcard in com and net. It certainly helps advance the understanding of the various issues involved.
But, aside from the footnote mentioned above, there is little discussion on how the other 15 tld’s are using the wildcard mechanism. I presume this is because, in fact, there was little investigation or analysis of how the other 15 tld’s were using the wildcard mechanism.
I was therefore surprised to see the recommendation that use of the wildcard mechanism be phased out across in other tld’s besides com and net. This recommendation does not appear to be substantiated anywhere in the body of the report.
I realize that your recommendations are qualified (“whose contents are primarily delegations and glue and where delelgations cross organizational boundaries..”), however, most readers will fail to see this distinction.
Instead, most readers will naturally conclude, as did an analysis distributed on the GAC list, that all use of the wildcard mechanism across the other 15 tld’s should be phased out.
The implication is that use of the wildcard mechanism by these 15 tld’s somehow threatens the security and stability of the internet.
Clearly this is not the case.
I suggest that recommendations regarding the other 15 tld’s should be removed from the report, since these specific tld’s and their uses of the wildcard mechanism were not investigated or analyzed as part of the effort. Correct me if I am wrong about this and you can share additional analysis with us.
In its place, I would propose that a review process be established, whereby tld managers have the opportunity to explain and demonstrate how their use of the wildcard mechanism does not and would not threaten the stability of the internet.
Through this type of dialogue, there can be continued creative use of the wildcard mechanism by tld operators in conjunction with industry review to ensure security and stability is not being compromised.
This week, PW Registry opened a 30-day public comment period on its plans for the PW tld. This includes our use of the wildcard mechanism. We welcome any and all comments regarding our use of wildcarding as well as other policies. These can be submitted publicly or privately. Public comments may be made at http://forums.pwregistry.pw
Best Regards,
Thomas Barrett
Pw Registry Corp.
www.pwregistry.pw
It’s interesting what this report doesn’t say.
This report doesn’t say that VeriSign actually breached any contracts or laws. The report criticizes VeriSign for violating certain expectations and assumptions—VeriSign violated “fundamental Internet engineering principles,” “accepted codes of conduct” and “established practices,” meaning that VeriSign “undermined expectations about reliable behavior.” But is that all? If so, it is tantamount to saying that “we wish VeriSign hadn’t done this, even though they were legally free to do so.”
This report also doesn’t address how end users felt about the wildcarding service. Isn’t that an important inquiry? If end users like wildcarding and find it helpful, shouldn’t that be considered?
Responding to George Kirikos on his suggestion that a “Consensus Policy” be developed, our fourth recommendation concerning introduction of changes did indeed include consensus as one of the criteria.
Responding to Thomas Barrett, we’ve recommended use of wild cards be phased out in the TLDs that are currently using them. We recognize this is a sensitive matter and we debated it at length. We definitely do not want to cause harm or perturbation. At the same time, it became evident that using wild cards in the general way has unfortunate side effects. We separated this recommendation from our prior one that wild cards not be introduced into TLDs where they do not already exist because we recognize this situation requires separate treatment. We expect in most cases there are other ways for a TLD to accomplish its goals, and we, among others in the technical community, are available to work with you and the other TLD operators.
Responding to Eric Goldman, we specifically did not speak to the contractual issues because that’s outside the scope of our committee. We are an advisory committee on security and stability matters. Contractual matters are handled by the ICANN. Our report does not imply VeriSign is legally free to do what it did, but it’s not our job to speak to that issue.
With respect to how users felt about the service, we documented that a large number of users were displaced and disrupted by the change. VeriSign argued that a large number of users liked the change. That’s not quite the right basis for these kinds of decisions. Equivalent service has been available for a long time through plug-ins in browsers without disturbing the underlying functionality of the domain name system. Moreover, the user can choose whether or not to use such plug-ins, whereas a change deep inside the domain name system results in an imposition on all users without their concurrence.