Dear TPR Working Group, Please find below the notes and action items from today’s TPR meeting. The next meeting will be Tuesday, 03 August at 16:00 UTC. Best regards, Emily, Caitlin, Berry, and Julie -- Action Items ACTION ITEM: Homework for WG members – add comments and suggested edits to the principles and strawman list at: https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0A... including anything that might be missing, clarifications/changes to terminology, impacts on use cases, etc. Also see the project workplan [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1FunWaz3gN...> for action items. Notes: Transfer Policy Review Phase 1 - Meeting #08 Proposed Agenda Tuesday 27 July at 16.00 UTC 1. Welcome & Chair updates 2. Presentation of outputs from the small group and continued discussion of Auth-Info Codes: See new section at the end of the Working Document (beginning on page 7): https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0A... [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPof...>. * Small Team has been meeting for the last two weeks on Auth-Info Codes. They will present their thoughts to us. There is some additional work that will need to happen in the full WG. * Project Plan was introduced to the GNSO Council at the meeting on 22 July. There were no questions from Council. Presentation from Jim Galvin on Principles: * “Transfer Authorization Code (TAC) is an Identity Credential that upon presentation by a registrant identifies that registrant as the owner of its corresponding domain name.” * This is very important and we should try to come to agreement on it. * “Should only exist at registry when a transfer is in progress”: * This suggests that regardless of when a registrar creates a TAC, it is not passed to the registry unless a transfer is in progress. * “Must be unique per registrant and per domain name”: * The value must be safe and secure and not reproducible outside of the registrar, i.e., one-time password. If there is a request for another one just generate a new password. * “Must not be retrievable from the registry”: * A registrar can set it but a registry will never respond with it, other than to validate if an accurate one was submitted (rate limits to avoid brute force). * A registrar would set a “NULL” or send new TAC to remove it from the registry or update the existing TAC. * “Registrars should manage any TTL scheme”: * Important principle that registrar is completely in control of the transfer process. * “SHOULD be updated at the registry upon completion of owner change process.”: * This is up for discussion. * Important part is the first principle: If you have this code you are the owner for the purpose of transfer. There was discussion on the Small Team about AuthInfo Codes for purposes other than transfers. Look at those to see if these purposes are still legitimate and if there’s another way to achieve the purpose. Presentation from Jody Kolker on the Strawman List: * The registrar creates Auth-Info code and it is hashed at the registry. * It’s not stored at the registrar and stored at the registry. * Discussed issues of how it would be stored if not at the registry. If the registrar doesn’t have the Auth-Info Code then it can’t prove identity. This is up for discussion. * Two-factor authentication, not necessarily using cell phone number, could be a security question. * Discussed that the registrant would have to have a second form of technology, such as a smart phone. * 32-character min [Alternative: 16 characters]. * This is what we wanted to get to. Aren’t there right now. * Require uppercase and lowercase letters, numbers, and special characters. Prohibit use of dictionary words. +Homoglyph consideration (0 vs O) see below.** * Discussed homoglyphs and said they shouldn’t be able to use those. * Registry check to ensure Auth-Code meets minimum requirements -- to discuss with the full group. * We would like them to check, but this needs to be discussed with the full WG. * Timeout after a certain number of requests to initiate a transfer. (Why: Adds integrity to legitimate xfer [slow manual incumbent, automated gaining process], guards against illegitimate [brute force]. What: ServerTransferLock at threshold x, notice to incumbent registrar, other) * This needs to be discussed. Not sure “timeout” is the right word. This would require work by the registry to alert the registrar. * Can Transfer Lock status affect requesting/updating auth code in addition to just blocking a transfer request? * There are open questions on a lot of these. Discussion: * Seems that there are two competing factors: 1) is the Auth-Info Code strong enough? 2) is it useable? In pushing for very long strings and raising the prospect that these will have to be typed by hand (not copied) this would cause errors. Both considerations should be included. For example, you could have 16-characters broken into groups of 4. * Small Team was thinking about how to be secure and still make it useable. If it is too secure it may not be usable, but too usable it may not be secure. * Need to ask ourselves how many entities in between do we want to have access to the Auth-Info Codes – resellers? Other service providers? Or only allow directly to the registrant. Need to decide this first before other questions. * Don’t think we can say “no storage” but need to set parameters around storage. * When we talk about two-step authentication, we need to talk about when that is appropriate. The two-step now is at the registrar panel. There is no two-step after getting the Auth-Info Code. * The most important point is the discussion about the ecosystems outside of the registrars and registries. They are outside the ICANN contracts. They are using a chain of resellers. So there are questions about storage of the Auth-Info Code. They might be stored and retrieved many times by many people. Second, if we make technical difficulties in accessing the code we will lose many people. * Need to come up with good practice around storing and keeping it safe. * The registrar creates Auth-Info code and it is hashed at the registry. * It's not stored at the registrar and stored at the registry. * Two-factor authentication, not necessarily using cell phone number, could be a security question. * 32 character min [Alternative: 16 characters]. * Require uppercase and lowercase letters, numbers, and special characters. Prohibit use of dictionary words. +Homoglyph consideration (0 vs O) see below.** * Registry check to ensure Auth-Code meets minimum requirements -- to discuss with the full group. * Timeout after a certain number of requests to initiate a transfer. (Why: Adds integrity to legitimate xfer [slow manual incumbent, automated gaining process], guards against illegitimate [brute force]. What: ServerTransferLock at threshold x, notice to incumbent registrar, other) * Can Transfer Lock status affect requesting/updating auth code in addition to just blocking a transfer request? * Bulk transfers could be an issue, but this WG could work on alternatives/solutions. * On multifactor authentication and locking the domain name: Issue is that a lot of us already offer MFA, but user adoption is very low. Have to consider how to encourage adoption. Could require increased support. * On transfer lock needing to be removed before a transfer: what we see is that resellers or their customers they turn it on and off for no obvious reason. Some resellers turn it off as a default. Lot of use cases regarding when a transfer lock is present or not. * This is more of a timing issue: should you be able to receive an Auth-Info Code when a lock is on it. * The transfer lock being on might impact whether you can request an Auth-Info Code from the registrar. * Re: the second principle (comment from Sarah Wyld): “How does the losing Rr know when to send the TAC to the Ry? E.g. RNH unlocks domain on Monday; on Tuesday they obtain the authcode from the Rr (how? by viewing it in CP? clicking a button that triggers it to be emailed to them? Some of this is known to the Rr and some is not). On Friday they go to the gaining Rr to initiate the transfer, including providing the authcode to them. At what point was the losing Rr supposed to send the authcode to the Ry? If the code is always existing in the Rr system and always visible to the RNH via their CP, nothing notifies the losing Rr that the transfer is being initiated until it's already happened.” * This doesn’t seem to align with the second item on the strawman list: * When the transfer request has started, when the TAC is provided to the registrant that’s when it is stored at the registry. * In a lot of different provider control panels the Auth-Info Code is always visible. We would change that to only seeing it when the registrant requests one. Yes, the intent of the principle is that the TAC is only viewable when the registrant requests it. * A larger point to keep in mind is that this a proposal and it doesn’t match 100 percent what everyone is doing now. Need to highlight points of use that might be impacted by the principles/strawman. Some people may need to change some things to align with the principles. Question: do these principles conflict with where you are that would make you want to seek a different solution? * We could improve security if the Auth-Info code only exists for a limited period of time, is a one-time password with a TTL, and handled in the registry system, not the registrars. * Auth-Info Code is used for transfers between resellers at the same registrar. * Keep in mind that although we are talking about Auth-Info Codes in isolation, this leads into the discussion on gaining and losing FOAs. * Primary principle: If someone has this code then someone can transfer it. Need to look at all these items and what is missing in between as well as other uses. * Comment: Need to look at what is going on at the gaining and losing registrar, and what is going on at the registry, and the user interface in each instance. These principles may not be 100-percent aligned, but we tried to gather up the ideas and put them on the table for the WG. * Staff did some digging to see what diagrams we have on the current process, but some of what we have is not up-to-date. Staff could try to update it to develop a working draft reflecting the current state. What might be most useful is after we formulate recommendations that we then develop a diagram to reflect those. * Not sure if going back to all the use cases is a good way to spend our time. Instead make sure that we put out our goals and make sure that our language around those goals are technology and policy agnostic, so there is enough room for all registrars to achieve those goals without limiting use cases. * Might be helpful to have some data - high level - on what the things are that registrants complain about … as mentioned earlier, there is a use sophistication hurdle that might taint that info. * One thing that came up in the Small Team’s discussion is that there are pieces that are going to be interdependent. Such as bulk-type transfers. There are real-world scenarios where someone might be consolidating domain names. We may need to talk about whether that use case is or isn’t covered. * Goal between now and the next call is to look at the principles and strawman and add their ideas/comments and how use cases may be impacted. * Re: second principle: suggest changing to “Should only exist at registry when a transfer is [eligible to be] in progress”. New text in brackets. * Re: TTL – could have registrar manage minimum and registry manage maximum; or registrar could manage TTL or registry could manage it. Could be more manageable with the fewer parties that are doing it. * The TTL should be allowed be very short for high value domains, but it should not be common to set to 15 minutes. * A TTL should have a minimum value no less than 1-2 days. Would not want a sticky registrar to set it to 5 minutes. * Looking across registrars, the transfer lock is guarding the name. * Re: TTL could see that a registrar could set the TTL low to make it hard for a registrant to transfer. There would have to be some kind of minimum. * On this issue of whether there should be a TTL at the registry and enforced there. Need to change the way we are thinking about this: What is it we are trying to achieve, what is the goal, and who benefits? What is the security feature we get with one approach or another? If the registry controls TTL then the registrar loses control. Also, the registry can just turn it off and the registrar will get the customer service issue. Focus less on the failure points, and on what is the benefit in terms of security that the registrant gets? * Most important to decide whether to have a TTL on the Auth ID. Registry can only validate the Auth ID based on whether it’s expired or now and so that Auth ID needs to be in the registry. * If we think TTL is a needed feature – seems most agree that there should be an upper and lower limit; we should set those bounds. * If we set a TTL we always place some part of the risk with the registrant, such as registrar failure, reseller failure, etc. * The domain name has to be unlocked at the registry. If the registrar fails then the domain name can’t be transferred. If the registrar has the domain name locked, then there is no way to transfer. * It’s not actually true that if you have the Auth-Info Code you can transfer, you can’t if the registrar has locked the name. Once an Auth-Info code is set at the registry then the locks have to come off. * Seems agreement that we should have TTLs with a maximum and minimum but have not agreed on the management of the TTL. * Possible new principle: Be sure that we can override the TTL with an Auth-Info Code. Need to be able to invalidate it. ACTION ITEM: Homework for WG members – add comments and suggested edits to the principles and strawman list at: https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0A... including anything that might be missing, clarifications/changes to terminology, impacts on use cases, etc. 3. AOB (5 minutes) - Next meeting: 3 August 2021 @ 16.00 UTC