Dear TPR WG members,
Please find below the notes and action items from today’s meeting.
The next meeting will be on Tuesday 18 October at 16:00 UTC.
Best regards,
Emily, Julie, Berry, and Caitlin
ACTION ITEMS/HOMEWORK:
- ACTION ITEM: Staff to coordinate with WG members on a Doodle to select a time starting the first week of November for recurring weekly meetings on Thursdays.
- ACTION ITEM: 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.
Notes:
Proposed Agenda
11 October 2022
1. Roll Call & SOI updates
2. Welcome and Chair Updates
- With the schedule we’ve been looking at probably early next year we’ll be going to Council for a Project Change Request to extend our timeline to allow for more time to review public comments.
- Also need to increase meetings to two per week – probably Thursday in addition to Tuesday. We’ll coordinate with WG members on timing.
- Doubling up on meetings is the only way to come close to finishing our Phase 1a work on time – still highly probable that we’ll miss our milestone date even with doubling up meetings.
- Hypothetically if we needed 3 months to complete our Phase 1 work, but the main reason for a Project Change Request is because of the potential impact on other work.
- When we complete the Phase 1 work, we aren’t done – we still have Phase 2. We are already committed to work well into 2024. We are getting into a pay me now or pay me later situation.
- With respect to the Project Change Request, the original plan was optimistic. We are starting to see signs that some of the topics in Phase 2 have some element of risk that could affect our Phase 1 work
– consider whether the Project Change Request should acknowledge that risk.
- Bottom line is that we are severely behind schedule and need to catch up.
- Leadership recommends going to 2 days per week starting in November and going through the end of the year.
- With so many tie-ins to Phase 2, give Phase 1a and b Final Report to Council but advise the Council not to take action on it. So Phase 1 and 2 recommendations would be considered as a package.
ACTION ITEM: Staff to coordinate with WG members on a Doodle to select a time starting the first week of November for recurring weekly meetings on Thursdays.
3. Recap of ICANN75 Discussion
- A lot of the discussions were around Losing FOA and also Gaining FOA.
- We came up with several possibilities but sounded like we didn’t want to get rid of the Losing FOA completely – preserve the ability to deny a transfer in flight – a type of Losing FOA.
- Discussed 5-day window to NACK a transfer request – would the notification to the registrant be mandatory or optional?
4. Continue Discussion of Comments on Elimination of the Gaining and Losing FOA – Recommendations 1 & 2
See pages 12-18 of the Working
Group’s Phase 1A Initial Report [itp.cdn.icann.org] and re-review the following:
Discussion:
- One option proposed was for the Gaining Registrar to set a TAC – but this would mean contacting the registry? Would there then be multiple TACs? Or a limit of one TAC? Seems like a huge operational
issue.
- Gaining Registrar would have to set the TAC at the Registry. Is there a way to get consent from the registrant beforehand.
- As a reminder, the proposal starts on page 11 here:
https://itp.cdn.icann.org/public-comment/proceeding/Initial%20Report%20on%20the%20Transfer%20Policy%20Review%20-%20Phase%201(a)-21-06-2022/submissions/Leap%20of%20Faith%20Financial%20Services%20Inc./LEAP-comments-Transfers-Phase1a-20220814-FINAL-15-08-2022.pdf
- WG needs to decide what they are going to do with this proposal. Need to identify how this might work, or not.
- Don’t need to take the proposal as one entity.
- Should we add a 'verification' requirement for TAC release? Meaning, when requested, instead of sending the TAC, the losing Registrar notifies the registrant of the request and requires confirmation to
release the TAC. This gives the registrant a way to deny the TAC request.
- What problem are we trying to solve? This proposal is a radically different solution. Think that we have addressed the concerns he’s identified, but let’s confirm that in additional rationale. For
example, the keystone issue is access to the account at the registrar/reseller.
- Key component of the proposal is to give the registrant the ability to deny a transfer in a 5-day window before it occurs – the ability that they no longer have in our recommendations.
- Should separate the proposal from the Losing FOA.
- From the industry perspective it is impractical to implement. Should focus solely on the Losing FOA.
- Frankly, I don’t see any significant benefit to requiring a 5 day period before the transfer TAC, nor do I see any significant benefit to a 5 day transfer request. I certainly don’t object to either
of these things but the benefit seems dubious to me with cornerstone of access to registrar/reseller account and the 30 day lock down after transfer (with notifications by losing registrar to RNH).
- Reinforce the key point that we don’t have to judge this proposal, but look at why he is making the proposal and asking if we have considered those issues.
- In the new system, there is no window for the registrant to NACK the transfer. Is there another way we can do this notification?
- Looking at the Leap of Faith proposal, should something like this go to Tech Ops? Analyzing whether it improves security? Does it make sense.
- In looking back at the proposal for the PTID – that was intended to solve the problem space of the TAC being vulnerable to theft. There are different goals with elements of this proposal.
- Don’t think it’s a good idea to take this to Tech Ops.
- I’m sorry but I disagree with the path of evaluating his proposal. We should be focused on whether or not we have addressed the concerns he believes have not been addressed. If they have, we’re done,
move on. if not, then we can consider whether we want to change something we’re doing or consider his proposal directly.
- Should default to the most modest changes we can make. Could be worthwhile for Tech Ops to take this up – they will be meeting in a few weeks.
- Can we table this until we see what is in Phase 2, such as rollbacks?
- On the issue of the Losing FOA and keeping that functionality, observation that with respect to the proposal the functionality is covered by the 30-day lock down.
- 5-day denial stops it, the 30-day lock is not equivalent. 5-day window serves a different purpose. To get the domain back after transfer would involve a lot of people/work. The DNS has changed. Not
the same as the registrant denying a transfer.
- Right now the window is 10 days; in reducing to 5-days we lost some registrant control.
- Without being a technical specialist, I have problems to understand why we should change at the model. First, I agree that access to the losing control panel is the key challenge (and cannot be defined
in a PDP). Secondly - the model where the transfer start by getting the TAC from the Losing Registrar, is well understood and also been used by ccTLDs. Thirdly - we have no statistics indicating there is a high volume of hijacked domain names.
- However, I like what Rich is saying. While 5 day pre-transfer is not 100% equivalent to the 30-day lock down, I do think that the system as a whole covers what needs to be covered. That’s what we need
to document to address George’s concerns. His concerns are valid.
- Questions are whether you make this mandatory or optional for registrars, and/or optional for registrants.
- I think we have to document that TAC request ACK/NACK better to address his concerns.
- What we are missing/gaps – and hence the need for the proposal – 1) ability for the registrant to NACK a transfer and 2) ability for the registrant to know where the domain name is being transfer.
- Need to be very specific about whether it is optional or not for Compliance to do their job. They can enforce with “MUST” but not with “MAY”.
- We didn’t eliminate the Losing FOA, we moved it earlier in the process when the TAC is created. There is still an option to NACK if you think the request is not legitimate.
- Ask ourselves what problem we are trying to solve. Are we trying to solve the transfer problem or the operational processes if the registrant got it wrong. If an account is hacked is this a problem
we have to solve?
- Wonder if it’s useful for a subset of the WG to brainstorm the different attack vectors that we’ve seen and document how to address them (or not in scope).
- Even if we put additional NACK options, if the registrant’s account has been hacked then the domain is gone – there’s nothing to be done. Need additional security for that. For example, email compromises
happen all the time and we can’t solve for that.
- Seems that Jody and Jim would be willing to catalog the risk vectors and how we are solving for them, or not.
- Volunteers: Jothan Frakes, Jim Galvin, Jody Kolker, and Rick Wilhelm.
- Once the TAC is provided there is no ability for the registrant to get it back. Could fix this by not immediately sending the TAC, but sending a notification first. Need to address this loss that registrants
are feeling.
- Note that Rick, Jody, Jothan, and Jim have been back channeling. They will all be at CPS in two weeks. They’re going to find some time to meet and with any luck knock most of this out.
- Roger: We should try to document a proposal for Losing FOA with a smaller window for the NACK. A notification is sent as soon as the TAC/Transfer is requested, registrant gets X days (should be
less than 5 days to fit next req) to approve/deny and Registrar still must provide TAC within 5 days of original request.
ACTION ITEMS: 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.
AOB