[DT-F] DT-F Review

[Alan Greenberg]

I have reviewed all of the traffic on this list and have extracted a 
summary of the issues identified below.

The important question is what are we going to try to deliver for the 
review of the CWG later this week.

The description of our task from the etmplate is:

>Removing the authorization function as per the recommendations of 
>DT-D implies changing the architecture of systems and processes for 
>making changes to the Root Zone and the Root Zone Whois database 
>which are at the heart of all key IANA functions.
>
>As such DT-F should review the high level architecture of the 
>processes and systems for making changes to the Root Zone, the Root 
>Zone Whois database, and the Root Zone DNSSEC key management 
>architecture, to identify any issues, and if they exist, recommend 
>solutions. Such solutions should be aligned with the overall 
>objectives and recommendations of the CWG and in particular, the 
>removal of the authorization function while both maintaining the 
>security, stability, and resiliency as well as improving the 
>transparency and accountability of Root Zone management.

(I note that we have not discussed DNSSEC key management. My 
understanding is that the NTIA plays no role in that other than in 
their role of approving all DNS changes. If that is incorrect, we 
need to address this issue.)

NTIA's role has been to authorize DNS RZ changes, and as per DT-D, 
the recommendation is that this authorization is no longer need. 
Accordingly, from a minimalist point of view, all we need to 
recommend is that post transition, the RZ Maintainer no longer needs 
to await NTIA approval before publishing a new Root Zone File.

However, our charge is somewhat wider than that, and asks us to 
identify any issues and if the exist, recommend solutions. It does 
not explicitly restrict this to issues directly related to the 
removal of the NTIA Authorizations (although perhaps this should be 
inferred!). And we have identified one aspect of the NTIA 
Authorization removal - the unknown influence that the POTENTIAL for 
NTIA authorization refusal might have minimized some untoward action 
(just as the CWG  has endlessly discussed how the threat of removing 
the IANA function from ICANN may have had an influence).

In 4 days, along with the other workload many of us are committed to, 
we are clearly not going to recommend solutions for any of the 
potential problems we have identified.

So the question we need to answer is to what extent do we wish to 
even slightly want to flesh out the potential issues we have 
identified, documenting them for future action, either prior to 
completing the transition proposal, or as future work. Identified topics:

- Robustness - reduction/elimination of single points of failure:
         - potential for accidental or malicious changes or omissions 
within IANA
         - potential for out-of-policy changes within IANA
         - potential for accidental or malicious changes or omissions 
within the Root Zone Maintainer
- whether we need to replace the NTIA, and if so how, in discussions 
regarding substantive Root Zone changes (past examples include DNSSEC 
and IPv6 deployment)
- the possible need to ensure that power/responsibility to 
modify/update the root zone is not concentrated in a single entity 
(potential problems that already exist to some extend as identified 
by the first bullet)
- to what extent can we or should we increase the transparency of the 
IANA RZ operation (such as publishing changes prior to their being 
published by the RZ Maintainer
- Is additional or different security required in the age of cyber-terrorism?
- Potential for any changes to the process slowing down the speed of 
RZ change implementation.

Alan

==========================
Extracts (mostly) of earlier e-mails used to construct above list:

Accountability: all activities associated with root management must 
be unambiguously attributable to an authorized actor and that actor 
must be held responsible for those activities.

Accuracy: all changes must be implemented with no errors.

Auditability: all activities that impact the public that are 
performed by root management actors must be recorded.

Improvability: root management must be able to evolve to meet the 
changing Internet.

Predictability: there should be no surprises associated with root 
management processing.

Security: no unauthorized entity should be able to make a change and 
only the changes requested are the ones that are implemented.

Simplicity: the root management systems must be as simple as possible 
("but no simpler").

Stability: the processes related to root change requests should be 
consistent over time with any changes well documented and introduced 
with appropriate lead time.

Standards-based: interactions between actors in root management 
should be based on open standards; no proprietary mechanisms or 
interfaces should be used between actors.

Transparency: changes made as part of root management, and the 
policies upon which they are based, must be visible to interested stakeholders.

Resiliency: it must be possible to quickly recover from a failure in 
any part of the system (even if the failure remains present).

Robustness: single points of failure must be minimized or mechanisms 
must be in place to mitigate their impact.

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.

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.

"power/responsibility to modify/update the root zone is not 
concentrated in a single entity"?

Use of an independant auditor.

I (Chuck) personally think that the technical checks that both the 
IANA operator and the Root Zone Maintainer do are very good.  So in 
my thinking, the kind of mistakes we may want to focus on are 
mistakes relating to policy implementation.  Is there a change to the 
process that would increase the chances of catching those before they 
are implemented without slowing down the process significantly?  I 
confess that I don't have a solution but I think that may be where we 
want to focus our attention with regard to mistakes.

Future changes should not slow down RZ management processes.

Changes that are caught now tend to be identified after they are 
live. If the changes were intentional, an appeal process will be 
available, but the changes will still be live. Do we need an 
injunction-like process to halt disputed changes before they are 
live, and to we need a transparency change to ensure that affected 
parties can learn of the changes before they go live? Presumably (or 
possibly) the publication and opportunity to delay would not apply to 
regular changes requested by the registry.

NTIA being in the loop did not result in their blocking any changes, 
but it is impossible to say whether their being there prevented 
problematic changes from being attempted.

One solution I (Alan) have heard is that IANA makes its revised zone 
file available to an auditor, and the RZ maintainer does the same, 
and the zone file cannot be published until the auditor confirms that 
they match. That confirms that the RZ maintainer does not make any 
mistakes. It does not verify that IANA did not make a mistake once a 
change is confirmed by the registry.

Involvement of NTIA in non-steady-state-operation-issues must be 
considered and possible replaced. Past issues have included the 
implementation (including timing) of DNNSEC and IPv6 deplyment. 
Perhaps we need to formalize and document the methodology used to 
make changes to the RZ (including who needs to be in-the-loop on such 
process or technology changes).

Impact of budget changes on IANA and what mechanism will there be to 
control these (presumably covered by DT-O).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-dtf/attachments/20150413/067481d2/attachment-0001.html>