[GNSO-TPR] Notes and action items - TPR WG Meeting #28 - 14 Dec 2021

[Julie Hedlund]

Dear TPR WG Members,

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

The next TPR WG meeting will be on Tuesday, 21 December at 16:00 UTC.

Best regards,

Emily, Julie, Berry, and Caitlin

Action Items

TAC Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0AK00/edit__;!!PtGJab4!sHvI0klsPZod6P2AH_3JP4bQCxEjDpVvaMZPUlG0SLsE2JGHws3WPDn1Yt7jPnF99AFjMyvIDA$> (beginning on p. 15)

Page 16, charter question b1, rationale: Re: “A spike in complaints might have been an indication of security shortcomings that would need to be investigated further.”
ACTION ITEM: Strike the sentence.  It is covered earlier in the text.

Recommendation 3, page 16:
ACTION ITEM: WG members to comment on the revised language of recommendation 3.

Recommendation 5, page 16:
ACTION ITEMS:
1. Staff to split the concepts in the recommendation into two parts as per comments from WG members.
2. Replace “failed attempt” with “presentation of an invalid TAC” and “Registry must notifies the Registrar of Record of the presentation of an invalid TAC”.

Charter Question b2:
Recommendation 6, page 17:
ACTION ITEM: Staff to split the recommendation into three parts.

Recommendation 9:
ACTION ITEM: Change the text to: “The Registry Operator MUST clear the TAC as part of completing the transfer request.”  WG to review the revised text.

Transfer Policy Review Phase 1 - Meeting #28
Tuesday 14 December 2021 at 16:00 UTC

1. Roll Call & SOI Updates

  *   No updates provided.
2. Welcome & Chair updates (5 minutes)

  *   Update from Sarah Wyld: Yesterday we participated in a panel at the NARALO monthly meeting and discussed the TPR PDP.  Very useful discussion.
  *   Update from Jim Galvin, RySG: Agree that the NARALO panel was helpful.  Had a lot of really good discussion and asked some good questions about the transfer process.  Confirmation that we are addressing issues that are interesting and important.
  *   RySG Advice (Jim Galvin): Action to ask registries about providing the gaining registrar IANA ID to the registrar of record.  People are generally supportive of the concept.  Some technical issues came up that we will provide more details about. Keep in mind that the IANA ID is only present for accredited registrars and isn’t present everywhere.  Have to be able to accommodate those registrars without an IANA ID.  Also discussed which field to use and if there is an additional element then there needs to be a standard for it in the IETF, but that would be a relatively straightforward process.
  *   Kristian Ormen: ccTLDs would probably all follow the policy even where the ID isn’t available.
  *   Jim Galvin: Whatever solution we provide needs to be compatible.
3. Second reading: TAC and FOA (45 minutes) -- see:

TAC Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0AK00/edit__;!!PtGJab4!sHvI0klsPZod6P2AH_3JP4bQCxEjDpVvaMZPUlG0SLsE2JGHws3WPDn1Yt7jPnF99AFjMyvIDA$> (beginning on p. 15)

Page 16, charter question b1, rationale:

Re: “A spike in complaints might have been an indication of security shortcomings that would need to be investigated further.”

  *   Comment from Theo Geurts: “I suggest striking this if we do not know what happened it does not add any value. For all, we know a script went haywire somewhere.”
  *   Think this was put in here is because we were looking for any changes in that data.  Maybe just a wording change is needed.
  *   Even if it did indicate some kind of ICANN compliance issue they wouldn’t be able to say what to do.  Should be taken out?
ACTION ITEM: Strike the sentence.  It is covered earlier in the text.

Recommendation 2:

  *   Comment from Theo Geurts: “Note to WG, some registries create the TAC now and not the registrar. Perhaps this should be more clear so all actors involved are aware that code changes are required.”
  *   Recommendations shouldn’t be considered in isolation.  Maybe the answer is in relation to preliminary recommendation 6.  There is a variety of implementations that occur.  The current state is that a TAC is created at registration and sits there until requested from the registered name holder.  New recommendations state that the TAC is only created upon the request from the registered name holder.
  *   Maybe this could be included as an implementation note to put this in the context of recommendation 6.
Recommendation 3:

  *   Reconfiguring the language of the recommendation to be specific about the standards to be referenced.  Do we want to cover this now?
ACTION ITEM: Keep this as an ongoing action item for WG members to comment.

Recommendation 5:

  *   Comment from Theo Geurts: “These notifications need to be subject to standard EPP poll messages.”
  *   Need to define what is a failed attempt.  Need to think about the lock in this context.  “Failed attempt” may not be the right term.  Could refer only to “presenting an invalid TAC”.
  *   Would still need some wording for an invalid TAC with respect to the lock.
  *   We haven’t firmed up the final details, but if a TAC is presented to the registrar of record to the registry then the registry should confirm that there are no registrar locks on the name.  An nvalid TAC is whatever doesn’t match what is in the system.
  *   Replace “failed attempt” with “presentation of an invalid TAC” and “Registry must notifies the Registrar of Record of the presentation of an invalid TAC”.
  *   We need to tie the presentation of a TAC with the absence of locks.
  *   What threat are we protecting against to allow these things to be uncoupled and expecting the user to do the right thing?  It is more likely that we want simple principles.
  *   We are only creating the TAC at transfer in the future based on the current recommendations.
  *   Seems unnecessary to tie these together.  In today’s policy is “registry must remove the locks or provide registrars with access”.  Maybe we keep the same concept of “or”.
  *   The gaining registrar can quite easily see that the name is locked.  Don’t even take a transfer request if the domain is locked.
  *   Looking at this recommendation, agree to change “failed attempts” to “presents an invalid TAC”.  But do we need to be explicit about what is an “invalid TAC”?
  *   If the TAC is correct and the domain is locked it isn’t an invalid TAC.
  *   It only matters if the TAC is invalid to send a notice; if the TAC is correct and the domain is locked, the losing registrar doesn’t need to know.
  *   Notification is required only if the TAC is invalid.  Do we want to say what “invalid” means, or is that self-explanatory?  The word “invalid” seems clear enough, although we could include an implementation note.
  *   Re: 3-5 number: Most have precautions in place to monitory multiple TAC requests since registry resources aren’t unlimited.
  *   Don’t think we are getting multiple brute-force attempts.
  *   People are looking at the 3-5 number.  What is reasonable from a security point of view?  10 is a common number as an absolute.  3 is a common number too.
  *   How many attempts do you need to be successful for a brute-force attack?  You would need to send a massive amount of requests, and you will be shut out.
  *   Suggestion: Are we trying to pack too much into recommendation 5?  There are plenty of reasons why an invalid TAC could be sent.  Most likely the gaining registrar will be monitoring and attempting to correct the error.  Is it worth trying to separating the issues?  Staff could try to try to do recommendation 5a and 5b.
ACTION ITEMS:

  1.  Staff to split the concepts in the recommendation into two parts as per comments from WG members.
  2.  Replace “failed attempt” with “presentation of an invalid TAC” and “Registry must notifies the Registrar of Record of the presentation of an invalid TAC”.
Charter Question b2:
Recommendation 6:

  *   Re:  “generate the TAC, set the TAC in the Registry platform, and provide the TAC to the RNH” -- Comment from Sarah Wyld: “added some words for clarity, otherwise it suggests that we generate, set, and provide the TAC ALL to the RNH (but actually only provide is to the RNH).
  *   Staff suggestion is to split this into three parts: 1) registrar is the contracting party setting the TAC; 2) TAC is only generated upon request; 3) only after confirmed by the registry is a TTL set.
  *   Re: “After confirmation that  the TAC has been successfully set at the Registry, when the Registrar provides the TAC it should also provide information about when the TAC will expire.”  Comment from Jothan: Should this happen chronologically only after it has successfully been set with the registry, in order to ensure it works in harmony with any minimum standard of the registry?
  *   Staff is working on a diagram to work out the timing.
ACTION ITEM: Staff to split the recommendation into three parts.
Recommendation 7:

  *   Is “disclosure” the right word in “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.”  Or is “unintended” or “unauthorized”.
  *   Seems to be the right term.
  *   Could provide a footnote to clarify that the disclosure only happens when the un-hashed code is used to validate the transfer.
Recommendation 8:

  *   Don’t seem to be any issues.
  *   But if this is becoming part of the transfer policy we could add a sentence clarifying that the AuthInfo Code is being replaced by the TAC.
ACTION ITEM: Staff to add a sentence clarifying that in the transfer policy the term “AuthInfo Code” is being replaced by “TAC”.

Recommendation 9:

  *   Re: “Once the Registry Operator has verified that the TAC provided by the Gaining Registrar is valid in order to accept an inter-registrar transfer request,” Comment from Sarah Wyld: “is this clear enough? should we add something to indicate that this happens after the transfer is completed?” And from Roger: “+1. Also, should we say "...the Registry should clear the TAC..." instead of "null" to allow flexibility?”
  *   Depends on what we decide on the losing FOA.
  *   What do we mean by “clear the TAC” instead of “null” – a way of saying that the field is empty (so null).
  *   May need to put a pin in this one to make sure there is consistency with the losing FOA recommendations.
  *   “clear the tac” is a better English phrase to describe what’s happening.  “set to null” is overly prescriptive as it treads into a technical description.
  *   Suggest not to be overly prescriptive on what needs to happen/sequence of steps at the back end at the registry.  The policy can just say what you expect to have occurred.
  *   Could we simply say “Once the transfer is complete, the Registry should clear the TAC”?  Or is this too prescriptive?
  *   We can say this if we get rid of the losing FOA.
  *   Don’t have to be prescriptive of when the steps take place – so no need to say that the TAC has to be cleared as a particular step (say, when complete).
  *   The registry could also clear the TAC as soon as they have verified it.
  *   We want to say that once the TAC is used it can no longer be used again.
ACTION ITEM: Change the text to: “The Registry Operator MUST clear the TAC as part of completing the transfer request.”  WG to review the revised text.

4. AOB (5 minutes)

  *   Next call: Tuesday 21 December 2021 at 16:00 UTC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20211214/afad897d/attachment-0001.html>