[DT-F] REVISED: Design Team F kickoff

[Gomes, Chuck]

I added a three responses below.

Chuck

-----Original Message-----
From: cwg-dtf-bounces at icann.org [mailto:cwg-dtf-bounces at icann.org] On Behalf Of David Conrad
Sent: Wednesday, April 08, 2015 9:11 PM
To: Jaap Akkerhuis
Cc: CWG DT-F
Subject: Re: [DT-F] REVISED: Design Team F kickoff

Jaap,

>> The current procedure is documented at a high level in SAC067, figure 
>> #1
> > (and its description) on pages 13 and 14. In the near term, the 
> > authorization step (step 3 in figure #1) can probably most simply be 
> > addressed by having ICANN instead of NTIA "push the button" to
>authorize
> > the change.
> 
>I was actually triggered by the phrase "architecture for publication of 
>the Root Zone" in Alan's mail. I read that as a slightly bigger task 
>(including root zone server operators etc.) then just the threeway 
>exchange we have currently.

My interpretation was that the focus of this Design Team was on the relationships that are directly impacted by the removal of NTIA. In my view that would be the IANA Function Operator and the Root Zone Maintainer relationships. However, I could be wrong...
[Chuck Gomes] That seems like a reasonable interpretation to me.

>> 1. Since no other party sees proposed changes until they are 
>> published,
> > the IANA Function Operator role can theoretically propose a change
>outside
> > of policy that will be published to the root Whois and/or root zone.
>
>Yes, and that brings the discussion about a last resort appeals panel 
>back.

As mentioned in a previous note, I believe an appeals panel is probably a reasonable requirement to recommend, however it obviously would only have impact after the fact.
[Chuck Gomes] It seems to me that one relatively simple way to deal with this would be to do the following: Once the IANA team have done all of their checks and before they submit the changes to the Root Zone Maintainer, they could send the details of the proposed change to the impacted registry operator asking them to confirm that the change is consistent with what was requested and does not violate any policy that they are aware of.  Any delay that this might cause would be in the control of the registry operator and should not be counted against IANA with regard to SLEs.  I asked on the list earlier today whether the IANA team already does this; if they do this wouldn't be much of a change if any.

It is probably worth noting that the way the current process works means that the Root Zone Maintainer is positioned to provide independent third-party intervention to operationally prevent a limited set of "out of policy" changes (specifically, requests that don't meet the policy relating to certain technical requirements). Back when I ran the IANA, the IANA Function Operator's technical checks and Root Zone Maintainer technical checks were somewhat different and there were cases where changes which passed the IANA Function Operator's technical checks were caught the Root Zone Maintainer's technical checks (my understanding is that the community has since required the technical checks performed by both the IANA Function Operator and the Root Zone Maintainer to be the same). This may have prevented some problems for TLDs.
[Chuck Gomes] I think it is important that everyone understand what is meant that " the Root Zone Maintainer is positioned to provide independent third-party intervention to operationally prevent a limited set of "out of policy" changes (specifically, requests that don't meet the policy relating to certain technical requirements)."  I would probably not use the word 'policy' hear but rather just say 'technical requirements'.  Hopefully everyone understands that the Root Zone Maintainer would not be able to identify compliance with non-technical policies coming from the policy development side of ICANN in the GNSO and ccNSO.

>I do think that not all changes will have a severe impact.

True, however it is difficult to quantify potential impacts. For example, if a name server change is made, the impact is quite different if the new name server pointed to doesn't respond to the TLD queries vs. responding to the TLD queries with the address of servers that facilitate man-in-the-middle attacks.

> > 2. Since the Root Zone Maintainer role holds the DNSSEC-signing key 
> > and publishes the signed root zone, they have the theoretical 
> > ability to unilaterally make out of policy changes to the root zone.
>
>Yup, as is now.

However, in contrast to #1, there is no independent third-party intervention possible here. The only current option is after-the-fact remedy.

>> 3. It is possible for a single party involved in root management to 
>> deny
> > service at each interface between parties in the existing system, e.g.:
>
> > A) IANA Function Operator refusing to process requests from the TLD 
> > manager;
> > B) the Root Zone Administrator refusing to authorize changes 
> > submitted
>by
> > the IANA Function Operator; or
> > C) the Root Zone Maintainer refusing to implement changes submitted 
> > by
>the
> > IANA Functions Operator and authorized by the Root Zone Administrator.
>
>So we should look to what would be happening now in these cases and 
>then see that similar measures will be taken.

Currently, my understanding (which may be wrong):

3A is ultimately mitigated by NTIA declaring ICANN in breach of the IANA Functions contract 3B is discouraged by potential negative political repercussions.
3C is ultimately mitigated by NTIA declaring Verisign in breach of the Cooperative Agreement

Obviously, in the future, 3A will need to be dealt with in some way, 3B goes away, and I can't speak to 3C. Perhaps Chuck can.

Regards,
-drc