-----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: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschu...@sidn.nl XMPP: antoin.verschu...@jabber.sidn.nl 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----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop