Skip to main content
Resources

Minutes | Board Technical Committee Meeting

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

Board Members Observing: Matthew Shears and Mike Silber.

ICANN Organization Attendees: Adiel Akplogan (VP Technical Engagement), Susanna Bennett (Chief Operating Officer), David Conrad (Senior Vice President and Chief Technology Officer), John Crain (Chief Security, Stability & Resiliency Office), Alain Durand (Principal Technologist), Dan Halloran (Deputy General Counsel), Matt Larson (VP Research, Office of the CTO), Wendy Profit (Senior Manager, Board Operations), Ashwin Rangan (SVP Engineering & Chief Information Officer), and Lisa Saulino (Board Operations Senior Coordinator).


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

  1. Update from the Chief Information Officer – The Committee received an update from the Chief Information Officer (CIO) about vulnerabilities, end-user support to the Board, and metrics and measures. As part of the discussion about vulnerabilities, the CIO provided an update to the Committee about the security issue related to ICANN's use of Adobe Connect and next steps to settle on what tools would be used for community collaboration. Additionally, the CIO reported that ICANN org recently adopted a coordinated disclosure policy, which will help ensure that ICANN discloses vulnerabilities in a responsible manner, in particular given that disclosure about vulnerabilities in cloud-based services presents unique challenges.

    The CIO's briefing included an update on the operational changes to how end-user support is being provided to Board members, which includes a tracking/ticketing system. The CIO noted that it may be about six months before there is meaningful data from which reports can be generated.

    The CIO also updated the Committee about the metrics and measurement systems adopted for cybersecurity purposes, noting that it is prudent to review different framworks to determine whether ICANN's systems are hardened from a variety of different perspectives. For cybersecurity metrics and measurement, the CIO reported that ICANN has been using the CIS20 framework over the last several years and is considering the possibility of using additional frameworks.

    The CIO was asked to provide an update on the implementation of the new enterprise resource planning (ERP) solution, to include a status update on what elements have been delivered, what remains outstanding, and how successful the process is going.

    • Action Item:
      • ICANN Chief Information Officer to prepare briefing for the Committee regarding the demarcation of responsibilities between the IT end-user support team and Board members with respect to technical devices used by the Board.
      • ICANN org to prepare a briefing to the Committee to provide a status update on the implementation of the ERP solution at a subsequent Committee meeting.
  2. SSAC Proposal for Name Collision Analysis Project – The Committee received an update on the SSAC Proposal for Name Collision Analysis Project. The analysis is proposed to be completed in three studies. The first study would focus on gathering data and building a repository of the data. Specific tasks related to this study would involve defining name collisions and looking at past studies concerning name collisions. The analysis would be presented in a written report, which would be shared with the community for feedback.

    The second study would look to identify gaps in the data and determine if there are any other data sets that might be required for the analysis. Once completed, a test system could be built to do an impact analysis.

    The final study would look at the possible courses of action that might mitigate harm for specific strings like .CORP, .HOME, and .MAIL and then extrapolate the results to see if there are generic mitigation measures that might be applicable for other strings.

    The Committee was informed that SSAC proposes to conduct three workshops over the course of the project, which would include 1 – 2 days of public engagement and 2 – 3 days of private interactions. The workshops could be held prior to or after ICANN meetings.

    The Committee engaged in a discussion regarding the scope of the project, projected timelines, project funding, handling potential conflicts of interests, and project management. As part of its discussion, the Committee identified several questions that it would like to discuss with the SSAC including, whether the scope of the project should include name collisions beyond the top-level, if conclusions would apply to other potential name collisions (other than .HOME, .CORP, and .MAIL), timing considerations, project management, and the resources needed to conduct the proposed analysis.

  3. Root Zone Management System Evolution Study – The Committee received a briefing from the Office of the Chief Technology Officer (OCTO) on the work underway to investigate whether the current practice for making modifications to the root zone content should be updated to eliminate single points of failure. This work is intended to fulfill the March 2016 IANA Stewardship Transition Coordinatin Group (ICG) proposal. The OCTO team reported that it proposed to conduct the analsyis through two studies, which would be the subject of RFPs. The first study would evaluate the process as it is today and provide possible recommendations on incremental changes that could be made to make the process more robust. The second study would not be limited to making incremental changes to the current approach, but would instead consider potential new approaches for making changes to the content of the root zone. The two RFPs would run serially, with the first RFP proposed to be open by mid-May. The Committee discussed whether the studies would focus on engineering aspects of a tamper-proof root zone and the OCTO team explained that the two-study approach would provide some flexibility to allow research for new concepts and approaches in addition to the engineering requirements. The Committee also discussed potential costs for undertaking the studies.
  4. Technical Questions Received from Constituencies – The Committee discussed possible responses to technical questions submitted by ICANN constituencies to the Board. The first question concerned the Board's perspective on the proposed KSK Rollover Plan and how the Board determined the level of "breakage" that would be acceptable when rolling the KSK. The OCTO team provided its perspective on this question, and the Committee discussed the importance of encouraging broad participation from the community in providing comments on the KSK Rollover Plan, including on this question. The Committee noted that input from the community would assist the Board's deliberations when it considers adopting the KSK Rollover Plan.

    Members of the OCTO team provided an update on the timing of the public comment period on the KSK Rollover Plan and next steps. The team informed the Committee that there are varying views within the community about the timing of the KSK rollover. Some parts of the community are urging ICANN to roll the KSK as soon as possible, while others advise that ICANN should do more work to understand the risks involved before moving forward with rolling the KSK.

    The Committee discussed plans to further engage with the RSSAC and the SSAC to seek feedback on the KSK Rollover Plan. The Committee also discussed the recovery time needed to address "breakage" resulting from rolling the KSK, as well as a question it received about the Board's position on the expansion of the root.

  5. Update from the Chief Technology Officer (Open to the community) – The Committee received an update from the Chief Security, Stability & Resiliency (SSR) Officer regarding the Domain Abuse Activity Reporting (DAAR) system, which is a system for reporting domain name abuse across gTLDs. The DAAR system employs reputation block lists and looks at multiple types of DNS abuse, including malware, botnets, phising and spam. The Chief SSR Officer indicated that the team is publishing the methodology used to generate reports from the DAAR system to provide transparency, and to allow others to replicate the results presented in the report. Also, the goal is to publish the relevant data sets as part of the Open Data Initiatve so that the community has access to the data sets.

    The update to the Committee also included discussion about reputation block lists and the role that these lists play in identifying domain name abuse, as well as the trends seen in the data. Some members of the Committee inquired about the inclusion of spam in the data set being analyzed, and asked for additional briefing on this point and whether it is consistent with ICANN's mission.

    The Chief SSR Officer informed the Committee that the methodology used to develop the DAAR reports is currently being reviewed by two independent security experts.The Office of the CTO is also interested in having the SSAC, the gTLD Registry Stakeholder Group, and potentially ccTLD registries review the methodology.

    • Action Item:
      • The Office of the CTO to prepare a briefing addressing the use of spam as an indicator of DNS abuse.
  6. Any Other Business (Open to the community) – The Committee discussed the frequency and structure of the existing Committee meetings. Currently, the Committee meetings are divided into three parts: one looks into ICANN organization's internal IT projects; another looks at the developments related to the work of ICANN constituencies and any resulting technical requirements; and the third is the public portion where the Committee looks into future developments in technology.

    The Committee discussed possibly combining the public portion of the Committee meeting with the meetings of the Technical Experts Group (TEG). The TEG was created prior to the existence of the Committee as a way for the Board to get exposed to the technological developments within the context of the Internet identifier space. Since the creation of the Committee, there is a question about whether it is necessary to continue the TEG in its current format or to use the public portion of the Committee meetings as a substitute. Also, there is a question about the role of the TEG in relation to the role of the Committee.

    After discussion, the Committee agreed to explore having three full meetings each year, which would take place during the ICANN meetings. There will be no interim workshops or telephonic meetings, unless there is an agenda topic that needs to be discussed.

    • Action Item:
      • The Office of the CTO to prepare a proposal on how to integrate the Technical Experts Group meeting into the public portion of the Board Technical Committee meeting.

The Chair called the meeting to a close.

Published on 12 July 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."