[GNSO-TPR] Notes and action items - TPR WG Meeting #47 - 17 May 2022 at 16:00 UTC

Tue May 17 23:04:07 UTC 2022

Dear TPR WG members,

Please find below the notes and action items from today’s meeting.

The next meeting will be Tuesday, 24 May 2022 at 16:00 UTC.

Best regards,

Emily, Julie, Berry, and Caitlin

Action Items

🚨 1. Working Group members who haven’t yet done so: please review the Phase 1(a) Initial Report draft (attached) and indicate what changes/updates are essential before the Initial Report can be published by using the dedicated Google Doc<https://docs.google.com/document/d/1s9xumJ1XBPdTb7kQmc5sAC2AkszvfAF0freMvnx6G18/edit> by Friday, 20 May. 🚨

Transfer Policy Review Phase 1 - Meeting #47
Proposed Agenda
17 May 2022

  1.  Roll Call & SOI updates
  2.  Welcome and Chair Updates
           *   Policy Support Staff sent out a survey, asking which members will be attending ICANN74 in person
           *   This is in order to guarantee access to the Transfer Policy Review PDP session room and a seat at the U-shaped table during ICANN74, you will need to please complete the survey to confirm if you are attending on-site and taking part in this session by Wednesday, 18 May 2022.
           *   Survey: https://forms.gle/ngWUUutRpaF87uJD8
           *   Please take five minutes to fill out this survey. If you are not planning to attend, you can answer “no” to the first question.
           *   Thus far, no feedback has been received on the draft Initial Report, which signals the Initial Report is in good shape.
           *   Stakeholder Group Updates:
              *   Registries would like to continue to have conversations about Recommendation 13.1 – currently do not support. Notice this is flagged on the agenda, so we can discuss then.
  3.  Return to items in the preliminary recommendations flagged for further discussion during last week’s call (see here<https://docs.google.com/document/d/1clAqB1wBeOf9ZC5RMMxKrrUTs3N2WyaVYTIyVy_ODs4/edit>)
        *   Recommendation 7 (Jim Galvin)
           *   Current draft: Preliminary Recommendation 7: [The working group recommends that ICANN org establish minimum requirements for the composition of the TAC (for example, minimum length, syntax, or entropy value) based on current applicable technical security standards. ICANN org MAY change these requirements in response to new or updated standards, but any changes to the requirements MUST go in effect with sufficient notification and time for contracted parties to implement the necessary updates. ] OR [The Working Group recommends that Registrars and Registry Operators follow best practices for the composition of the TAC (for example, minimum length, syntax, or entropy value) based on current applicable technical security standards such as RFC9154 or subsequent or similar RFCs. These best practices may be updated in response to new or updated standards as appropriate.]
           *   The big issue here was how to make something enforceable, but not too prescriptive – this will involve a balancing act. How specific should the group get?
           *   It will be difficult to enforce who is properly creating a TAC – there are suggestions in the RFC with respect to randomness. It’s hard to know if there is a problem, unless something breaks. The suggestion that there should be enforcement of this is interesting. It may be better to see if the same value is popping up and appearing, and that would be for registries to check, which will also be difficult and possibly unacceptable to registries.
           *   The recommendation should be everything before the footnote brackets. The recommendation should be the first two sentences of Jim’s proposed recommendation. It is important to provide some sort of guidance to contracted parties here.
           *   Proposed update to Rec. 7: The working group recommends that the minimum requirements for the composition of a TAC MUST be as specified in RFC 9154 (and its update and replacement RFCs). In addition, where random values are required by RFC 9154, such values MUST be created according to BCP 106. [Footnote: BCP 106 is a Best Current Practice and is an idempotent reference to the most recent version of the specification entitled “Randomness Requirements for Security”, currently RFC 4086, which is how it is referenced in RFC 9154.]
           *   Some concerns about the language in the footnote being unknown or confusing to this average reader, and the group should make this more readable.
           *   Some may, for example, be confused by the language of idempotent. BCP 106 is a static reference and will be tied automatically to the latest RFC – the URL is always static.
           *   No objections to Jim’s proposed language.
           *   Action: Policy Support Staff to extract Jim’s explanation – take verbal explanation and create text that could complement what a non-IETF expert will understand. [Note: complete – please see: p. 3 of https://docs.google.com/document/d/1clAqB1wBeOf9ZC5RMMxKrrUTs3N2WyaVYTIyVy_ODs4/edit.
        *   Recommendation 9.2
           *   Saying one-way hash is the appropriate term of art. Saying that algorithms evolve with time is correct. Jim chose specific language that is laid out in RFC 9154. A potential improvement could be, similar to the IETF, abstract out algorithm identifiers to separately deal with algorithms as they change. It may be overkill for this specific application.
           *   Could this be an implementation note or footnote on the current 9.2?
           *   Proposed suggestion from Jim:
           *   9.2 When the Registrar of Record sets the TAC at the Registry, the Registry MUST store the TAC securely, at least according to the minimum requirement set forth in RFC 9154: using a strong one-way cryptographic hash with at least a 256-bit hash function, such as SHA-256 [FIPS-180-4], and with a per-authorization information random salt with at least 128 bits. [FIPS-180-4] National Institute of Standards and Technology, U.S. Department of Commerce, "Secure Hash Standard, NIST Federal Information Processing Standards (FIPS) Publication 180-4", DOI10.6028/NIST.FIPS.180-4, August 2015, <https://csrc.nist.gov/publications/detail/fips/180/4/final>.
           *   Delete text after one-way hash. Everyone beginning at using could be a footnote for the IRT.
           *
        *   Recommendation 13.1
           *   Everything before the comma seems supported by all.
           *   Registries are uncomfortable with the language “enforced by the registries”
           *   13.1: A standard Time to Live (TTL) for the TAC MUST be 14 calendar days from the time it is set at the Registry, enforced by the Registries.
           *   Registries are not finding support among the registries for enforcement by registries because (i) transferring a domain name is an activity that is done between registrars and registrants. Registrars have the relationship with the customer, not the registry. Putting the registry in an “ACK” capacity puts the registry in a position of making a decision for a customer for which the registry has not relationship with.
           *   Do not see a situation where a registry is going to communicate directly with a registrant when a TAC is expired
           *   If this was to be a requirement, it would not just be an invalid TAC – this is creating an issue for the gaining registrar. One wouldn’t want to use an “invalid TAC” message b/c this situation would have to be examined and investigated. Maybe there should be a new error code and error message and suggest that this is an expired TAC to report to the gaining registrar. This, however, is at odds with the requirement that no one stores TAC values. Now the registry would not just have to set the TAC to null but also store all TACs and their dates of evaluation. The implementation, on its face, sounds straightforward, but when it is parsed, it is more complicated.
           *   An invalid TAC message should be OK to send to the registrar, but this is good to discuss.
           *   Agree that the implementation is somewhat more complex than originally considered; however, forego the scenario where registry is in charge and put it on the losing registrar. The issue for the registry is now being transferred to the losing registrar. The same question will have to be posed to registrar technical folks.
           *   If you give a registry a role in the compliance of the TAC, that seems awkward at best, and not something that registries are supportive of. Registries will now have an obligation to be responsive to anything they did or didn’t do with the TAC. When the enforcement is put on registries, the registry is added to the compliance side of a TAC and a transfer, and that does not feel like a helpful transition. In the spirit of a transfer being a registrant engagement activity, it feels like it belongs with a registrant and not a registry.
           *   How does this work today? Would the registry just take the word of the registrar?
           *   Yes, the registrar sets the TAC and is responsible for it. The first level of investigation would be to the registrar. If you ask the registrar what they did, that would be the first order of what to be done.
           *   Asking Rys to be involved in the TTL was purposeful not a bug in ensuring the entire ecosystem did actually use a specific TTL, seeing as there are thousands / tens of thousands RRs and much fewer RY platforms
           *   Pulling Rys in explicitly to compliance here is awkward and is adding registries to something they do not want to be a part of.
           *   When a registry receives a complaint from a registrar, and a name needs to be moved from one registrar to another, how would that be done?
           *   That scenario is outside of this process because this is something that would be directed by ICANN and would be done manually.
           *   This is directly affecting the previous recommendation where the TAC is created upon request. It sounds like there is more due diligence to unpack this and baggage associated with this that needs to be accounted for. Given the time constraints, this may not be able to be unpacked prior to public comment. This could be a good candidate for very specific input from the community.
           *   The WG is creating a new model for transfers. There is an important starting principle – there is a window of vulnerability associated with that TAC. Currently, a transfer has a manual intervention – the registrant has to get the TAC and get it to the gaining registrar. The notion of enforcement is an interesting one. Enforcement from the point of view of ICANN or enforcement internally – are all registrars going to be well-behaved? Probably not. Would like to be cautious about tying registries and registrars together in this process.
           *
        *   Recommendation 13.2
           *   13.2: The Registrar of Record MAY set the TAC to null:
              *   At any time in response to a request from the RNH.
              *   After a period of less than 14 days by agreement by the Registrar of Record and the RNH.
           *   Leaving the recommendation at – the Registrar of Record MAY set the TAC to null – should be sufficient.
           *   Agree this is OK – the registrar should be responsible and responsive to their customer. The reason there was a limit on it is a concern that the registrar may set the TAC to null almost immediately and make transfers virtually impossible. If looking to shorten, the first bullet could potentially be removed.
           *   If there is no description of when Registrars may set TAC to null, this opens the door to set a TAC to null unscrupulously.
           *   Agreement to remove the first bullet, but keep the second..
  4.  Discussion of Recommendation 19 email thread (please see here<https://mm.icann.org/pipermail/gnso-tpr/2022-May/000449.html>)
           *   Mike R. stated some concerns about the current language.
           *   This suggestion is slightly more specific – could we consider “evidence of fraud or material violation of the Registration Agreement” I.A.3.7.1
           *   Material breach should be sufficient – important to keep fraud in.
           *   Will return to this item next week.
  5.  Begin review of items flagged in Proposed Revisions from Working Group members<https://docs.google.com/document/d/1s9xumJ1XBPdTb7kQmc5sAC2AkszvfAF0freMvnx6G18/edit> document (if any)
           *   To date, no input has been received, but if you would like to include additional items, please include them in the Google Doc by COB Friday: https://docs.google.com/document/d/1s9xumJ1XBPdTb7kQmc5sAC2AkszvfAF0freMvnx6G18/edit
           *   It is conceivable that the group may start Change of Registrant earlier than expected. The more Staff has advance notice, the more we can properly plan for the future meetings. It’s likely the group will discuss Change of Registrant at ICANN74. Staff already has the next iteration of the Initial Report that factors in the feedback from the next calls. The public comment forms are also ready to go. The Prep week webinar week will provide an overview of the recommendations in the Initial Report.
  6.  AOB

        *   Next call: Tuesday 24 May 2022 at 16:00 UTC

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20220517/8cb1157e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TPR Initial Report Draft - 17 May 2022.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 218088 bytes
Desc: TPR Initial Report Draft - 17 May 2022.docx
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20220517/8cb1157e/TPRInitialReportDraft-17May2022-0001.docx>