Page History
...
Info |
---|
PROPOSED AGENDA
4. Deliberations on Additional Security Measures (15 minutes, time permitting) 5. AOB (5 minutes)
BACKGROUND DOCUMENTS |
Info | ||
---|---|---|
| ||
GNSO transcripts are located on the GNSO Calendar |
Tip | ||
---|---|---|
| ||
Apologies: Crystal Ondo (RrSG) Alternates: Essie Musailov (RrSG) |
Note |
---|
Notes/ Action Items
Action Items
Transfer Policy Review Phase 1 - Meeting #21 Tuesday 12 October 2021 at 16:00 UTC
- Jim Galvin will soon be occupying a new role: I have been selected to be SSAC’s liaison to the ICANN Board of Directors, a role that I will assume at the AGM. It won’t change my role on the WG as I will continue to represent the Registry Stakeholder Group. See: 2. Welcome & Chair updates (5 minutes)
ACTION ITEM: WG members should review the Gaining and Losing GOA working documents – including candidate recommendations for the Losing FOA and suggested changes to the Gaining FOA policy. See: Gaining FOA working document [docs.google.com] and Losing FOA working document [docs.google.com]. 3. Review of draft responses to charter questions and candidate recommendations for AuthInfo Codes – see end of document beginning on page 16 (60 minutes) at: AuthInfo Codes working document [docs.google.com] Discussion: Charter Question b1) Is AuthInfo Code still a secure method for inter-registrar transfers? What evidence was used by the Working Group to make this determination? Candidate 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 of Record to validate that a request to transfer a domain name in a generic top-level domain (gTLD) is submitted by the authorized person, which may be the RNH or another appropriate party. The individual demonstrates that they are the authorized person by providing the TAC. A TAC is required for a Registered Name Holder to transfer a domain name to be transferred from one Registrar to another.”
Candidate Recommendation 6: [The Working Group recommends that the Registry notifies the Registrar of Record [and registrant] receive a notification after [number] failed attempts to enter the TAC. The Registrar of Record may subsequently also provide a notification to the registrant that these failed attempts have taken place. ICANN Org may change from time to time the number of failed attempts that trigger a notification.] OR [The Working Group recommends that after [number] failed attempts to enter the TAC, it is not possible to attempt a transfer for [period of time]. ICANN Org may change from time to time the number of failed attempts that trigger this result.].
Charter Question b2) The registrar is currently the authoritative holder of the AuthInfo Code. Should this be maintained, or should the registry be the authoritative AuthInfo Code holder? Why? Candidate Recommendation 7: The Working Group recommends that the registrar continue to own and generate the TAC. The Working Group further recommends that the TAC is only generated by the Registrar of Record upon request by the registrant. When the registrar provides the TAC to the registrant it should also provide information about when the TAC will expire.
Candidate Recommendation 8: The Working Group recommends that when the registry receives the TAC, the registry must securely store the TAC using a one-way hash that protects the TAC from disclosure by using a secure password-hashing function (for example, bcrypt).
Candidate Recommendation 9: The Working Group confirms the following provision of Appendix G: Supplemental Procedures to the Transfer Policy contained in the Temporary Specification for gTLD Registration Data: “4. Registry Operator MUST verify that the "AuthInfo" code provided by the Gaining Registrar is valid in order to accept an inter-registrar transfer request.”
Charter Question b3) The Transfer Policy currently requires registrars to provide the AuthInfo Code to the registrant within five [calendar] days of a request. Is this an appropriate SLA for the registrar’s provision of the AuthInfo Code, or does it need to be updated?
ACTION ITEM: Staff to incorporate a recommendation to retain this policy with change from days to hours.
Charter Question b4) The Transfer Policy does not currently require a standard Time to Live (TTL) for the AuthInfo Code. Should there be a standard Time To Live (TTL) for the AuthInfo Code? In other words, should the AuthInfo Code expire after a certain amount of time (hours, calendar days, etc.)?
Candidate Recommendation 10: The Working Group recommends that the Transfer Policy include a standard maximum Time To Live (TTL) for the TAC of [14 days]. Candidate Recommendation 11: The Working Group recommends that the Transfer Policy include a standard minimum Time To Live (TTL) for the TAC of [period].
b5) Should the ability for registrants to request AuthInfo Codes in bulk be streamlined and codified? If so, should additional security measures be considered?
ACTION ITEM: WG members to provide their input as suggestions in the AuthInfo Code Candidate Recommendations at: AuthInfo Codes working document [docs.google.com]. 4. Deliberations on Additional Security Measures (15 minutes, time permitting) – see: Additional Security Measures working document [docs.google.com] ACTION ITEM: WG members to review and comment on the Additional Security Measures working document [docs.google.com] in preparation for the discussion during the next WG meeting on 19 October.
This is the related charter question: “a6) Survey respondents noted that mandatory domain name locking is an additional security enhancement to prevent domain name hijacking and improper domain name transfers. The Transfer Policy does not currently require mandatory domain name locking; it allows a registrar to NACK an inter-registrar transfer if the inter-registrar transfer was requested within 60 days of the domain name’s creation date as shown in the registry RDDS record for the domain name or if the domain name is within 60 days after being transferred. Is mandatory domain name locking an additional requirement the Working Group believes should be added to the Transfer Policy?” 5. AOB (5 minutes)
|
Note |
Notes/ Action Items |