* In this issue: Update on November 2001 ICANN Meeting and ccTLD Security Work

To all ccTLD Administrative and Technical Contacts:

With this e-mail, we are resuming the ccTLD News Memo series that was last active in 1998.

This e-mail has two parts: (A) an update on the program for next month's ICANN meeting in Marina del Rey; and (B) an invitation to the ccTLD community to initiate a bottom-up effort to assess and improve ccTLD registry security practices.

(A) Update on November ICANN Meeting

We look forward to seeing many of you at the upcoming ICANN meeting. Following the usual round of constituency meetings on 11 and 12 November, the focus of the meeting on 13-15 November will be on DNS security/integrity/resiliency issues. We intend to make it participatory, with panel and roundtable discussions, breakout working groups, and constituency meetings.

The updated (but still tentative) schedule for the meeting, including panels topics, is as follows:

13 NOVEMBER - Tuesday

0830 - CEO Welcome
0845 - Plenary talk - Steve Bellovin
0930 - Panel - Root Nameserver security
1030 - Break
1045 - Panel - DNS Security - Past & Future
1145 - Panel - TLD registry and nameserver security
1245 - Lunch - speaker
1430 - Cross-Constituent break-out groups
1615 - Break
1630 - Panel - Registry/registrar recovery & restoration
1930 - Reception - Marriott

14 NOVEMBER - Wednesday

0830 - Plenary talk - John Tritak
0900 - Plenary talk - Bruce Schneier
0945 - Break
1015 - Roundtable sessions
    • Management focus
    • Technical focus
1215 - Lunch
1315 - Constituency meetings
1600 - Names Council wrap-up
1930 - Reception - Getty Museum

15 NOVEMBER - Thursday

0800 - Reporting session
    • Root Name Server operators
    • Regional Internet Registries
    • gTLD Registries
    • gTLD Registrars
    • ccTLD Registries
    • ISPs
    • Others
1000 - Open mike on security
1100 - Board meeting on security
1230 - Lunch
1400 - Open mike on other
1500 - Board meeting on other

As the schedule reflects, we are planning four panel sessions:

(1) Root Name Server Security.

Description: Overview of present system, security aspects, short term plans for enhanced security, longer term considerations.

(2) DNS Security: Present and Future.

Description: Overview of current security aspects of domain nameservers and plans for future security enhancements, such as DNSSEC.

(3) TLD registry & nameserver security.

Description: Overview of Registry operational & nameserver security considerations.

(4) Registry/registrar recovery/restoration.

Description: Management of crisis situations (both preparation for and recovery from), with an emphasis on post-Sept 11 threat analysis and response.

Obviously, we are working to have ccTLD manager participation on panels (3) and (4). Panel membership is being finalized by the program committee. Schedule updates are being posted regularly at <http://www.icann.org/mdr2001>.

As you will note, we will be asking the ccTLD constituency to meet on the afternoon of 14 November, to prepare for a public report on the morning of 15 November. The agenda for that meeting and the report are, of course, up to the ccTLD community. We anticipate that the ccTLDs will work together to justify the confidence of the global Internet community, and to evaluate what security-related efforts should be undertaken by ccTLD managers, individually and collectively.

In that regard, let me turn to the second, closely related topic of this e-mail.

(B) ccTLD Security Work

In the wake of 11 September, many people around the world are looking at the Internet and saying: "I depend on it. Is it secure, in the face of crisis situations? Is it reliable?" From the standpoint of the DNS, we know that it is remarkably robust and resilient. The underlying distributed architecture of the DNS is itself an enormously powerful platform for stability and integrity. And we know that the DNS registries include a number of very impressive, highly secure operations.

At the same time, I think it is fair to say the following:

(1) It is reasonable for Internet users, ISPs, governments, etc., to ask about the security of the DNS and its registries.

(2) To merit confidence among the user community, we have to be able to explain the architecture of the DNS and the security work that has already been done by the registries. We also have to evaluate what additional steps can be done, and document what is expected of registries in this area (i.e., in a "best practices" or similar document).

(3) There is always room for improvement; you can always learn from the experiences of your peers (this applies to ICANN no less than to the registries).

With that in mind, ICANN is looking to the root nameserver operators, the name and address registries, and the gTLD registrars to take seriously the security worries of the global Internet's user communities, and to develop, in a bottom-up way, standards and reports to justify the confidence of those communities. Some of those groups have already begun their work:

• Root Nameservers. Through the Root Server System AdvisoryCommittee and various collaborators, the root nameserver operators are working on a range of efforts to improve the overall stability and integrity of the root nameservers. They will be reporting to the community by way of a panel on 13 November.
• gTLD Registries. ICANN has asked the gTLD registries to prepare reports on security-related topics. The gTLD registries have all agreed to do so, and are collectively working on a Registry Best Practices document that focuses on security. The gTLD constituency has also formed a Registry Failure Task Force, which will examine ideas like a "buddy" system.
• RIRs. The IP address registries have agreed to give a report focusing on security.

Because they are so much more numerous, however, we have not asked the ccTLD registries or gTLD registrars to undertake any security-related work in advance of the November meetings. But I do ask that you begin to think about initiatives in the area of DNS registry security. As a community, we must demonstrate that security issues are being given adequate consideration by the TLD registries, ICANN, etc.

At the November meeting, there will be two focus areas: one primarily for a technically inclined audience that builds on panels addressing issues relating to root-servers and DNSSEC; and another for a registry/registrar managerial audience that builds on panels that cover nameserver security and registry service recovery/restoration issues. Panel discussions, and breakout session workshops, will occur for participants to address the issues with colleagues and counterparts. Additionally, we are inviting the constituencies to meet on the afternoon of 14 November, and to make presentations to the community on 15 November.

In sum, constituents within the ICANN community are being asked to begin internal dialogues on their respective security issues. For example, the gTLD registry constituency is discussing registry security and recovery topics, Registry Best Practices, and will be providing a constituency presentation on the status of their work. We know that many ccTLDs already have effective practices in place regarding security issues, both for protection from potential threats and the recovery/restoration in crisis situations.

In similar fashion, we want to encourage the ccTLD registries to begin a community dialogue about ccTLD registry security issues, especially from a ccTLD manager's standpoint and at the national level. Existing practices should be addressed, exploring whether there are common standards. For example, can we identify standard ccTLD registry measures relating to protection against potential threats, such as site security, network security, or management and personnel practices? Can we identify standard practices by ccTLDs to recover from actual serious failures, such as data backup, data escrow, or recovery procedures and processes. What reporting mechanisms should we expect? We note that the ccTLD constituency of the DNSO has already done work in this area, as have some of the regional ccTLD organizations. The constituency's Best Practice Guidelines identifies some of these issues, for example, in Section 3.3 ("Operational Requirements").

Please feel free to contact me or Herbert Vitzthum, ccTLD Liaison, should you have any questions or like to explore areas of discussion.

With kind regards,

M. Stuart Lynn
ICANN CEO/President