Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meeting will be on Thursday, 10 November (note new schedule of twice-weekly meetings) at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin ACTION ITEMS/HOMEWORK: 1. 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. 2. Recommendation #2: Staff to write up the recommendation to keep the Losing FOA functionality with flexibility on terminology and format. 3. Recommendation #3 -- WG members to review the language in the Implementation note and suggest improvements. See page 4 in the Working Document at: https://docs.google.com/document/d/1SaEV9vjiSZONjHvnXj3zbPVTTflDTo4WphZrbqDT... [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1SaEV9vjiSZONj...>. Notes: Transfer Policy Review - Meeting #64 Proposed Agenda 08 November 2022 1. Roll Call & SOI updates 2. Welcome and Chair Updates * The Contracted Parties (CPs) had a Summit last week so we had the week off. * We are starting the twice-weekly meetings this Thursday, 10 November to help us get through the public comments. * CP Tech Ops group met, including to talk about transfers: talking about the TAC and embedding information in it, such as the TTL and the IANA ID. It came down to looking at it from both sides and the benefits and risks. What benefit does it provide and what are the risks? It might expose a security risk. Too much work for the limited benefit. Other suggestion was to embedding the Gaining Registrar IANA ID in the TAC. Also discussion around including the ID in the information being sent to the Losing registrar in the pending transfer poll notice. Some support of that. Some discussion of giving the RNH the option to ACK or NACK the transfer – supported keeping that functionality. * Clarify: Understanding that the recordings are only available to the contracted parties, would be helpful for those engaged in those conversations to circulate those key points on transfers, particularly from the Tech Ops discussions. * Small Team on risk/threat vectors: The small team met to exchange and outline some text to provide to the group of the threat profile and how the elements we are discussing here meet the security requirements. One thing we put in that analysis is the presumed return of the mechanism currently called the “Losing FOA”. Included that functional mechanism in timing and form without calling it the same name. Calling it “Transfer Confirmation”. 3. Continue Discussion of Comments on Elimination of the Losing FOA – Recommendation 2 -- See Public Comment Review Tool for Recommendation 2<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt...> and Public Comment Working Document for Recommendation 2 [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1gyy9xfe0-ymW-...>. * Several people pointed out that the name “Losing FOA” seemed to be a misnomer. * Hesitant to bring this functionality back in, I really think we were on the right track with eliminating it. I prefer the idea I heard about putting a confirmation step in the TAC request stage. * Group discussed a 5-day window for the registrant to ACK/NACK. If nothing is done it automatically goes through. We want to keep the pending transfer period also? so we've lost the entire 'instant transfer' concept. * Question: Are there other options being considered, or has this been decided? Answer: In the comments received, they agreed that the functionality was useful to keep. The discussion was around where to keep it, but general agreement to keep it where it is now. If there isn’t agreement to change it to something else, the status quo stands – to keep that functionality. If there is no agreement either way the status quo stands. * The principles for the public comment review: In order for something different to move forward it needs to achieve consensus agreement; in absence of that then the status quo stands. * Haven’t discussed the option of a rollback in any case – that was saved for possible future discussion. Of course the TAC can be stolen between the provision and the use, so a rollback option would be helpful. * But no matter the process there would be more impact from a rollback then stopping the transfer before it starts. * Do they need a notice of the transfer being triggered, if they already got a notice of the TAC being requested and they then approved it and initiated the transfer? Why is notification of transfer trigger more useful? * The losing registrar is left with no recourse to support a customer where the domain was transferred out - or is at least significantly diminished in their ability to help their customer once the domain name is no longer at their cred. * If we can’t get consensus on the recommendation to get rid of the Losing FOA, then we need to keep it, but it can be in a slightly different form/name. * Jim: My recollection of the recent conversations is that I interpreted a lot of support for making sure the Transfer Confirmation remains (Losing FOA) because it is desired for business reasons. I want to emphasize “business reasons” because there is no security enhancement as long as you have both a 30 day lock down after transfer and have a claw back process (which is coming up next). Personally, I don’t see a technical reason for a “Losing FOA”. It is a change for users and the public comments reflect that people just don’t understand how it all works. So, the discussion as I heard it the past few weeks is that we want to be responsive to the public comments and registrar customers. * We’ve been discussing the Losing FOA for the past several weeks and the concerns raised in public comments without consensus on getting rid of it. Even the Tech Ops discussion supported the Losing FOA functionality but calling it something else. * Proposal from Roger: Write up keeping the Losing FOA functionality and the WG to bring it to their groups and discuss it. If there is no agreement for something else then the status quo stands. * The problem with rollback is it’s too late and also has too many dependencies. * Lock period and rollback don't necessarily address the concerns of the disruption of service that is enabled (potentially) while remediating a transfer that would have been halted by NACK. * Service disruption is true but that can be mitigated by having the rollback process move the DNS back “quick” while the details are sorted out over a bit more time. Or, you could require DNS coordination as part of transfer, but that opens the discussion to addressing the DNSSEC failures too, which are worse if a transfer was unintended. * There are benefits to all of the options but at what cost. The public comments agreed that we aren’t making it better by getting rid of it. * Options: 1) Rec #2; 2) Update the functionality with rationale and consensus agreement; 3) status quo. ACTION ITEM: Staff to write up the recommendation to keep the Losing FOA functionality with flexibility on terminology and format. 4. Continue Discussion of Notification of TAC Provision – Recommendation 3 – See Public Comment Review Tools for Recommendation 3<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt...> and Public Comment Working Document for Recommendation 3 [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1SaEV9vjiSZONj...>. d) Proposed edit Include additional elements required to be included in the “Notification of TAC Provision” such as: * An element that explains that the TAC will enable the transfer of the domain name to another registrar. * The deadline by which the RNH must take action if the request is invalid so that the registrar has sufficient time to NACK the transfer, where applicable (note that, at the time the RNH receives the “Notification of TAC Provision”, the TAC may have already been provided and the transfer command sent to the registry operator). * Required actions registrars must take (and by when) upon receiving notification by the RNH of an invalid request. Discussion re: “An element that explains that the TAC will enable the transfer of the domain name to another registrar.” * When we talked about notice last year, we expected registrars to do this – the question is whether we make it mandatory. * This seems to make sense to make some kind of specific language that we have to embed in the notice or point to language. Discussion re: “The deadline by which the RNH must take action…” * Is there a reason to have a deadline? * Can we get clarification from ICANN org on the comment? It is not on the TTL itself, it is with the RNH as to how much time they have – but might not be possible to do this. You don’t really know how long that might be. Is there a possibility to set an expectation with the RNH as to what is reasonable. This is a Compliance request to put in a timeline for the RNH so they have a reasonable time to NACK and unauthorized TAC provision. * Under our current recommendation it’s impossible to provide. There is no time before a TAC is usable. That is another time period that registries would be managing. This is time relative to the registry. The registry would have no way of enforcing that time since it doesn’t know when to start the timer. * Nothing the WG can do with this request. Discussion re: Required actions registrars must take (and by when) upon receiving notification by the RNH of an invalid request. * Where does this concept fit? Assumed this was something registrars would do. Should it be mandatory? * ICANN org: Why we requested this – Compliance noted that this was a reason why the registrar may deny a transfer. So, if the RNH NACK’d the transfer the registrar doesn’t have to stop the transfer. So the suggestion is that it should be mandatory for the registrar to stop the transfer if the RNH requests it. * Is this a problem today? * In Recommendation #20, the WG has recommended (in switching to MUST category) this recommendation should address this concern. e) Proposed edit ICANN org understands that notifications tend to be in the form of an email, and in general emails typically are not secure methods of communication. RFC9154 in subsection 7 of section 4.3, notes "The registrar's interface for communicating the authorization information with the registrant MUST be over an authenticated and encrypted channel." Thus, ICANN org suggests the WG consider updating the language in recommendation 3.2 to note "If the TAC has not been provided via another method of communication, this communication will include a secure mechanism (e.g. a link using HTTPS that requires authentication) to provide the TAC." This suggested language change complies with RFC9154. Potential next step: Strawman revision: If the TAC has not been provided via another method of communication, this communication will include a secure mechanism (e.g. a link using HTTPS that requires authentication) to provide the TAC. Discussion: * Intent of RFC9154 was that the TAC should not be sitting in email. * WG to consider the proposed revision and comment for discussion at the next meeting.