[DT-F] DT-F Review

[Gomes, Chuck]

Thanks Alan.  In my opinion and I do think that we need to at least list the "the potential issues we have identified".  You are correct that we do not have time to develop and propose solutions by Thursday, but I think it would be irresponsible for us to not communicate further issues that we think may require further work before the transition occurs.

My compliments on your good summary of where we are at and identifying the issues that have been identified.  Once we define our main task and identify our action items to accomplish that I think your list of other issues would be good to go through one by one at least at a high level to discuss our positions on each one.

Chuck

From: cwg-dtf-bounces at icann.org [mailto:cwg-dtf-bounces at icann.org] On Behalf Of Alan Greenberg
Sent: Monday, April 13, 2015 12:15 AM
To: CWG DT-F
Subject: [DT-F] DT-F Review

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). <http://en.wikipedia.org/wiki/Insider_threat).%A0> 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/44610b3d/attachment.html>