[DT-F] REVISED: Design Team F kickoff

[Alan Greenberg]

At 08/04/2015 05:48 AM, Jaap Akkerhuis wrote:
>  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.

For the record, my intent was that I was referring to the 3-way 
communications as transformed to 2-way without the NTIA (plus 
anything new we introduce!).  Certainly following that, the zone file 
would be made available to the root operators, but I was not 
envisioning the mechanics of that changing at this time.

Alan


>  >
>  > 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
>_______________________________________________
>cwg-dtf mailing list
>cwg-dtf at icann.org
>https://mm.icann.org/mailman/listinfo/cwg-dtf