[DT-F] REVISED: Design Team F kickoff

[Jaap Akkerhuis]

 David Conrad writes:

 > 
 > >Given that Design Team D proposes to do away with the NTIA
 > >authrization step[2] and that the CWG takes accept it seems to me that
 > >the task is merely describing the changes needed in the current
 > >procedure.
 > 
 > 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.

 > 
 > Some examples of potential/theoretical problems in the current system I
 > can think of:

Most of these practical problems do actually already exists.

 > 
 > 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. I do think that not all changes will have a severe impact. But
changes which looks like (re-)delegations might indeed requite more
examinations then ther is now.

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

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

 > 
 > 4. Checks and balances between the IANA Function Operator and Root Zone
 > Maintainer roles are largely implemented via contractual obligations with
 > the Root Zone Administrator.
 > 
 > Note that #1, #2, and #3 can be either accidental (mistakes or failures)
 > or malicious (via attacks or an "insider threat" --
 > http://en.wikipedia.org/wiki/Insider_threat).  In many "critical systems"
 > cases I'm aware of, these kinds of risks dealt with by having some sort of
 > "two person rule" (http://en.wikipedia.org/wiki/Two-man_rule).  Obviously,
 > as we do not have a "two person rule" now, we (the Internet's users) rely
 > on #4 to mitigate the risks associated with #1-#3. It's probably worth
 > noting that in a worst case, any remedy would be after the fact.

Yes, after the fact and you wat to be able to undo these (mistakes or
failures) as quickly a possible to prevent more damage.

 > 
 > >>- Current NTIA operational involvement and if/how this needs to be
 > >>replaced or compensated for.
 > 
 > Removing NTIA from the operational aspect of the Root Zone Administrator
 > role is relatively straight forward as mentioned above. However,  the
 > removal of the NTIA contractual obligations may suggest a need for greater
 > reliance on built-in mechanisms to ensure appropriate principles are met.

Given that everything is up in the air, I wonder (thinkig out looudly)
whether currently we can point to these problems and point out that in
future a better solution needs to be found, For now some ad-hoc
mechanism (ICANN, Independent Auditors) could replace the NTIA
operational role.

	jaap