Dear all,

Please find below the notes from today’s meeting on Thursday, 22 December 2022 at 13:30 UTC.

Kind regards,

Ariel, Steve, and Emily

Notes - IDNs EPDP Call – 22 December 2022

Action Items

None

Notes

Welcome and Chair Updates

• This is the last call of the year. Thanks to the EPDP Team members for their contributions and commitment.
• Today’s focus will be something new in the policy development context, a risk assessment exercise. This will be a subjective test and there is no defined outcome. All are encouraged to keep an open mind.
• James Caulfield from the ICANN org risk management function is joining this call, primarily to observe, but may be able to answer questions about risk assessment in general and to provide guidance in that regard.
• This is not the last time we will talk about the risk assessment. We will revisit this topic in the new year.

Risk Assessment - String Similarity Review

• Slide 4 – Why Risk Assessment?
• Slide 5 – Risk Assessment Overview
  • Purpose: Assess the inherent risk level of the two failure modes involving domains, understand whether the mitigation measures are commensurate with the risks, and assess the residual risk level after factoring in the mitigation measures
    • Inherent Risk: The level of natural level of risk without doing anything to reduce the likelihood or mitigate the severity 
    • Residual Risk: The amount of risk remaining after the inherent risks have been reduced by mitigation measures
  • The specific risks being assessed are: 
    • Risk 1: Denial of Service / No-Connection
    • Risk 2: Misconnection
  • Assess the Control Effectiveness, which reflects the effectiveness of mitigation measures. The mitigation measures being considered include two options: 
    • Option 1: String Similarity Review Hybrid Model 
    • Option 2: String Similarity Review Level 2 + String Confusion Objection Using the Hybrid Model
• Comment: The registrant is another stakeholder in this risk assessment. If two confusingly similar TLDs exist, this could be a vector for phishing, which impacts legitimate registrants.
• Question: Phishing happens on a regular basis. Would this be more of a problem in IDN gTLDs if the TLD itself is confusingly similar to another gTLD?
• Comment: Phishing is currently focused on second level registration under the same TLD. If the phishing is done through creating a confusingly similar TLD and then using the same string at the second level, the space for creating confusingly similar domain names increases.
• Reminder: The focus of this group’s assessment for the purpose of this analysis is the top level (TLD level).
• Slide 6 – How to Apply the Risk Assessment Model
• Slide 7 – Step 1: Describe Risks and Consequences
• Comment: people tend to mistakes in typing URLs, so QR codes are increasingly used. This example may be less relevant with time. It is worth thinking about how often people type in a URL and do not reach the intended website and think that the Internet is not working.
• Comment: The risk of no connection is a nuisance. The risk of misconnection is real and can erode trust. The damage can be significant, even if it is only discovered later that, for example, the user has been a victim of phishing.
• Comment: It would be helpful to have data on the prevalence of misconnection currently with ASCII (as there are not many IDN TLDs) and to think about whether we expect it will be worse with the introduction of more IDNs and with variants.
• Comment: It is hard to find relevant examples in currently available data.
• Slide 8-9 – Step 2: Assess Likelihood and Severity
• Comment: The level of likelihood depends on the gTLD itself. For example, it’s possible that one TLD is riskier than another because of how it is used. A version of .Doctor might be riskier, for example. This maybe another layer to consider.
• Response: This is a generalized way to assess across the board, as it is difficult to get so specific for the purposes of this exercise. For this exercise, we will focus on the possible new IDN gTLDs that may be introduced in the next round as a broad category.
• Comment: Another factor might be whether two potentially confusable strings are in the same script or in two different scripts.
• Comment: If we are trying to determine a rating for likelihood of confusion overall, it is a challenge. It’s hard to put all potential IDN gTLDs together in a bundle and look at collective likelihood. Maybe that is not the right way to look at it.
• Comment: Likelihood is probability. In order to make an assessment, you need statistics. Without numbers, you are making a guess. Policymaking should be based on facts.
• Response: We do have some data that was provided by ICANN org, but the specific data for the issue under discussion here is very difficult to obtain.
• Comment: Since the previous round, the community has looked at data and reduced the string similarity space by discovering things that are clearly confusable and are included as part of the variant sets.
• Comment: Likelihood is not the same as probability. Where there is not concrete data, you can base the analysis on professional judgment as part of risk assessment. The numbers are more about the descriptions than about a numerical score.
• Comment: Ultimately, this is a tool to help the group move forward on this issue. We don’t have absolute data, but we do have a decent amount of information about the issue space. If the group is not able to come to a conclusion on the issue, it is possible to put questions for community input in the Initial Report.
• Comment: Objections are based on a set of criteria. If this group decides to go with the hybrid model, the panel shouldn’t be influenced by other elements unless instructed to do so, for example the outcome of the string similarity review. That is not currently in the scope of what is anticipated for the String Confusion Objection.
• Comment: The group is leaning towards the hybrid model in deliberations. The result of those deliberations was based on professional judgement, not hard data. The purpose of this exercise is to help make sure that the group understands the risk that we are trying to mitigate. Using numbers helps the group talk the issue through, using the same professional judgement.
• Comment: Concern expressed by one IDN EPDP Team member about using this risk assessment approach without hard data.
• Comment: As a reminder, the EPDP Team agreed that it would be helpful to go through this exercise.
• Slide 10 – Step 3: Assess Control Effectiveness
• Slide 11 – Step 4: Pinpoint Risk Level in Risk Rating Matrix
• Comment: Regarding severity ratings (slide 9), we are starting to develop the building blocks for our process. We are looking at the range of possibilities in terms of consequences. On no connection or denial of service, these examples are not relevant. On misconnection, the consequence is usually negligible. It is possible that there could be more severe consequences in specific cases where there is malicious activity, but those numbers are likely much smaller.
• Response: Risk = Likelihood x Severity. If you think that something is not likely to happen, the risk may be minimal. But if it causes severe consequences in rare instances, the overall risk could still be high. It is important to look at all angles.
• Summary: The EPDP will return to this topic in the new year.

AOB

• Next call is 5 January 2023, starting half an hour earlier.