Dear TPR WG members,

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

The next meeting will be on Tuesday, 22 November at 16:00 UTC.

Best regards,

Emily, Julie, Berry, and Caitlin

ACTION ITEMS/HOMEWORK:

Jothan Frakes, Jim Galvin, Jody Kolker, and Rick Wilhelm have volunteered to compile a list of attack vectors and how the recommendations solve for them, or where they are out of scope.

Recommendation 10:

a) Concern -- Staff to see where the discussion on the Losing FOA falls and then to tidy up the language in recommendations and rationales.
b) Proposed edit -- Staff to amend the recommendation according to the strawman revision suggested in the potential next step.

Recommendation 11:

b) Proposed edit -- Staff to revise the recommendation either according to the potential next step in the strawman revision of “unset the TAC” or retaining the term “clear” with a definition in a footnote.
c) Proposed Edit -- Jim Galvin to bring this issue back to the Registry SG for discussion/consideration.

Recommendation 13:

d) Proposed edit -- Staff to update the language to “Registry” from “Registries”.
e) Proposed edit -- Staff to revise the language according to the Strawman revision suggested in the Potential next step.
f) Proposed edit -- Staff to revise the language according to the Strawman revision suggested in the Potential next step, except to change to “reset the TAC to null.”
Question to the community -- Staff to call for volunteers to consider whether to 1) maintain the recommendation as is – that the registries enforces; 2) add language to the current recommendation; 3) change it to the Registrars to manage the TTL; or 4) not to specify who enforces it. Volunteers during the meeting are: Jim Galvin, Rick Wilhelm (need to confirm), Jody Kolker, and John Woodworth.

Notes:

Transfer Policy Review - Meeting #67

Proposed Agenda

17 November 2022

1. Roll Call & SOI updates

2. Welcome and Chair Updates

Just one meeting next week on the 22^nd – no meeting on the 24^th due to the US holiday.
Comments on redlined recommendations 3-9 and strawman for recommendation 2 are due by 30 November.
Previously discussed enhancing the rationales, but didn’t include that for recommendations 3-9; once we are closer to finalizing recommendations staff will adjust the rationales as necessary, also to take into account the work of the small team on threat vectors.

3. Verification of TAC Validity – Recommendation 10 (Public Comment Review Tool and Public Comment Working Document [docs.google.com])

a) Concern:

One cannot claim that this is a "security improvement" in the rest of the document to justify removal of the Losing FOA. This recommendation does nothing to bolster security.
Potential next step: WG to consider if it needs to revisit which recommendations about the TAC should be referenced as justification of the eliminating the Losing FOA.

Discussion:

This is a concern raised with respect to a number of recommendations.
This is more a continuation of operational values as opposed to a security feature.
Editorial exercise – careful that the TAC does not eliminate the Losing FOA – the Losing FOA is implemented differently in the new system.

ACTION ITEM: Recommendation 10, a) Concern -- Staff to see where the discussion on the Losing FOA falls and then to tidy up the language in recommendations and rationales.

b) Proposed edit

Recommendation should reference the Transfer Policy and not the Temporary Specification (which will, at some point, be superseded by this Policy). This is because the Temporary Specification is intended to be temporary and the updates to the Transfer Policy should live in a permanent update.

Potential next step: Strawman revision

The working group recommends that the Transfer Policy include the following requirement 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,” with terminology updates in accordance with other relevant recommendations.

Discussion:

WG agrees with the potential next step – strawman revision.

ACTION ITEM: Recommendation 10, b) Proposed edit -- Staff to amend the recommendation according to the strawman revision suggested in the potential next step.

4. TAC is One-Time Use – Recommendation 11 (Public Comment Review Tool and Public Comment Working Document [docs.google.com])

a) Concern

One cannot claim that this is a "security improvement" in the rest of the document to justify removal of the Losing FOA. This recommendation does nothing to bolster security.

Furthermore, RFC 9154 says (in section 4.3): "4. The authorization information MUST only be stored by the gaining registrar as a "transient" value in support of the transfer process. 5. The plain-text version of the authorization information MUST NOT be written to any logs by a registrar or the registry, nor otherwise recorded where it will persist beyond the transfer process."

But, according to Rec #11, the TAC is "one-time-use", and so if the registry operator has cleared the TAC, it would have had no loss of security if it had been logged for audit trail purposes by the gaining registrar. So, this didn't make sense.

Rec 11: #3

Potential next step: WG to consider the merits of these arguments and whether they warrant adjustment to the Report and recommendations.

Discussion:

WG agrees that no changes are necessary.

b) Proposed edit

Be more precise on including what the action of “clear” entails in the policy recommendations as Org understands that “clear” entails unsetting the authorization information by the Registry.

Potential next step: Strawman revision:

The Registry Operator MUST unset the authorization information ~~clear the TAC~~ as part of completing the successful transfer request.

Discussion:

More natural to say “unset”, but not aware that there have been concerns about this phrasing. Should be apparent that it should be the opposite of what the registrar is doing.
WG agrees that the suggested text in the strawman revision is a better fit.

ACTION ITEM: Recommendation 11, b) Proposed edit -- Staff to revise the recommendation either according to the potential next step in the strawman revision of “unset the TAC” or retaining the term “clear” with a definition in a footnote.

c) Proposed edit

Add language that specifies a scenario where if the transfer request is not successful (e.g. “NACKED” by the losing registrar), the TAC must also be cleared by the registry operator, and a notification sent by the losing registrar explaining that the transfer request was not successful and a new TAC must be generated if a new transfer request is to be generated.

Potential next step: WG to consider whether the recommendations should include additional details per the scenario described.

Discussion:

Worry about the timing of this step: 1) interaction with registry lock; 2) one-time use of the TAC – when is it used? When it is received?
Would like some time to discuss within the Registry SG.
Thought the use was when the transfer was complete?
May need to add language to make that time period clearer.
If the registry lock is enacted when the TAC is received and if the decision is to not unlock it, would that then be a NACK?

ACTION ITEM: Recommendation 11, c) Proposed Edit -- Jim Galvin to bring this issue back to the Registry SG for discussion/consideration.

5. Service Level Agreement (SLA) for TAC Provision – Recommendation 12 (Public Comment Review Tool and Public Comment Working Document [docs.google.com])

a) Concern

One cannot claim that this is a "security improvement" in the rest of the document to justify removal of the Losing FOA. This recommendation does nothing to bolster security. To improve security, you would need to mandate a delay in the provision of the TAC.
Potential next step: WG to consider if it needs to revisit which recommendations about the TAC should be referenced as justification of the eliminating the Losing FOA.

Discussion:

Staff to make sure this is consistent if we use the terminology anywhere else.

b) Concern

The Registries note an ambiguity between Recommendations 3 and 12 that we believe should be clarified. Recommendation 3 states that the Registrar of Record is required to notify an RNH of the provision of a TAC within 10 minutes of its request. However, Recommendation 12 states that the TAC itself must be provided within at most 5 days. The use of “provision” and “provide” are ambiguous. Perhaps Recommendation 3 is intended to notify an RNH of the “request” for a TAC as opposed to its provision? Other resolutions are possible and our suggestion does not indicate a preferred choice.

Rec 12: #8

Potential next step: WG to consider if the edits proposed with respect to the “Notification of TAC Request” are sufficient to address this comment. Namely, that the term “Notification of TAC Issuance” will be used, and the recommendation will refer to the time that the TAC is issued. Strawman edit:

Recommendation 12: The working group confirms that the Transfer Policy MUST continue to require Registrars to set the TAC at the Registry and provide issue the TAC to the RNH or their designated representative within five calendar days of a request, although the working group recommends that the policy state the requirement as 120 hours rather than 5 calendar days to reduce any risk of confusion. The working group further recommends that the policy MUST make clear that 120 hours is the maximum and not the standard period in which the TAC is to be provided issued.

Discussion:

Any comments on shortening the time period or keeping it the same? No comments so no changes needed to Recommendation 12.

6. TAC Time to Live (TTL) – Recommendation 13 (Public Comment Review Tool and Public Comment Working Document [docs.google.com]) and question for community input (Public Comment Review Tool and Public Comment Working Document [docs.google.com])

a) Concern

One cannot claim that this is a "security improvement" in the rest of the document to justify removal of the Losing FOA. This recommendation does nothing to bolster security. Many people may access the TAC in a 14-day period.	Rec 13: #5
Potential next step: WG to consider if it needs to revisit which recommendations about the TAC should be referenced as justification of the eliminating the Losing FOA.

Discussion:

WG agrees that no changes are necessary.

b) Concern

The permitted maximum of 14 days appears to be unnecessarily long given that the longer that it is available the generally greater chance that there is of its misuse.
Potential next step: WG to consider if these comments introduce new information that may prompt the WG to reconsider the current recommended 14-day period.

Discussion:

14 days seems to be the right time period – it is already pretty short.
WG agrees that no changes are necessary.

c) Concern

Add provision that the Rr MAY NOT set the TAC to null after a period of less than 24 hours.

Rationale: This is to prevent registrars from abusing this clause and blocking users from legitimately transferring out their domain names like for example - setting TAC to null after one minute.

Potential Next Step: The WG previously considered including a minimum TTL but did not come to agreement to do so. If recommendations are kept as-is, consider adding rationale explaining why this is not needed?

Discussion:

This was discussed previously and WG did not come to any agreement on a minimum TTL.
24 hours sounds nice, but doesn’t prevent 24 hours and 1 minute. The 14 days is more secure.
WG agrees that no changes are necessary.

d) Proposed edit

Change “standard” to “maximum” in accordance with §13.2 which allows for a shorter TTL but not for a longer one.

Change “enforced by the Registries” to “enforced by the Registry" to clarify that the registry is authoritative for the TLD in question. . .

Potential next step: Strawman revision:

13.1: A ~~standard~~ maximum Time to Live (TTL) for the TAC MUST be 14 calendar days from the time it is set at the Registry, enforced by the Registry~~ies~~.

[Staff note: If this edit is adopted, does the recommendation need to more explicitly state that there must always be a TTL?]

Discussion:

If we use “standard” do we need to footnote it?
WG agrees that no changes are necessary, but consider a footnote and change to “Registry” as opposed to “Registries”.

ACTION ITEM: Recommendation 13, d) Proposed edit -- Staff to update the language to “Registry” from “Registries”.

e) Proposed edit:

Be consistent through the policy recommendations. Use the combination of 14 days and 366 hours instead of calendar days alone.

Rec 13: #6

Potential next step: Strawman revision

13.1: A standard Time to Live (TTL) for the TAC MUST be 14 calendar days / 366 hours from the time it is set at the Registry, enforced by the Registries.

Discussion:

WG agrees with the Strawman revision in the Potential next step, but notes that the number of hours is 336, not 366.

ACTION ITEM: Recommendation 13, e) Proposed edit -- Staff to revise the language according to the Strawman revision suggested in the Potential next step.

f) Proposed edit:

Use more precise language in place of “clearing the TAC” or “setting the TAC to null.”

Potential next step: Strawman revision

13.2: The Registrar of Record MAY unset the authorization information set the TAC to null: After a period of less than 14 days by agreement by the Registrar of Record and the RNH.”

Discussion:

WG agrees with the Strawman revision suggested in the Potential next step, except for the change to “reset the TAC to null”.

ACTION ITEM: Recommendation 13, f) Proposed edit -- Staff to revise the language according to the Strawman revision suggested in the Potential next step, except to change to “reset the TAC to null.”

Question for Public Comment

Question to the community: Who is best positioned to manage the standard 14-day TTL – the Registry or the Registrar, and why? Are there specific implications if the TTL is managed by the Losing Registrar?

Discussion:

RySG is still opposed. Seems that this needs further discussion.
Could be managed both ways.
Wonder if a small group of Registries and Registrars could get together to consider whether to keep the language, add language, or not spell it out as to who enforces it.

ACTION ITEM: Recommendation 13, Question to the community -- Staff to call for volunteers to consider whether to 1) maintain the recommendation as is – that the registries enforces; 2) add language to the current recommendation; 3) change it to the Registrars to manage the TTL; or 4) not to specify who enforces it. Volunteers during the meeting are: Jim Galvin, Rick Wilhelm (need to confirm), Jody Kolker, and John Woodworth.

7. AOB