ICANN79 Meeting:

ICANN79 Prep Week Session: Name Collision Analysis Project Study 2 Update

Why NCAP?

2017: ICANN Board tasked SSAC to conduct studies to present data, analysis and points of view, and provide advice to the Board on name collisions

• Specific advice regarding .home/.corp/.mail
• General advice regarding name collisions going forward

SSACs analysis and recommendations

1. Provide means to preserve security & stability of the internet namespace
2. Analyze real-life impact of name collisions and rationale to take this seriously
3. Directly impact next TLD round

Findings:

Finding 4.1 - The definition of what is a name collision has evolved over time

Finding 4.2 - Name Collision Identification and Quantification
 4.2.1 - Name collisions continue to persist within the DNS
 4.2.2 - There are limitations with using currently available data sources for understanding root cause and risk, or designing mitigation and remediation plans
 4.2.3 - .CORP and .HOME demonstrated that high volume is an insufficient measure for analyzing the potential of high-risk impact
 4.2.4 - It is possible that future name collisions may occur on the scale of .CORP, .HOME, and .MAIL
 4.2.5 - It is impractical to create a do-not-apply list of strings in advance of new requests for delegation

Finding 4.3 - Data Manipulation Risks
 4.3.1 - There is a risk for CDM (Critical Diagnostic Measurements) data manipulation
 4.3.2 - Data manipulation has ramifications beyond the technical aspects of name collision that are influenced by when analysis occurs

Finding 4.4 - Quantitative and Qualitative Measurement Considerations
 4.4.1 - Critical Diagnostic Measurements are structurally quantitative and benefit from supplemental qualitative information
 4.4.2 - The quantitative data in CDMs can be improved

Finding 4.5 - Notification to users of name collisions is a critical function and separate from assessment or remediation
 4.5.1 - Controlled Interruption as a notification method is effective in some but not all instances
 4.5.2 - Other methods for notification may be used but remain untested.
 4.5.2 -  The criteria for the use of ICANN's name collision reporting form negatively impacted its use

Finding 4.6 - Predicting the rate and scale of change in the root zone is not possible in advance of a new round of gTLDs

Finding 4.7 - There is no process for emergency changes to the root zone when considering the temporary delegation of strings

Finding 4.8 - The adoption of IPv6 has grown significantly since 2012

Finding 4.9 - Reserved private-use strings may mitigate the risk of name collisions over the long term but not the short term.

Recommendations:

Recommendation 1 - ICANN should treat name collisions as a risk management problem.

Recommendation 2 - ICANN should adopt a consistent definition for name collision

Recommendation 3 - ICANN should continue its education and outreach efforts to the community on the name-collision topic

Recommendation 4 - ICANN should consider the need for mitigation and remediation efforts for high-risk strings
 4.1 - ICANN should submit .CORP, .HOME, and .MAIL through the Name Collision Risk Assessment Process

Recommendation 5 - ICANN must support the delegation of strings in order to improve the ability to conduct a name collision risk assessment

Recommendation 6 - ICANN should establish and maintain a longitudinal DNS name collision repository in order to facilitate risk assessments and help identify potential data manipulation

Recommendation 7 - ICANN should establish a dedicated Technical Review Team function

Recommendation 8 - ICANN should replace the existing Name Collision Management Framework with the recommended Name Collision Risk Assessment Framework
 8.1 - ICANN should not reject a TLD solely based on the volume of name collisions
 8.2 - ICANN should request special attention to strings with high-impact risks during the name collision assessment process
 8.3 - ICANN should update its public-facing name collision reporting process

Recommendation 9 - ICANN should create a Collision String List
 9.1 - ICANN should support a mechanism that allows applicants to request a string be removed from the Collision String List

Recommendation 10 - ICANN must develop and document a process for the emergency change related to a temporarily delegated string from the root zone due to collision risk or harms

Recommendation 11 - ICANN should not move ahead with NCAP Study 3

Publications:

SAC123: Report on the Evolution of Internet Name Resolution   

Some key aspects:

• Internet name resolution is evolving beyond just the global DNS to include alternative naming systems that are experimenting with different approaches for reasons like speed, privacy, censorship resistance, and governance.
• Many alternative systems adopt DNS name syntax to leverage existing software.
• Two concerning trends are increased ambiguity where the same name can resolve differently in different systems, and less visibility of names to end users even as names remain vital for security and trust.
• Maintaining integrity and coordination in the shared domain namespace is important.
• The report explores different perspectives on these trends from end users and developers.
• It identifies proposals to facilitate namespace coordination and recommends ICANN continue tracking these issues and provide regular updates to the community.

7.1 End Users (some key aspects):

• • Domain names used to play an important role for end users in discovering web resources, but search engines have now replaced them as the primary method of discovery.
  • End users today rarely directly interact with domain names due to the dominance of search engines and mobile devices. Features like browser "omnibars" also allow more free-form input.
  • Other identifiers like QR codes and social media handles now also compete for users' attention rather than domain names.
  • Domain names are becoming less visible in users' environments, yet they still provide an underlying ubiquitous resolution context relied upon by other technologies.
  • Surveys found search engines are by far the predominant method for accessing websites, with domain name usage declining. QR code usage is increasing but still limited except in Asia.
  • Decreased domain name visibility makes it easier for fraudsters to deceive users with lookalike names. Users are also generally unaware that some TLDs signal a different resolution context.
• In summary, domain names are no longer the primary method end users employ to find and access Internet resources, decreasing their visibility and understandability while introducing security issues.

SAC122: Report on Urgent Requests in the gTLD Registration Data Policy 

Some key aspects:

• Focus is on handling of Urgent Requests in proposed gTLD registration data policy
• Urgent Requests refer to imminent threats to life, injury, infrastructure or child exploitation
• Proposed policy requires response to Urgent Requests in 24 hours generally
• SSAC contends proposed policy for Urgent Requests is not fit for purpose
• Definition and required response times are incompatible
• Questions if need and rationale for separate Urgent Request process is fully justified
• Existing ICANN policy and industry practices offer useful precedents
• Proposed extensions allow responses up to 7 days, not reflecting urgency
• Lack of concrete data on frequency and handling of such requests currently
• Risks reputation of ICANN multistakeholder model effectiveness 

           Recommendations:

• • Add structure to ensure Urgent Requests handled expediently
  • Tighten response time requirements to be fit for purpose
  • Gather data on Urgent Requests for future policy making