Date: Thu, 28 Mar 2024 19:57:08 +0000 (UTC) Message-ID: <2084429314.1201.1711655828794@community1.lax.icann.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1200_670538178.1711655828792" ------=_Part_1200_670538178.1711655828792 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The call for the Transfer Policy Review PDP Working Group <= /span>will take place on Tuesday, 25 October 2022 at 16:00 UTC for = 90 minutes.
For other places see: https://tinyurl.com/3j5dsa3f
PROPOSED AGENDA
BACKGROUND DOCUMENTS
TPR - Timeline (conceptual) - Visio-TPR_P1_Timeline_v0.1.pdf
RECORDINGS
Notes/ Action Items
ACTION ITEMS/HOMEWORK:
1. ACTION ITEM: Jothan Frakes, Jim Galvin, Jody Kol=
ker, 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. ACTION ITEM: For Recommendation #3 -- =
WG members to review the language in the Implementation note and suggest im=
provements. See page 4 in the Working Document at: https://docs.goo=
gle.com/document/d/1SaEV9vjiSZONjHvnXj3zbPVTTflDTo4WphZrbqDTmxU/edit?usp=3D=
sharing.
Notes:
1. Roll Call & SOI updates
2. Welcome and Chair Updates
- No call next week (01 November) due to the CPH Summit, st= arting up twice-a-week meetings the following week (with 10 November).
3. Continue Discussion of Comments on Elimination of the Losing FOA =E2= =80=93 Recommendation 2 (see Public Comment Review Tool and Working Documen= t [docs.google.com])
- Proposal based on Public Comment adds complexity to the p=
rocess.
- Gives RNH them a window of time to NACK =E2=80=93 either in =
a 5-day window or shorter. As today, it is an auto-ACK process; if no=
NACK it will be ACKed.
- Issue with the proposal: The Losing FOA =E2=80=93 there is n=
o pending transfer. Doesn=E2=80=99t really do anything because the tr=
ansfer has already gone through. Putting them back in the process con=
tinues to do nothing. Like the option to NACK up front because the mi=
nute the TAC is released the transfer is live.
- The idea is that the orange box goes back to what it is toda=
y.
- The RNH must inform the Gaining Registrar about the TAC to s=
tart the transfer.
- So we have to now define a pending Transfer period then.
- Issue is that the TAC is vulnerable for up to 14 days.  =
;If you put the NACK at the end the RNH can still stop it.
- Clarification: regarding the rationale for what was done wit=
h the TAC =E2=80=93 the security of the AuthInfo code in the current system=
was a message =E2=80=93 long period of vulnerability; changes in the Initi=
al Report have addition security measures when setting the TAC.
- If we are going to recommend additional requirements also se=
e if we can address the issue that when a TAC is requested it is not automa=
tically generated. You can bypass the problem of the Losing FOA by ge=
tting an ACK/approval when the TAC is requested.
- Some comments noted that there is a window from when the TAC=
is provisioned/communicated when the TAC is given to the Gaining Registrar=
the Registry processes it and it is gone. The functionality that giv=
es the RNH the ability to stop the transfer once the Gaining Registrar is k=
nown is critical to some commenters. There still is the problem of TA=
C vulnerability once provisioned and putting the NACK at the end (once the =
Gaining Registrar is known) addresses this problem.
- If an account is breached, all options are out the window, a=
s it's already breached, regardless of which process we decide.
- Suggested 'step' simply adds a verification option, which gi=
ves a Registrant a chance to deny. Since there's no room to deny later in t=
he process.
- The losing FOA is a warm fuzzy option at this option. =
My take away from the public comment is that people don=E2=80=99t really un=
derstand how the security profile is implemented and how what we have is ac=
tually better than what was had before. I=E2=80=99m hoping that the t=
ext that the small team will propose will make this more clear and if so we=
can add it to the document and it will help others too.
- If this is solving extreme scenarios not sure it is worth th=
e effort.
- Not sure about the 'adding dev cycles' since we're already s=
ending a 'notice of TAC provision' this simply modifies that so instead of =
delivering the TAC initially, it informs the registrant of the request and =
how to deny it, if ignored it will be sent within the 120 hour window.
- If we move it forward from where it is today, it will requir=
e more development.
- Do we need to see what the small team will give us before we=
make a decision? The small team is looking at just the different thr=
eats that can occur and how they are solved or not.
- Compliance data regarding unauthorized transfers. Transfer c=
omplaints previously provided to the WG can be found here: https://com=
munity.icann.org/display/TPRPDP/Metrics
- If we move the NACK to the front everyone has work to do, or=
if we leave it where it=E2=80=99s at we still get the security advantage w=
ithout the extra work.
- Reminder, Registrars will still have to educate their custom=
ers on the new process regardless.
- Not sure how At-Large will address it, but in discussion in =
the CCWG is that we want as secure a process as possible, without being com=
plex or lengthy, but this doesn=E2=80=99t lie in the policy but in the regi=
strar processes. We have to identify what we initially agreed in the =
WG in the preliminary recommendations was a great step forward.
- BC/Zach will get back after consulting with his group.
- The issue is not whether this functionality should exist or =
not, even if some think it=E2=80=99s fluffy, just where it should happen/li=
e in the process --- beginning or where it is now.
4. Continue Discussion of Notification of TAC Provision =E2=80=93 Recomm= endation 3 (see Public Comment Review Tool and Working Document [docs.go= ogle.com])
- One of the considerations for Recommendations #3 and #4 i=
s whether we will keep these notifications. If we assume that =E2=80=93 reg=
ardless of Recommendation #2 =E2=80=93 then we can dive into the specifics.=
- Recommendation #3 has to exist regardless of whether we reta=
in the Losing FOA.
- Public Comments Review:
o First few are about the Losing FOA.
o About the tech contact being an important recipient -- that =
was assuming that contact would receive the notice of TAC provision (not th=
e TAC). Question of who that contact would be =E2=80=93 admin contact=
is going away. Having a database of additional contacts is a risk.
o The principle of notifications is essential =E2=80=93 when t=
o notify either at provision or at request =E2=80=93 it depends on how far =
apart are there two steps. If there is a gap then there should be two=
notifications. The second part is whether you should notify more tha=
n one person =E2=80=93 from a security perspective it would be good to have=
more than one notification, but not mandatory =E2=80=93 SHOULD and not MUS=
T.
o If the group changed course and sent the notification to mul=
tiple contacts, the notice would have to be distinct from the provision of =
the TAC itself.
o Having an optional additional contact might be helpful, but =
having the contact on file doesn=E2=80=99t add anything.
o Adding contacts who aren=E2=80=99t customers sounds a comple=
x issue for GDPR. The current recommendations don=E2=80=99t preclude =
from doing this. Or could be optional but not required.
o What if one contact NACKs the transfer and one ACKs it? &nbs=
p;Only one should get the option to NACK/ACK.
o Does this need to be policy?
o Summary: Leave it as a MUST for notification to the RNH and =
leave the other options out of the policy.
o Number of comments about how the recommendations don=E2=80=
=99t address a customer using a privacy/proxy service. Staff drafted =
text for an implementation note:
Potential next step: Strawman revision:
Recommendation 3: The working group recommends that the Registrar of Rec= ord MUST send a =E2=80=9CNotification of TAC Provision=E2=80=9D to the RNH,= as listed in the registration data at the time of the TAC request, without= undue delay but no later than 10 minutes after the Registrar of Record pro= vides the TAC.
Implementation Note: For the purposes of sending the notification, the R= egistrar of Record should use contact information as it was in the registra= tion data at the time of the TAC request. In cases where a customer uses a = Privacy/Proxy service, the Registrar of Record should send the notification= directly to contact information associated with the underlying customer wh= ere it is possible to do so
o Question: Should this only refer to Proxy service? Proxy =
service is RNH, whereas for Privacy service, the underlying customer is RNH=
.
o No registrar would send the TAC to the proxy service.
o My concern is that the proxy service should not be doing the=
transfer- it should be the underlying customer/domain registrant.
o Do we need the implementation note?
o Not sure the distinction between privacy and proxy is necess=
ary if you are talking about the underlying customer.
o Think what we are saying is for the recommendation we can st=
rike out =E2=80=9Cas listed in the registration data at the time of the TAC=
request=E2=80=9D. If we have an Implementation note we could improve the l=
anguage to call out the issue of the underlying customer is known.
o If keeping the note, we still have to realize that Registrar=
s may not have access to underlying data.
ACTION ITEM: For Recommendation #3 -- WG members to review the l= anguage in the Implementation note and suggest improvements. See page= 4 in the Working Document at: https://docs.google.com/document/d/1SaEV9v= jiSZONjHvnXj3zbPVTTflDTo4WphZrbqDTmxU/edit?usp=3Dsharing.
For next meeting =E2=80=93 review comment from ICANN org: =E2=80=9CInclu=
de additional elements required to be included in the =E2=80=9CNotification=
of TAC Provision=E2=80=9D such as:
* An element that explains that the TAC will enable the transfer of the dom=
ain 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 appli=
cable (note that, at the time the RNH receives the =E2=80=9CNotification of=
TAC Provision=E2=80=9D, the TAC may have already been provided and the tra=
nsfer command sent to the registry operator).
* Required actions registrars must take (and by when) upon receiving notifi=
cation by the RNH of an invalid request.=E2=80=9D
6. AOB -- Work Plan for Reviewing Public Comments =E2=80=93 see attached= and below:
- Suggestion is to go through the recommendations sequentia=
lly.
- Will adjust the work plan as we go after each meeting.
- Try to wrap up the public comment review by the end of the y=
ear.
Work Plan
25-10-22: Meeting #63 - Review of public comments for Phase 1A - Recs #2, #=
3, #4 TPR WG 10/25/22 In Progress PC review
08-11-22: Meeting #64 - Review of public comments for Phase 1A - Recs #3, #=
4, and Question for Community Input on Rec #4 TPR WG 11/08/22 Not Started P=
C review
10-11-22: Meeting #65 - Review of public comments for Phase 1A - Recs #5, #=
6, #7 TPR WG 11/10/22 Not Started PC review
15-11-22: Meeting #66 - Review of public comments for Phase 1A - Rec #7, #8=
TPR WG 11/15/22 Not Started PC review
17-11-22: Meeting #67 - Review of public comments for Phase 1A - #9, #10, #=
11, #12 TPR WG 11/17/22 Not Started PC review
22-11-22: Meeting #68 - Review of public comments for Phase 1A - #13, #14, =
and Question for Community Input on Rec #14 TPR WG 11/22/22 Not Started PC =
review
29-11-22: Meeting #69 - Review of public comments for Phase 1A - Question f=
or Community Input on Rec #14, [no comments on #15], #16, #17 TPR WG 11/29/=
22 Not Started PC review
01-12-22: Meeting #70 - Review of public comments for Phase 1A - Rec #16, #=
17 TPR WG 12/01/22 Not Started PC review
06-12-22: Meeting #71 - Review of public comments for Phase 1A - Rec #18, #=
19 TPR WG 12/06/22 Not Started PC review
08-12-22: Meeting #72 - Review of public comments for Phase 1A - Rec #20, #=
21, #22 TPR WG 12/08/22 Not Started PC review
13-12-22: Meeting #73 - Review of public comments for Phase 1A - Charter Qu=
estions and Report Text; Additional Suggested Topics and Proposals TPR WG 1=
2/13/22 Not 15-15-12-22: Started PC review
20-12-22: Meeting #74 - Review of public comments for Phase 1A - WG Process=
es and Modalities; Additional Input TPR WG 12/15/22 Not Started PC review
22-12-22: Meeting #75 - Review of public comments for Phase 1A