[DT-F] REVISED: Design Team F kickoff

[Cheryl Langdon-Orr]

I think Independant Auditor is a good thing to look at and discuss, it of
course is well inside my own comfort zone  of working with, gaining
accreditation for and maintaining QAS  for our ISO9000/14000 series
clients, HACCP processes and NATA accredited labs that is more akin to my
'day job' so I guess no real surprises there...


*Cheryl Langdon-O**rr ...  *(CLO)

about.me/cheryl.LangdonOrr
[image: Cheryl Langdon-Orr on about.me]
  <http://about.me/cheryl.LangdonOrr>


On 8 April 2015 at 19:48, Jaap Akkerhuis <jaap at nlnetlabs.nl> 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.
>
>  >
>  > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-dtf/attachments/20150408/c8515f53/attachment.html>