[DT-F] REVISED: Design Team F kickoff

[Alan Greenberg]

At 08/04/2015 09:10 PM, David Conrad wrote:

>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...

That was my original intent.


> >> 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.
>
>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.
>
> >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.

Until the "separate but parallel process" is initiated, we have no 
choice but to presume that 3C stays as is. Or at least is not 
something we can address.

Alan


>Regards,
>-drc
>
>
>_______________________________________________
>cwg-dtf mailing list
>cwg-dtf at icann.org
>https://mm.icann.org/mailman/listinfo/cwg-dtf