Skip to main content
Resources

Minutes | Board Technical Committee Meeting

Board Member and Liaison Attendees: Cherine Chalaby, Avri Doria, Rafael Lito Ibarra, Akinori Maemura, Ram Mohan, Kaveh Ranjbar (Chair), George Sadowsky, and Jonne Soininen.

Board Member and Liaison Apologies: Ron da Silva.

Other Board Members in Attendance: Khaled Koubaa and Matthew Shears.

Observers: Merike Kaeo and Tripti Sinha.

ICANN Organization Attendees: Adiel Akplogan (Vice President for Technical Engagement), Michelle Bright (Board Content Coordination Director), Franco Carrasco (Board Operations Specialist), James Caulfield (VP, Risk Management), David Conrad (Chief Technology Officer), Steve Conte (Office of the CTO Programs Director), Samantha Eisner (Deputy General Counsel), Dan Halloran (Deputy General Counsel), Aaron Jimenez (Senior Coordinator, Board Operations), Matt Larson (VP Research, Office of the CTO), Wendy Profit (Senior Manager, Board Operations), and Ashwin Rangan (Chief Information Officer).


The following is a summary of discussions, actions taken, and actions identified:

  1. BTC Working Methods and Support from ICANN org – The Committee engaged in a discussion about planning for leadership of the Committee in the coming year. It was noted that a new Committee Chair would be part of the slate of appointments by the Board Governmance Committee at the Annual General Meeting as the current Chair did not intend to serve in such a capacity next year.

    The Committee also discussed having more structured and dedicated support from ICANN org staff members to assist with the upcoming work of the Committee, and the Chair provided an update on ongoing conversations with the President and CEO about such support from ICANN org.

  2. BTC Work Plan – The Committee discussed developing a work plan for the next three meetings so that ICANN org members providing support to the Committee could begin helping to plan the meeting dates, agendas and any necessary briefings for the Committee.

    The Chair noted that there is an open request for the Committee to have a joint meeting with the Board Risk Committee. Committee members discussed the possibility of attending the workshop proposed for the Board Risk Committee during the upcoming ICANN meeting in Barcelona. The Committee also discussed having a joint meeting with the Technical Experts Group in Barcelona. Members of the Committee suggested that the meeting be open to the public to give additional opportunities for the community to follow along with the work of the groups and to understand the technical matters under discussion.

  3. Cybersecurity Assessment – The Committee received an update from the Chief Information Officer (CIO) about ICANN org's yearly external assessment on cybersecurity preparedness. For cybersecurity metrics and measurement, the CIO reported that ICANN has been using the CIS20 framework over the last several years.

    Committee members asked questions about the results of the assessment, including whether the assessment involves penetration testing of ICANN org's. Also, Committee members asked for additional details about what steps are taken by ICANN org to improve scores from year-to-year. The CIO provided information about the types of pentration testing that are included in the assessment, and also gave an update what steps have been taken over the years to harden the organization's systems.

    As part of the CIO's update, he highlighted five projects that are being undertaken to address cybersecurity preparedness, and also noted that the team was considering the possibility of using the NIST framework going forward to assess cybersecurity preparedness. The CIO informed the Committee that the NIST framework seemed to be emeraging as the global model from a cybersecurity assessment perspective.

  4. KSK Rollover – The Chief Techonology Officer (CTO) provided an update to the Committee about ICANN org's plan to change the cyrptograhphic keys that help protect the DNS (i.e. the KSK rollover), which is scheduled for 11 October 2018. The update included background information leading up to the planned KSK rollover, including the Board's request to the RSSAC, SSAC, and RZERC for their advice regarding the proposed plan to roll the KSK in October. The CTO reported that all three of those advisory committees responded to the Board's request, and have indicated in one form or another that they did not identify a reason not to move forward with KSK rollover as planned.

    The CTO noted that there was a minority dissent in SSAC in response to the Board's request for advice about about the proposed plan to roll the KSK, and the Committee engaged in an indepth discussion to understand the reasons for the minority dissent. As part of the discussion, the Committee considered whether there were additional methods of gathering information about the potential impacts of rolling the KSK, and if so, whether these methods should be deployed to gather additional information before the Committee makes a recommendation to the Board about how to move forward with the plan to roll the KSK. An additional concern discussed by the Committee was understanding the various viewpoints of the SSAC members who dissented. One Committee member recommended that that it would be prudent to speak to the dissenting members of the SSAC along with those who were in the majority before the Committee makes a recommendation to the Board about whether or not rolling the KSK in October should continue as planned.

    Committee members expressed varying views on the matter. Some recommended that additional information should be gathered before rushing to move forward with rolling the KSK given that more information may help to better assess potential impacts to public services, such as schools, fire, police, etc. Others highlighted that the methods proposed for gathering additional data may not result in additional information that would change the risk calculus of whether or not to move forward with the rollover of the KSK as planned in October. Additionally, some members of the Committee highlighted that the Committee (and the Board) should focus on assessing the risk of moving forward now or later, and focus on whether there is a proper incident response plan in place if there are negative impacts of rolling the KSK.

    The CTO provided additional information about the KSK preparedness survey and other data gathering methods used by the Office of the CTO to help assess the risk of the number of misconfigured systems that could potentially be impacted by the KSK rollover. He also discussed the plan developed for mitigaging possible negative impacts of rolling the KSK.

    As part of its discussion about the SSAC's comment to the Board concerning the KSK rollover, the Committee also engaged in a discussion about the nature of SSAC reports and whether there is a difference between the SSAC issuing an advisory versus a comment. The SSAC Liason to the Board provided an explaination about when the SSAC may issue a comment veruses advice, and confirmed the the comment provided about the KSK rollover went through the full-scale process inside the SSAC before it was submitted to the Board. It was suggested that if the Committee (or Board) had concerns about whether or not the SSAC provided thorough guidance or advice to the questions asked by the Board, that the Board should considering engaging with the SSAC as soon as possible to discuss matter.

    After discussion, the Committee approved the recommendation that the Board approve the KSK rollover as planned for 11 October 2018, with one Committee member opposed to the recommendation.

  5. Root Server Strategy – The CTO provided an update to the Committee about the work to develop an overarching strategy to reduce the effects of attacks on the root server system, of which the L-root strategy is a portion. He noted that the risk of attacks against the root are increasing as a function of the growth of the Internet in terms of devices as well as bandwidth and capacity. The traditional approach of addressing these risks, such as increasing capacity or providing more money to address the problem, may not be able to keep up because the attackers appear to be able to add more capacity than the defenders can afford to match.

    The CTO reported on ICANN org's draft strategy to address risks to the root server system. The strategy is based on the following model of security: confidentiality (to protect the root service from eavesdropping), integrity (to protect the root service from data manipulation), and availability (to protect root service from going away).

    The CTO requested that the Committee recommend that the Board direct ICANN org to initiate a consultation with the community to finalize the strategy, and once finalized, to initiate a project plan to move forward with the strategy.

    Committee members engaged in a discussion about the proposed recommendation to the Board, which included discussion about potential budget implications and a timeframe for implementation. After discussion, the Committee decided to move forward with recommending that the Board direct ICANN org to initiate a consultation with the community to finalize the root server strategy, and once finalized, to initiate a project plan for the agreed upon strategy.

The Chair called the meeting to a close.

Published on 6 December 2018

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""icann.org"" is not an IDN."