[DT-F] REVISED: Design Team F kickoff

[David Conrad]

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

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

Regards,
-drc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4673 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/cwg-dtf/attachments/20150409/7dce4af1/smime.p7s>