[DT-F] REVISED: Design Team F kickoff

[David Conrad]

Jaap,

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

However, I'm unsure this addresses the underlying need. Answering Alan's
question:

>>- problems (or potential problems) with the current process;

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

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.

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.

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.

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.

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

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/20150407/c1fe3e47/smime.p7s>