Dear TPR WG Members, Please find below the notes and action items from today’s call. The next TPR WG meeting will be in two weeks on Tuesday, 09 November at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items 1. ACTION ITEM: WG members to contribute to a list of additional security measures and provide other comments/suggestions in the Google doc for Additional Security Measures Working Document<https://docs.google.com/document/d/1q7xaJuxi50Q6TDD26H92P6wOfZ8luap1wdWOtIgk...>. Transfer Policy Review Phase 1 - Meeting #23 Tuesday 26 October 2021 at 17:30 UTC 1. Chair Update 2. About the PDP and Status Update (20 minutes) -- Slides attached * About the Transfer Policy: “ICANN consensus policy governing the procedure and requirements for registrants to transfer their domain names from one registrar to another.” * Formerly called the Inter‐Registrar Transfer Policy (IRTP) * Went into effect in November 2004 * GNSO reviewed the policy once before, shortly after implementation * Mission and Scope: PDP to conduct a holistic review of the Transfer Policy and determine if changes to the policy are needed to improve the ease, security, and efficacy of inter-registrar and inter-registrant transfers. * Conducted in 2 Phases under a single Charter<https://community.icann.org/display/TPRPDP/2.%2BWG%2BCharter> <https://community.icann.org/display/TPRPDP/2.%2BWG%2BCharter> & covering 8 topics. * PDP began Phase 1(a) in May 2021: * Phase 1(a) Topics: Forms of Authorization and AuthInfo Codes * The working group has now conducted initial deliberations on each of the Phase 1(a) topics and has begun to develop “candidate recommendations” and draft responses to charter questions. * While members and alternates are limited to representatives designated by SO/AC/SG/Cs, anyone can sign up to observe. * Topics: * AuthInfo Code Management * Gaining & Losing Registrar Form of Authorization (FOA) * FOA: Further Work Needed * EPDP included the workaround from the Temporary Specification in its recommendations, which were adopted by the ICANN Board. * Registrars identified challenges in ICANN org’s position that a Gaining Registrar is required to send a Gaining FOA where the email address “is available”, as there is no guarantee that the email goes directly to the registrant. * ICANN Board passed a resolution to defer contractual compliance enforcement of the Gaining FOA requirement pending further work in this area. * Contracted Party House Tech Ops Subcommittee has developed a proposal for a proposed transfer process. * Status: Potential Recommendations Under Consideration * Eliminate requirement for the Gaining Registrar to send the Gaining FOA and obtain consent from the Registered Name Holder before it may proceed with the transfer. * Eliminate requirement for the Losing Registrar to send the Losing FOA to the Registered Name Holder. * New notifications from the Losing Registrar to the Registered Name Holder when key changes are made to the account, some mandatory for the Losing Registrar to send, others optional. * Additional security for the AuthInfo Code, which the group is recommending be called the “Transfer Authorization Code” (TAC). Highlights: * ➔ Minimum requirements for TAC syntax/complexity, adherence to requirements confirmed by registry * ➔ Losing Registrar generates TAC upon request * ➔ TAC may only be used once * ➔ TAC is valid for a limited period of time (Time to Live) * ➔ Registry must securely store the TAC using a one-way hash that protects the TAC from disclosure * After the WG has reviewed the elements relating to single transfers, the WG will consider issues relating to bulk transfers. 3. Deliberations on Additional Security Measures (60 minutes) -- see: Additional Security Measures working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1q7xaJuxi50Q6T...> Overview: * Staff and leadership developed a chart of an overview of inter-registrar transfer locks following last week’s discussion. * To help everyone understand what locks we are talking about. * Where we are unsure of the origin of a lock staff has inserted an asterisk (*). * Looking for feedback to make sure this is complete and accurate. Discussion: * A lot of registrars apply locks by default to protect against unauthorized transfers. * Not all domain locking is an additional security measure – whether it prevents hijacking depends on good account security – it is a dependency. If you lose control of the account it doesn’t matter if there is a lock or not. Need to capture these details. * The key is if we say that there is a mandatory lock and if someone gets ahold of someone’s account, it doesn’t matter since it can’t be transferred for 60 days. It becomes a more difficult hack if you have to hack both the registrar and registry accounts. * The concern with these stated security features is that there is a relationship between them – we need to capture and recognize that. Challenging to talk about them in isolation. * Question: What do the asterisks mean? Answer: It denotes uncertainty on the staff support side as to the origin of a lock – indicating that the origin is a guess. * First row: If this lock that many registrars do upon creation: the charter question a6 is whether this should be mandatory or just allowed as it is today. Leaning towards keeping it optional, but focusing on trying to keep it as consistent as possible across registrars. * Is there an opportunity to get more information about the impact/concerns relating to inconsistency of application of locks? * The charter question being specific to this first row – seems that we have answered that, but we need to resolve the 60-day creation. * “Lock means a set of measures that a registrar applies to a domain name, which prevents at a minimum any modification to the registrant and registrar information by the Respondent, but does not affect the resolution of the domain name or the renewal of the domain name. (UDRP Rules, Section 1)” * The UDRP lock is different than EPP code clientTransferProhibited (which can allow change of registrant info). * There is an issue that some registrars may be imposing a UDRP lock that also locks the nameservers in place, which can prevent removal of allegedly infringing content etc. * Question: Any ideas on additional security measure we could be doing to improve this? Should we put in requirements around registrar and registry locks? * Question: Is this a place where people want to talk about multi-factor authentication? Answer: Not sure we want to include this in our policy. * Question: Is there a multi-factor piece of transfers that is possible? * We shouldn’t make assumptions about any one feature because they do have dependencies. * Multi-factor authentication is a security feature and if it is present it may help. We could note that it may or may not be present, and we could say something about it if it is present in transfers. We can mention that it adds to the security features if it is present. Different registrar models have different use cases for multi-factor authentication. * Should not make it too difficult for a registrar to do it if it wishes to use MFA. * In terms of scope and deliberation on additional security measures as they relate to transfer policy is in scope, although it might not be a consensus policy. Looking at the WG Guidelines there is nothing that would prevent the WG from providing implementation guidance. Perhaps there is language that is not consensus policy but could help the implementers. * What we could consider doing is for it to be allowed to have MFA on the TAC, but not on other actions. That would be in scope. * It’s important that we put boundaries on either side of this – can’t make it too easy to transfer a domain name but also can’t make it too hard. * Steinar Grøtterød-TPR Member (At-Large) to Everyone (2:46 PM): <COMMENT> I am in favor or adding wording that describes a requirement for registrars to make access to their control panel in a secure way. Of importance is also the distribution of the TAC to the Registrant/DNH. I find it strange that 2FA is enabled for accessing a control panel and then the TAC is sent in unsecured way (email).<COMMENT> * Question: Should we brainstorm a list of security measures? * Shouldn’t be prescriptive on the mechanism. ACTION ITEM: WG members to contribute to a list of additional security measures and provide other comments/suggestions in the Google doc for Additional Security Measures Working Document<https://docs.google.com/document/d/1q7xaJuxi50Q6TDD26H92P6wOfZ8luap1wdWOtIgk...>. 4. AOB (5 minutes) * Next meeting: In two weeks on Tuesday, 9 November 2021 at 16:00 UTC (no meeting next week).