Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt

[Antoin Verschuren <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 10-07-13 15:19, Edward Lewis schreef:

> These are concerns that are not well defined and I've off and on
> tried to find a more rigorous framework from which to hang them.
> But Antoin sums up the "operator" view that - the world is more
> complicated than a simple solution away from completeness.

I've given Ed's words a really good thought, and slept a night over it.
I think the reason why some of us don't feel comfortable  with many of
the assumptions in our requirements is because we try to avoid a
framework we as technicians are not comfortable with, and that is trust.
Trust is more a layer's thing. As sysadmins we expect trust is
evident, and we all try to do "the good thing" so why would anyone
doubt us at some point. We don't realize trust is something that needs
to be gained by convincing somebody else to express it, it cannot be
self-proclaimed.

In the CDS discussion, we have already identified some situations
where even for us it is evident CDS does not work, and I'm trying to
translate that to a more generic definition in stead of "a gut feeling".
We've said that CDS, or CSYNC to be more generic, is not useful for
bootstrapping a delegation, i.e. registering a delegation for the
first time. It also does not work when the delegation path is broken,
f.e. when a key is compromised. And the most recent case is when one
of the roles in the process of maintaining a delegation changes. These
are all situations where initial trust needs to be build-up,
re-established, or re-initialized. CSYNC and CDS try to solve a
problem for a static operational state where technical information
needs to travel from child to parent to maintain that relationship.
And in that static state, it can work fine, and as Ed, I'm all for it.

So defining where CSYNC cannot work because of a lack of trust is the
first thing we need to do, and I'll give it a try:

1. Bootstrapping
The initial appointment of trusted roles in a delegation must be set
up over an out-of-bound channel, and therefor CSYNC cannot be used for
bootstrapping the initial delegation. So registration of the initial
technical parameters of a delegation must take place over an
out-of-bound secure channel. In simple words: Registering a domain for
the first time is done over EPP, not over DNS.
2. Re-bootstrapping
When one of the roles in the out-of-bound channel is changed, a
renewed trust must be expressed. The roles we know of that are present
in the out-of-bound channel are:
Registry-Registrar-Reseller-Registrant-DNS operator-key maintainer.
When one of these roles is changed to another entity, the delegation
needs to be re-bootstrapped over the out-of-bound channel for everyone
in that out-of-bound channel to be aware of it's new trust
relationship. In simple words: Changing a Registrar, Registrant,
Reseller, DNS-operator, or DNSSEC key maintainer for a zone cannot be
communicated over DNS, but it must use EPP.
3. Re-initialising a bootstrap
When a (secure) delegation fails, because of a lame delegation, key
compromise, or misconfiguration of any other technical parameter
causing the delegation to break or trust to be absent, restoration of
that trust needs to be established over the out-of-band channel. In
simple words: Emergency keyrollovers in case of key compromise, or
restoration of lame delegations cannot use DNS but must be done over EPP.

So CDS and CSYNC only have a use case for the maintenance of a static
delegation, and I really think this is not a waisted effort. I
personally would like to solve the more generic question of a
technical parameter to travel from child to parent as in the CSYNC
draft, as opposed to the only one use case one scenario of getting a
DS renewed at the parent as focused on in the CDS draft.

> That the child has no information about the parent

I don't have an answer for Ed's question about how to identify the
entry point at the parent for a child.
I really liked the concept of a "parental agent" in the CDS draft, but
that is a role definition in the administrative out-of-bound channel.
I really think we need to separate roles in the administrative and
technical model for a delegation for our concepts to work.
So "parental agent" is an excellent term to describe who is above you
in the administrative out-of-bound channel, but it does not have any
synonym or responsibility in the technical DNS model.
I know we invented this because it's hard to change the ICANN lawyers
minds that registrars are responsible for administration and
bootstrapping technical parameters for a delegation only. Perhaps when
we add the list above to the responsibility of registrars, and clearly
define that CSYNC or CDS is for technical maintenance of a static
delegation, we can convince them that it is ok for a (DNS) child to
talk directly to the (DNS) parent, and then identification of a parent
can fairly easy be done in the DNS.

Thoughts, additions?

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: [phone]  M: [phone]
Mailto: [e-mail]
XMPP: [e-mail]
HTTP://www.sidn.nl/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJR3o79AAoJEDqHrM883AgnAlkH/2f3LWHVziH0F6epKc35MTY1
H8hsolkp0Y859JmnuQ5m6koy+YKV20DzCtSjZsBMCafkiBfXeIMeW7o33XWurHKG
pPku6iP5rf3BZCAi9kZ25z+jmThnU0+r2fVZKTyh5jpTnzI65HtKTknqGOyAlPC7
sTeqAXAn5Vb4RrxIUyCl9w4BkalRp7LbN7m5L81B3EdfGDm9L6myLkPi/pkbFG7P
k7fJK9+Kl9yCUsQdfaFSvE+cuNtRASSoAKhDvYRIOB726ylF5u5xNP89ROr8XyC8
rgniyyiL4KUjQ7jABdmppGw4aMbKJRRA5yfIGt6MEWCpgGv3rK6DODWi402zeNY=
=fxKD
-----END PGP SIGNATURE-----