Dear TPR Working Group, Please find below the notes and action items from today’s TPR meeting on Tuesday, 03 August 2021 at 16:00 UTC. The next meeting will be Tuesday, 10 August at 16:00 UTC. Best regards, Emily, Caitlin, Berry, and Julie -- Action Items ACTION ITEM: WG members to provide comments in the Auth-Info Codes Working Document on the draft recommendations 1 and 2 (page 2), and the Small Team principles (start at page 8) and strawman list (start at page 10) at: https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0A... [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPof...>. Notes: Transfer Policy Review Phase 1 - Meeting #11 Proposed Agenda Tuesday 03 August at 16.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (5 minutes) 3. Continued discussion of Auth-Info Codes (75 minutes): Focus on Small Group Outcomes beginning on page 8: https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0A... [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPof...>. Poll Results: 1. The registrar creates the TAC and it is hashed at the registry. (17 responses) * Support as requirement -- 88% * Support as industry practice -- 12% * Do not support -- 0% 1. It’s not stored at the registrar and it is stored at the registry [but it only exists at the registry when the transfer is in progress]. (18 responses) * Support as requirement -- 22% * Support as industry practice -- 39% * Do not support -- 39% Discussion: * Some voted “no support” as needing more discussion, particularly about implementation. * Some concepts of not storing it – there are some reasons that would change that. * Second part of this was interesting – gets back to one of the questions the Small Group came up with as to whether there are other reasons for which people are using the Auth-Info code today. * Language is misleading. It should be in the registry and if it is it should be hashed. Agree with storing it only during the transfer process. * Could split this up into multiple concepts. * Problem for reseller registrars if they can’t store it. 1. Two-factor authentication, by whatever means the registrar sees fit. (21 responses) * Support as requirement -- 24% * Support as industry practice -- 57% * Do not support -- 19% Discussion: * Change to “industry standard, or optional” since industry standards can be mandates. Some registrars might not be able to follow the standard. * Don’t think we should use the wording “two-factor authentication” as it could be misleading in future. Change to “AuthID needs to be transferred to the registry in a secure manner.” * “Secure manner” is too vague. * The idea of two-factor on the system level is tricky – don’t think that is what we are suggesting. * When it comes to the security that is required to make things safe it should be completely up to the registrar, so it should not be a requirement. Technology will change very quickly, so what works now may be obsolete in a couple of years. Industry practices also will dictate. * How to handle it if it’s not written in policy? * If you put specifics into the requirements then you will allow a registrar to put those in. If you leave it up to industry practices then it isn’t part of the ICANN requirements. * “Secure Mechanism” is in the current Transfer Policy and is defined. * The Transfer Policy with respect to Change of Registrant uses the term "secure mechanism" and defines it in implementation notes as: Secure Mechanism: The policy recommendations by the GNSO recognize that some flexibility is required in how registrars process a Change of Registrant. As a non-limiting example, Registrars may want to consider "out of band" authentication based on information that cannot be learned from within the registrar account or publicly available resources such as Whois. Examples may include, but are not limited to: * sending an email requiring an affirmative response through a tool-based authentication method such as providing a unique code that must be returned in a manner designated by the Registrar; or * calling or sending an SMS to the Registered Name Holder's telephone number providing a unique code that must be returned in a manner designated by the Registrar; or * calling the Registered Name Holder's telephone number and requiring the Registered Name Holder to provide a unique code that was sent to the Registered Name Holder via web, email or postal mail. * Don’t try to define the specifics right now. * Think we should say state of the art secure authentication technology which is at the moment multi factor authentication. * If reseller is getting the TAC from registrar, then giving it to registrant, then what is the issue here? It is still more secure if registrars are required to use 2FA before giving out a TAC. * If we are too broad and vague about concepts we are not really making policies here. 1. Minimum character count for the TAC. (18 responses) * Support as requirement -- 89% * Support as industry practice -- 0% * Do not support -- 11% Discussion: * Wonder how you develop a minimum character count for the TAC and when does it become obsolete. * How do we future proof this? For example, is 4-character enough to eliminate the FOA? Should be a minimum. Hard to set the maximum. * Not sure that there is an industry standard. There are several. * Nice to have a minimum and maximum to be able to do a quick validation. * What happens when the maximum is insecure? How do we change it? * 32 or any length ICANN may prescribe from time to time. * General agreement that a minimum could be set. Not get detailed but wording should support flexibility. 1. Require uppercase and lowercase letters, numbers, and special characters. Prohibit use of dictionary words. (20 responses) * Support as requirement -- 65% * Support as industry practice -- 35% * Do not support -- 0% Discussion: * Seems to be support for making this at least a good practice or a requirement. * The Small Team wanted to ensure further uniqueness of the string. Avoid a password that is “123…”. * Making say “restricted words” instead of “dictionary words”? * If you say, “don’t do dictionary” then you have to check against a dictionary. It’s tough because you have to decide whose dictionary it is; requirements could change between registrars. * This concept should be encouraged, but I do not see how a requirement could realistically be drafted or enforced * Could look to NIST standards. 1. Registry check to ensure TAC meets minimum requirements. (16 responses) * Support as requirement -- 75% * Support as industry practice -- 13% * Do not support -- 13% Discussion: * Seems like the check should be done at the registry before sending over to the registry. * The thought was to discourage fringe registrar actors from not doing what they are supposed to do. Could be just a syntax check. * The registry would be the location of central enforcement logically... it would happen at the registrar due to it being a registry requirement. * Skeptical that registries should provide oversight … we don’t want police registries … * Registries to validate that the TAC matches requirements. Like, some checks and balances? * it depends on what we mean by ensuring TAC meets minimum requirements… 1. Failed attempt identification/notification after a certain number of requests to initiate a transfer. (17 responses) * Support as requirement -- 76% * Support as industry practice -- 18% * Do not support -- 6% Discussion: * Good support for requirement or industry practice. * Don’t support because not clear what the failed attempts should be. * This needs to be fleshed out. * Could see how it could be useful, but not as a requirement. * What if the registry tracked it and just alerted the registrar when the threshold is met – optional for the registrar to do it. * Registrar should be able to set up its own threshold and notification system – total control over the number of attempts. * Good option since a registrar wouldn’t be able to see attacks on domains registered to us. * Seems like a good idea, but think about whether it should be a requirement or practice. 1. Lock needs to be off for TAC to be requested/updated. (18 responses) * Support as requirement -- 39% * Support as industry practice -- 0 % * Do not support -- 61 % Discussion: * Not sure of the timing of when you get the Auth Code and when you release the lock. Why would you need to release the lock to get the Auth Code? * Don’t see why it would be a requirement to have it on or off. * Why not allow the flexibility? Why does it have to be on or off? * rather it be possible to keep the domain locked right up until the transfer itself gets initiated * concept on the lock use extending to code request was to add a layer of safety * Do get an Auth Code the lock don’t have to be off, but they do for the transfer to be executed. * The process should be standard across all registrars and registries, as to when locks must be on or off. 1. Maximum TTL for the TAC. (19 responses) * Support as requirement -- 79% * Support as industry practice -- 11% * Do not support -- 11% Discussion: * Majority supported as a requirement. * Need to think about the maximum TTL – would the registry be involved in enforcing it? * Note that the WG discussed this topic under Charter Question b4, for those referencing the document during the discussion * Should there be two questions? 1) should there be a TTL? 2) what should the maximum TTL be? * In the Small Team the majority accepted the concept of a TTL, but the details needed to be sorted out. * If there is a TTL but not a maximum, one could just set it for 10 years, which would not make sense. * Maximum helps to prevent registrars from keeping them for a long time. * If there is a maximum TTL you can avoid a lot of problems. * What the maximum is, is a good discussion. * There is also an inter-dependency within the Auth Code discussion itself related to a concept of there being no Authcode set and how that would work, plus the more meta discussions around bulk-transfer within this WG. * Auth TTL max/min interplays with those conceptually. 1. Minimum TTL for the TAC. (18 responses) * Support as requirement --83 % * Support as industry practice -- 11% * Do not support -- 6% Discussion: * General support for a minimum requirement. * As long as it possible to overwrite/invalidate it if it’s compromised then everything is good. * Definitely needs to be something in there that is something is hacked to ensure that the registrar can fix it – so don’t have the minimum as a requirement in the case of security breaches. Draft Recommendations: Draft Recommendation 1: The Working Group recommends that the Transfer Policy use the term “Transfer Authorization Code (TAC)” in place of the currently-used term “AuthInfo Code.” Draft Recommendation 2: The Working Group recommends that the Transfer Authorization Code be defined as follows: “A Transfer Authorization Code (TAC) is a code created by a Registrar to validate that a generic top-level domain (gTLD) transfer request is submitted by the authorized person. A TAC is required for a Registered Name Holder to transfer a domain name from one Registrar to another.” * WG members to review and comment. 4. AOB (5 minutes) - Next meeting: 10 August 2021 @ 16.00 UTC * Goal is to continue at the same time into September and beyond. * Staff will send out invites.