[GNSO-TPR] Notes and action items - TPR Meeting #19 - 28 September 2021
Julie Hedlund
julie.hedlund at icann.org
Tue Sep 28 17:42:17 UTC 2021
Dear TPR Working Group,
Please find below the notes and action items from today’s TPR meeting on Tuesday, 28 September 2021 at 16:00 UTC.
The next meeting will be Tuesday, 05 October at 16:00 UTC.
Best regards,
Emily, Caitlin, Berry, and Julie
--
Action Items:
Homework for the WG by Monday, 04 October: WG members should provide descriptions of the purposes of the gaining FOA and of the functions that the WG recommends to replace those purposes.
See the updated Work Plan and Action Items here: https://docs.google.com/spreadsheets/d/1FunWaz3gNZl8mPi5pNKti2GsfPC_9_DTt8uRQq4Oe5Q/edit?usp=sharing [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1FunWaz3gNZl8mPi5pNKti2GsfPC_9_DTt8uRQq4Oe5Q/edit?usp=sharing__;!!PtGJab4!qxlptUrJ1ANf6GnP-fUZ6w_hjjv1maS31O6P-jcfehCIc93D4QInTWi7OmJVvuXvAH-MaWGjsQ$>
Notes:
Transfer Policy Review Phase 1 - Meeting #19 – Tuesday, 28 September at 16:00 UTC
Proposed Agenda
1. Roll Call & SOI Updates (5 minutes)
* See updated SOI from Farzaneh Badiei at: https://community.icann.org/display/gnsosoi/Farzaneh+Badiei+SOI.
2. Welcome & Chair updates (5 minutes)
* Comments from WG members: None.
3. New Topic: Gaining FOA (75 minutes) – See: Gaining FOA working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1QOCzbLh7w4hdijpAsg6_lybddr0nlsFDcWjdz5e21Qo/edit?usp=sharing__;!!PtGJab4!o01IykxHjlIJMlYKgf5WXN399sOTJsj-MSxXUHasSo4IeUvRalOA7qnZJ1P44kLW1-T8IFtXkA$>
Charter Questions:
a4) If the Working Group determines the Gaining FOA is no longer needed, does the AuthInfo Code provide sufficient security? The Transfer Policy does not currently require specific security requirements around the AuthInfo Code. Should there be additional security requirements added to AuthInfo Codes, e.g., required syntax (length, characters), two-factor authentication, issuing restrictions, etc.?
Discussion:
* Think we have answered this. We have had discussions around additional security relating to AuthInfo Codes.
* Question: Where are all the working documents? Answer: On the wiki at: https://community.icann.org/display/TPRPDP/Working+Documents.
* Note that there are some candidate recommendations on AuthInfo Codes at: https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0AK00/edit?usp=sharing (page 16).
a5) If the Working Group determines the Gaining FOA is no longer needed, does the transmission of the AuthInfo Code provide a sufficient “paper trail” for auditing and compliance purposes?
Discussion:
* Everyone recognized that the gaining FOA provided another piece of the audit trail. Do we need to make sure that is embedded elsewhere? It is not just what we’ve done for the TAC, but also the notification of the transfer being complete provides an audit trail.
* From ICANN Compliance: Requiring AuthInfo Code and Losing FOA be provided to the registrant.
* We have ways to track the request history without Gaining FOA.
Summary:
* We aren’t getting rid of the losing or gaining FOA, but instead replacing their functionalities. Important to ensure that we are addressing the reason why the gaining FOA was being used.
* Question: Rather than thinking about getting rid of the gaining FOA, but should we be taking the features and requirements served by the gaining FOA and say that you have to keep certain records. Do we want to make sure that we say that there is a paper trail, you are required to keep it, and this is the information it has to have.
* The key is to extract the purposes of the gaining FOA and either provide those in another mechanism, or a rationale for why we don’t think we need to serve that purpose anymore.
Poll Questions and Responses:
(Q1) Did the Gaining FOA serve a security function? - 15 responses
* Yes, and new requirements should exist to replace the Gaining FOA’s security function -- 33%
* Yes, but this function is no longer necessary -- 40%
* No, it did not serve this function -- 27%
* Not sure/Needs further discussion -- 0%
Discussion:
* Just a mechanism to transfer a domain name; was not originally a security function.
* It’s primary purpose was not as a security feature, just to facilitate a transfer. It could be a security feature, but it wouldn’t be a strong one. But, the added set might provide a small amount of security.
* Think the gaining FOA requirements predated AuthInfo Codes.
* Not everyone sees it as a security feature, or as a strong one.
* Back in the day, we weren’t thinking in terms of security so these weren’t well documented.
* The difficult question is whether or not the gaining FOA is a security mechanism.
* Seems that there is general agreement that it does add something, if not security.
(Q2) Did the Gaining FOA serve a notification function? - 16 responses
* Yes, and new requirements should exist to replace the Gaining FOA’s notification function -- 63%
* Yes, but this function is no longer necessary -- 38%
* No, it did not serve this function -- 0%
* Not sure/Needs further discussion -- 0%
Discussion:
* Don’t think we need a policy requirement because the losing registrar will have that requirement. The gaining registrar may wish to do it for other reasons.
* The gaining FOA from the gaining registrar’s perspective did serve a purpose, but it doesn’t need to be a policy requirement.
* Losing registrar will have policy obligation to notify, they don't both need to; Gaining registrar may have marketing desire or data protection obligation to notify, but not due to the transfer itself.
(Q3) Did the Gaining FOA serve a “paper trail” function? - 18 responses
* Yes, and new requirements should exist to replace the Gaining FOA’s “paper trail” function -- 44%
* Yes, but this function is no longer necessary -- 50%
* No, it did not serve this function -- 0%
* Not sure/Needs further discussion -- 6%
Discussion:
* We need to know whether the function isn’t necessary or has been replaced and with what.
* If 44% said yes, there is still a “paper trail” function, what would that look like? What are the barriers to accomplishing that?
* The key here is that the majority people agreed that it provided a “paper trail” but disagreed on whether it was still needed.
(Q4) Did the Gaining FOA serve another function not listed in previous questions? - 16 Responses
* Yes -- 0%
* No -- 94%
* Not sure/Needs further discussion -- 6%
Discussion:
* Majority agreement that there are no other functions provided by the gaining FOA.
* Sending emails for notification could be used by bad actors for phishing. When we do have mandatory emails requiring action by the registrant that can result in opportunities for abuse, so think about that if we are keeping notification requirements.
* Perhaps in the policy we shouldn’t specify the mechanism for the transfer notification.
* Answered “no” because we are talking about the gaining FOA as is (current policy).
* Could take lessons from other industries on security principles, such as the financial industry. Such as the principle to not have embedded actions (such as clicking links). Notification itself can’t be directly actionable.
* Keep in mind the timing of these types of notification – what is interesting is that the gaining FOA pre-GDPR was the first notification the registered name holder would receive, to agree to transferring the domain. Secondarily there was an option to reject that transfer as unauthorized.
* If the gaining FOA is no longer a requirement, that changes the timing and who is notifying whom – which is connected to whether the gaining FOA played a part in a security mechanism.
(Q5) Which statement do you support with respect to Gaining FOA? - 16 responses
* The requirements should be removed from policy with no replacement -- 44%
* Improved FOA security and new notifications are sufficient to replace it -- 50%
* The WG needs to explore other possible measures to replace it -- 6%
* Not sure/Needs further discussion -- 0%
Discussion:
* If we aren’t going to replace this function, we’ll need to provide a rationale.
* Looks like we have a fairly even split.
* Is this a solution in search of a problem? Seems like things are in good shape at the moment.
* One distinction to make with respect to actionable notifications when thinking about the desire for 1-click actions, are you starting something or stopping something? there’s a case to be made to have a one-click to stop something but require logging in to the portal (being careful about phishing attacks, i.e., use two-factor authentication) to confirm or start something. it’s a subtle distinction that requires careful analysis but could be helpful.
* Keep in mind with the redacted WHOIS it is not possible to send a gaining FOA at this moment.
* Think we've got all the functionality moved to other places in the process.
* If we thought the gaining FOA did something that we can't do any other way, we could explore how to keep it, but don't think that is the case, and then if we get into how to keep it, we need to consider lawful bases for processing the data, which may be nonexistent.
* In the first answer we talk about “requirements” but think this question is just about the gaining FOA as a document in itself – think we want to keep all the things that this document stood for. The FOA itself needs to go away, but the requirements it stood for will replace it.
* We want the security and notification, but they don't have to happen via the gaining FOA.
* Can’t enforce what we were sending in the way we were sending it.
* Find ways to keep what those notifications represented.
* Think we will get information from the new registrar in another way.
* Because of GDPR there needs to be some kind of contract between the losing and gaining registrars in order to transfer data. Is there a legal way to share data? So far no one could come up with a good way of doing that.
* Don’t see how we can keep what the gaining FOA stood for because of GDPR. The data is not accessible.
* “what it stood for” is the security requirements and paper trail that were provided by it.
* Question: Is there a stakeholder insisting on keeping the gaining FOA? Answer: Not that we are aware of.
* Seem to be recommending that we eliminate the gaining FOA, but then we need to identify its purposes and how they are being met with other mechanisms.
* Need to ask the question of whether the TAC notifications address the purposes of the gaining FOA (the TAC presentation notification).
* Potential scenario: A registrant goes to their incumbent registrar to ask for a TAC, registrant brings it to the gaining registrar, but realizes they lost it and can go back to the losing registrar message and asks again. If they don’t realize they lost it, but get a notification of transfer, they have the option to claw that back. If the accounts are compromised then we can’t do anything about that.
* Don’t see how the gaining FOA improves security.
* Majority of transfers happen without issues, but we are trying to solve for those who don’t.
* Everyone seems to agree that the gaining registrars notifications would be very limited.
* The gaining registrar may have business reasons to send out notifications, but the losing registrar won’t. Seems we agree that if the gaining registrar sends a notification it should not be mandatory, but optional.
* All the security requirements go on the front end of the transfer, with the option at least to claw it back.
* RNH should be notified when the transfer completes, but don't think that MUST come from the new Registrar.
* Summary: Think we agree that the gaining FOA cannot exist in its current form in future, but it does provide certain functionalities that have been replaced. We need to say what those functionalities are and how they have been replaced (such as the presentation of the TAC).
ACTION ITEM: Homework for the WG by Monday, 04 October: WG members should provide descriptions of the purposes of the gaining FOA and of the functions that the WG recommends to replace those purposes.
4. AOB (5 minutes)
- Next meeting: 5 October 2021 @ 16.00 UTC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20210928/57e0bf0d/attachment-0001.html>
More information about the GNSO-TPR
mailing list