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

[Julie Hedlund]

Dear TPR WG Members,

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

The next TPR WG meeting will be on Tuesday, 10 May 2022 at 16:00 UTC.

Best regards,

Emily, Julie, Berry, and Caitlin


Action Items:

Draft recommendations on NACK Charter Question h1 produced by the small group (see working document pages 16-23 here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1L2bZnhJUY3VxyAjVCrkyVqdttOPn2EaqBARRRnEPd0Q/edit__;!!PtGJab4!t_o2O1GHzkJDjFq1Wmy7lE2ChWlmMrJ30pO8zf5rLHhKq3yVtdZZJDcTSI37gyzc98d9UDYNTg$>)

For I.A.3.7.3 -- Change “No payment” to “Non-payment”.
For I.A.3.9.1 -- WG members who have suggestions for text to address this situation should send them to the list.

Composition of the TAC (see attached document):

Recommendation 7:
1. Staff to consult with ICANN org Compliance as to whether there are issues with enforcement to reference an RFC without context.
2.  WG members to review the suggested text from Sarah and Jim and provide comments on the list.

Recommendation 11:
Jim Galvin and WG members to consider suggested change to the language as follows: “The working group recommends that the TAC as created by the Registrar of Record according to Preliminary Recommendation 7, must be “one-time use. In other words, it MUST be used no more than once per domain name. The Registry Operator MUST clear the TAC as part of completing the successful transfer request.”

Notes:

Transfer Policy Review Phase 1 - Meeting #45
Tuesday, 03 May 2022 at 16:00 UTC
Proposed Agenda

1. Roll Call & SOI updates

2. Welcome & Chair updates

  *   Homework: Review Initial Report and identify those items that need extra work in coordination with your groups as much as possible.
  *   Only other reminder is that we have 6 sessions now to work diligently, avoiding bringing up settled discussions.
3. Draft recommendations on NACK Charter Question h1 produced by the small group (see working document pages 16-23 here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1L2bZnhJUY3VxyAjVCrkyVqdttOPn2EaqBARRRnEPd0Q/edit__;!!PtGJab4!t_o2O1GHzkJDjFq1Wmy7lE2ChWlmMrJ30pO8zf5rLHhKq3yVtdZZJDcTSI37gyzc98d9UDYNTg$>)

Overview:

  *   Reminder: the goal is to take the small group outputs as they are unless something is really broken or wrong in what they produced.
  *   Thank the members of the small team and the staff support, particularly the summary table.
  *   Focus was the finalize the input from the full WG.
Recommendation 19: The working group recommends revising the following reasons that the Registrar of Record MAY deny a transfer request as follows:

I.A.3.7.1: Evidence of fraud or violation of the Registration Agreement. Implementation Guidance: The ​​intent of “violation of the Registration Agreement” is not to allow the blocking of transfers due to minor violations, but to allow action in case of substantive contravention of the Registration Agreement.

I.A.3.7.2: Reasonable dispute over the identity of concern that the transfer was not requested by the Registered Name Holder or Administrative Contact.

  *   Identity is not the goal.
I.A.3.7.3: No payment for previous registration period (including payment disputes or credit card charge-backs) if the domain name is past its expiration date at the current Registrar of Record or for previous or current registration periods if the domain name has not yet expired. In all such cases, however, the domain name must be put into "Registrar Hold" status by the Registrar of Record prior to the denial of transfer.

Comment from Jothan re: “for previous or current registration periods if the domain name has not yet expired…” I was asked if this addresses explicit renewals in addition to those within add-grace

Recommendation 20: The working group recommends changing the following reasons that the Registrar of Record currently  MAY deny a transfer into reasons that the Registrar of Record MUST deny a transfer and revising the text as follows:

I.A.3.7.4: Express objection to the transfer by the authorized Transfer Contact Registered Name Holder. Objection could take the form of specific request (either by paper or electronic means) by the authorized Transfer Contact Registered Name Holder to deny a particular transfer request, or a general objection to all transfer requests received by the Registrar, either temporarily or indefinitely. In all cases, the objection must be provided with the express and informed consent of the authorized Transfer Contact Registered Name Holder on an opt-in basis and upon request by the authorized Transfer Contact Registered Name Holder, the Registrar must remove the lock or provide a reasonably accessible method for the authorized Transfer Contact Registered Name Holder to remove the lock within five (5) calendar days.

I.A.3.7.5: The transfer was requested within 60 30 days of the creation date as shown in the registry Whois RDDS record for the domain name.

I.A.3.7.6: A domain name is within 60 30 days (or a lesser period to be determined) after being transferred (apart from being transferred back to the original Registrar in cases where both Registrars so agree and/or where a decision in the dispute resolution process so directs). "Transferred" shall only mean that an inter-registrar transfer has occurred in accordance with the procedures of this policy.

Discussion:

  *   Re: 1.A.3.7.3: Question: If someone has entered into a payment plan and the registrant determines to renew the domain name, you would not want the domain name to transfer away during that time. Do the sections address this? Answer: For I.A.3.7.3 – instead of “No payment” we could say “Non-payment”, but maybe it covers without that.
  *   Seems like the registrar has extended credit to the registrant, but the domain has been paid for.  Seems like a more complicated relationship, that doesn’t involve a grace-period payment.  Don’t think the policy has to accommodate this.
  *   Think it is premium names that are not addressed in the current policy.
  *   Seems like if there was a payment plan there would be contracts to cover that?
ACTION ITEM: For I.A.3.7.3 -- Change “No payment” to “Non-payment”.

Recommendation 21: The working group recommends revising the reasons that the Registrar of Record MUST deny a transfer request as follows:

I.A.3.8.1: A p Pending UDRP proceeding that the Registrar has been informed notified of by the Provider in accordance with the UDRP Rules.

I.A.3.8.3: Pending dispute related to a previous transfer, pursuant to under the Transfer Dispute Resolution Policy.

I.A.3.8.4: Pending URS proceeding or URS suspension that the Registrar has been informed notified of by the Provider in accordance with the URS Procedure.

Recommendation 22: The working group recommends changing the following reasons that the Registrar of Record currently MAY NOT deny a transfer into reasons that the Registrar of Record MUST NOT deny a transfer and revising the text as follows:

I.A.3.9.1: Implementation Guidance: Registrars are prohibited from denying domain name transfer requests based on non-payment of fees for pending or future registration periods during the Auto-Renew Grace Period, provided that any auto-renewal costs borne by the Registrar are reversible for future period.

  *   Comment from Jothan: Explicit renewals do not have automatic refunds like auto-renewals.  These have a unit cost that extends the renewal term for 1 year so is related to a future registration period.  Is the losing registrar protected in this instance by this verbiage where a registrant extends and has funds still due?
  *   This one might suggest that a registrant might have their transfer denied while under a payment plan.  If that is covered by contract, then that’s okay.  Wording could leave room for the registrant to migrate the domain away.
  *   The question is whether we want to allow registrars to hold a transfer hostage for payment?  But this could be covered by a contract.
  *   Registrars should take this into account with the contracts with registrants.
  *   Think we are confusing this with a title, versus a payment plan that is like an unsecured loan.  This is not an apt analogy. In Jothan’s situation the entity loaning the money has made an unsecured loan.  Or mechanism facilitates the situation where the registrar could be the registered name holder and leases the name, rather than the registrant holding the title so to speak.
  *   You could structure the deal in a way that the registrar is listed as RNH until the domain is paid in full.
ACTION ITEM: For I.A.3.9.1 -- WG members who have suggestions for text to address this situation should send them to the list.

I.A.3.9.2: No response from the Registered Name Holder. or Administrative Contact

I.A.3.9.3: A registrar-applied inter-registrar transfer lock is in place on the Ddomain name in Registrar Lock Status, for reasons other than those specified in I.A.3.7 and I.A.3.8 unless and the Registered Name Holder is not provided with the reasonable opportunity and ability to unlock the domain name prior to the Transfer Request pursuant to the requirements in sections I.A.5.1 - I.A.5.4.

I.A.3.9.4: Domain name registration period time constraints, other than as defined in I.A.3.7.5 and I.A.3.7.6[1] during the first 60 days of initial registration, during the first 60 days after a registrar transfer , or during the 60-day lock following a Change of Registrant pursuant to Section II.C.2.

I.A.3.9.5: General payment defaults between Registrar and Reseller, as defined in the RAA, business partners / affiliates in cases where the Registered Name Holder for the domain in question has paid for the registration.

4.  Composition of the TAC – Recommendations 7, 9, and 11

Recommendation 7:

Current text:
[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.]

From Sarah Wyld:
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.

From Jim Galvin:
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.] The salient specification point from RFC 9154 is as follows.
● Using the set of all printable ASCII printable characters except space and a required entropy of 128 bits, the length of the TAC MUST be at least 20 characters. Gould, J. and R. Wilhelm, "Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer", RFC 9154, DOI 10.17487/RFC9154, December 2021,
<https://www.rfc-editor.org/info/rfc9154>.
Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005, <https://www.rfc-editor.org/info/bcp106>.

Discussion:

  *   Seems rather technical for a policy recommendation.
  *   Seems reasonable though.
  *   Not sure how to balance technical with general.  Not sure what to change.
  *   Maybe we can find a way to bring in Sarah’s language.
  *   RFC 4086 and BCP 106 are the same document.
  *   If the PDP wants to say higher level and just refer to the IETF standards, it could refer to RFC 4086 and BCP 106 and stop there.
  *   This seems like a good suggestion.
  *   Are we future proofing this enough, or locking it in one place?  To the extent that the technology evolves the RFCs would be updated accordingly.  They would be adaptable.
  *   In RFC 9154, it has a “SHOULD” around the 20 characters – it doesn’t make it a “MUST”.  The bullet point in the suggested text makes it a “MUST”.
  *   Seems that this text might be too technical for a recommendation, but great to have for reference?
  *   IETF didn’t put “MUST” in because that would have been policy; this WG would have to make it a “MUST” to make it policy.
  *   The objective is to make sure we are providing registrants a reasonable amount of security for the TAC.  The specificity of the text has to be balanced with evolving technology.
ACTION ITEMS:
1. Staff to consult with ICANN org Compliance as to whether there are issues with enforcement to reference an RFC without context.
2.  WG members to review the suggested text from Sarah and Jim and provide comments on the list.

Recommendation 9:

Current text:
The working group recommends that:
9.1 The TAC MUST be only generated by the Registrar of Record upon request by the RNH or their designated representative.
9.2: When the Registrar of Record sets the TAC at the Registry, the Registry MUST securely store the TAC using a one-way hash that protects the TAC from disclosure.
9.3: When the Registrar of Record provides the TAC to the RNH or their designated representative, the Registrar of Record MUST also provide information about when the TAC will
expire.

From Jim Galvin:
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", DOI 10.6028/NIST.FIPS.180-4, August 2015, <https://csrc.nist.gov/publications/detail/fips/180/4/final>.

Discussion:

  *   This prevents the registry from storing TACs with encryption that is reversable.  The registry can never recover the TAC.   If it is encrypted it could be recovered using the key.  This means that the TAC is short lived and disposable.
  *   Registry can compare them, not recreate them.
  *   This is not current practice – this is a big improvement in security.  How to make this clear.
  *   If the TAC is transformed into something only used for the transfer it would affect registrars who use the TAC for other confirmations/authorizations.
  *   If they are using it for something else don’t we should address that here.  The TAC is supposed to be only for transfer.
  *   Current TAC is not as private as people think it is.
Recommendation 11:

Current text:
The working group recommends that the TAC MUST be “one-time use.” In other words, it MUST be used no more than once per domain name. The Registry Operator MUST clear the TAC as part of completing the successful transfer request.

From Jim Galvin:
The working group recommends that the TAC MUST be “one-time use.” In other words, it MUST be used no more than once per domain name. The Registrar of Record MUST meet this requirement by randomly creating a new TAC each time one is needed as specified in Preliminary Recommendation 7. The Registry Operator MUST clear the TAC as part of completing the successful transfer request.

Discussion:

  *   Concern that this would force people to work with other people’s patented processes.
  *   For bulk transfers, still planning to use a TAC on a single domain – hadn’t yet recommended one TAC for multiple domains. Will be revisiting this.  In this case, “bulk” means that if you have 100 names you have 100 TACs.
  *   All Jim added was a sentence tying this to recommendation 7.
  *   Seems like Recommendation 11 is valid without the additional text.
  *   The current wording does not specify that the registrar of record is creating the TAC and links that to recommendation 7.  Could amend to take out the word “randomly” – you don’t need it if you are referencing recommendation 7.
  *   Do think it’s useful to tie together the related recommendation.
  *   Don’t understand the “MUST meet”.
  *   Suggestion from Rick Wilhelm: “The working group recommends that the TAC as created by the Registrar of Record according to Preliminary Recommendation 7, must be “one-time use.” In other words…”
  *   Proprietary, non-standard use of Auth-Info shall be broken by this.
ACTION ITEM: Jim Galvin and WG members to consider suggested change to the language as follows: “The working group recommends that the TAC as created by the Registrar of Record according to Preliminary Recommendation 7, must be “one-time use. In other words, it MUST be used no more than once per domain name. The Registry Operator MUST clear the TAC as part of completing the successful transfer request.”

5. AOB

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20220503/807c98b3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Preliminary Recommendations on TAC suggested text.pdf
Type: application/pdf
Size: 47706 bytes
Desc: Preliminary Recommendations on TAC suggested text.pdf
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20220503/807c98b3/PreliminaryRecommendationsonTACsuggestedtext-0001.pdf>