Skip to main content
Resources

Minutes | Board Technical Committee (BTC) Meeting

Board Member and Liaison Attendees: Harald Alvestrand, Avri Doria, Rafael Lito Ibarra, Merike Käo, Akinori Maemura (Chair), Mandla Msimang, Patricio Poblete, Kaveh Ranjbar, Nigel Roberts, 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 Caufield (VP, Risk Management), David Conrad (Chief Technology Officer), Steve Conte (Office of the CTO Programs Director), John Crain (Chief Security, Stability & Resiliency Officer), Kim Davies (VP, IANA Services and President), Linna Hsii (Counsel), Matt Larson (VP, Research), Ashwin Rangan (SVP Engineering & Chief Information Officer) and Carlos Reyes (Strategic Policy Planning Director).

Invited Guests: James Galvin (Security and Stability Advisory Committee (SSAC) Name Collision Analysis Project (NCAP) Working Party (WP) co-chair and only present for agenda item no. 1.)


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

  1. BTC Session with the NCAP Co-Chair – James Galvin, the co-chair of the NCAP discussion group, provided the Committee with an update on their work. Since discussion group's last update, James reminded the Committee that following Scarfone Security's recommendation to not continue with Studies 2 and 3 as currently designed, the discussion group provided some suggested alterations which will reduce the scope and budget for the project. The first proposed alteration is to eliminate one of the elements proposed in Study 2 which is to build a data repository. The discussion group has come to the understanding and realization that such data repository is not necessary. The second proposed alteration, also noted in Study 2, is to remove the task of building a test system for impact analysis. Similar to the data repository, the discussion group has concerns that such a repository could be built and be sustainable in the long term. The third and final alteration is to explain and expand on what it means to "conduct an impact analysis".

    The first element of the impact analysis is to conduct a data sensitivity analysis which seeks to answer what is the minimum data set that will be needed to conduct name collision analysis in future applications. The second part of the impact analysis will focus on case studies conducted for .CORP, .HOME and .MAIL in 2012 and build on those, specifically with longitudinal analysis to see what changes have taken place over the years. In addition to .CORP, .HOME and .MAIL, there will also be a focus on NXDOMAIN queries, names which seem to consistently be queried at the root that don't currently exist to see what can be learned from them. The third part of the impact analysis will consider how the internet infrastructure, particularly the DNS infrastructure has changed since 2012. Some of these effects may be attributed to privacy considerations, resolver aggregation and the availability of data overall.

    The discussion group is currently working with Office of the Chief Technology Officer (OCTO) to develop a detailed cost proposal and budget taking into consideration these alternations to Studies 2 and 3 that will be put forth before the Committee for consideration. Despite the proposed alterations, the NCAP discussion group maintains that most of the questions posed by the 2017 NCAP Board resolution will be answered with the revised Study 2. There will be a couple questions, specifically related to mitigation strategies that will be more directly addressed as part of Study 3. Following the NCAP update, James Galvin left the meeting.

  2. Action Items Review – The Committee Chair established the agenda for the meeting, reviewed the open action items and addressed the following:

    • OCTO to prepare a new Board paper on NCAP that takes into consideration the Committee's input and provide it to the Committee to make a recommendation to the Board – this item has been completed.
    • OCTO to continue researching New IP and provide the Committee with periodic updates – OCTO has published a full report on New IP and will report back if there are any updates; this item is completed.
    • The Committee to review the summary and analysis of public comments on the Proposal for Future Root Zone KSK Rollovers and consider possible recommendations to be summitted to the Board for further consideration – this item is completed.
    • OCTO to publish a high-level summary of the ICANN Managed Root Server (IMRS) strategy – OCTO has published a new version of the IMRS strategy which includes a study on IMRS single placement; this item is completed.
  3. Next Steps for NCAP – The Committee engaged in a discussion on whether the original questions posed by the 2017 NCAP Board resolution should be revised given the alterations that will be made to Studies 2 and 3. Committee members offered general support that the original questions are still valid and should remain unchanged but that emphasis should be placed on answering questions 7 and 8.

    • Action Item:

      • Matt Larson and OCTO to prepare a revised Board paper to state 1) the Committee agrees that the questions posed by the 2017 NCAP Board resolution are still relevant, but should highlight the ones related to the criteria for determining collision strings, namely questions 7 and 8; and 2) ask the Committee to continue its work on scoping and costing for Study 2.
  4. Priority Project Updates – The Committee received an update on the following projects:

    Root Server System Governance Working Group (RSS-GWG): The RSS-GWG has set up a cadence of calls for the RSS-GWG Board Caucus group. ICANN org continues its internal coordination to support the RSS-GWG. The RSS-GWG will present its next report to the Committee following discussions with the Board Caucus group.

    ICANN Managed Root Server (IMRS): OCTO published the high-level IMRS strategy paper which includes a section devoted to hyperlocal strategy. The strategy paper is currently available for public comment.

    Root Zone Management (RZM) Evolution Project: the IANA Stewardship Transition Coordination Group (ICG) for the IANA transition called for a study to examine the root zone management process and look for single points of failure in an effort to offer recommendations on how to reduce and/or eliminate these failures. ICANN org is in the final stages of the Request for Proposal (RFP) to engage a contractor to conduct the study. Given the current climate and the difficulty in interviewing people face-to-face, the study may take up to a year to complete rather than the six month that was originally anticipated.

    Domain Name System Security Facilitation Initiative (DSFI) Technical Study Group: The DSFI Technical Study Group has been meeting consistently every two weeks. The group has also reached a point where hourly meetings are no longer sufficient and has decided that in addition to its regular meetings, to also meet on a monthly basis for a three-hour block. The work is progressing well, and the group is looking at various attacks that the members know about that occured in recent history in an effort to answer the five questions that were posed in the charter document.

  5. Briefing on the Next Root Zone Key Signing Key (KSK) Ceremony – Kim Davies, the VP for IANA Services provided the Committee with an update on the preparations for the next KSK ceremony. In February 2020, ICANN org held its Q1 KSK ceremony roughly as planned. COVID did not affect anyone's travel at the time since it was before any personal protection mandates took place. The next scheduled ceremony was in April 2020 which was severely impacted by COVID. As a result, ICANN org settled on a configuration where the ceremony was running with limited personnel; the bare minimum of seven people instead of roughly 30 from all around the world. Remote participation was encouraged as much as possible and ICANN org provided additional access through zoom to people that would typically be in the room face-to-face. The remaining observers were following along with YouTube. During the course of the ceremony, there was someone walking around with an iPad on Zoom, getting up close to elements within the room so that community members and the trusted community representatives (TCRs) could see up close what was happening. The other change that took place as a result of COVID was instead of generating a one quarter of signatures, ICANN org generated three quarters. The additional signatures gave ICANN org the benefit of not having to hold any further KSK ceremonies in 2020 and provides ICANN org with signature coverage for the root zone all the way up to March 2021.

    The current assessment regarding KSK ceremonies for 2021 is one needs to be held. According to ICANN org's standard practices, it is usually in the middle of the previous quarter, so it would be mid-February that would be targeted as a rough date. While the situation around COVID is much clearer than last year, the climate is still not conducive to normal operations, particularly since international travel is severely impacted. Given these ceremonies are held in close quarters and people need to be near each other for an extended period of time, there is a significant risk for transmission. As such, given the current situation, ICANN org does not believe that it can resume normal ceremony operations in time for February 2021.

    The current plans for the next KSK ceremony are to follow the same set of options that were presented to the Board in early 2020 which involved a graduated set of options. The KSK team will be reviewing these options at the end of the month to make a decision on which option fits best with current circumstances. At the moment, option C, the same option that was selected in the last KSK ceremony appears to work best. Option C means ICANN org would hold a KSK ceremony in February 2021 much like the one held in April 2020. It would only consist of staff that are physically participating in the ceremony. While the February 2021 ceremony won't differ significantly from the April 2020 ceremony, there will be some slight improvements such as additional precautions around key transit as well as allowing participation by additional. The ceremony would be held in Los Angeles to avoid any international travel. ICANN org would again generate three quarters of signatures which would bring the signatures through the fourth quarter of 2021. The choice to collect three quarters worth of signatures was based on factors including the availability of a COVID vaccine and the additional time needed to prepare the East Coast facility for an in-person ceremony. The objective is to hold an in-person ceremony around November of 2021 in Culpeper, Virginia.

    The plan for the upcoming KSK ceremony has been shared with the TCRs and received positive feedback. Kim Davies then engaged in a discussion with the Committee on the need to prepare an additional resolution confirming the continuation of the contingency plan for the upcoming KSK ceremony.

    • Action Item:

      • ICANN org to prepare a draft Board resolution to continue to take all necessary steps to perform the KSK ceremony as provided in contingency plans.
  6. Updates from Technical Liaisons – The Committee received an update from the following technical liaisons:

    SSAC (Merike Käo): The SSAC is reviewing the DNS abuse work from the DNS Abuse Working Party and continues to work on comments to the New gTLD Subsequent Procedures Draft Final Report. SSAC has also formed a working party around routing security and issues surrounding route hijacking and how it affects the DNS. The charter for the working party is being finalized and the SSAC Chair let the Address Supporting Organization (ASO) Chair know that this work is ongoing.

    RSSAC (Kaveh Ranjbar): RSSAC is busy with the RSSAC Work Plan and planning for the work that is ahead in the coming year. This month, Steve Crocker joined the RSSAC Caucus and began commenting on some of the work items.

    Internet Engineering Task Force (IETF) (Harald Alvestrand): No new updates.

The Chair called the meeting to a close.

Published on 20 January 2021

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."