On Apr 20, 2013, at 13:40, Paul Wouters wrote: > > Now I'm confused about what you would like to see. You wrote: > >> My response is that the CDS should not automatically cause a change to >> the DS, just marshall the data. >> I am pushing to rely on a second factor (the security over the c&c >> channel to the parent) to verify the request. >> I'm not comfortable with in-band scraping. > > I guess we could add language that states the intention of the child.
First, some use cases, written from the child operator's perspective: I want to add a DS record for a key that is not yet published. I want to delete a DS record for a key that has never been published. (*) I want to add a DS recrord for a key that is in use. I want to delete a DS record for a key that is in use. I want to add DS records for hashes not previously supported. I want to add DS records for hashes I am moving away from. ...and others in the "I want to add/delete" category. > If the CDS is signed by the KSK, the child agrees for the parent to update > the DS. > > If the CDS is signed by the ZSK, the child is just "marshalling the data" and > the > parent should look elsewhere for the authentication of that data. We really do need to drop the KSK and ZSK terminology because there are Common Signing Keys coming "back" in vogue. The factor is whether a key is a SEP or not. Recall that in the validation and signing engines, the SEP bit is not significant, it is there for the convenience of key management tools. What if I use a key in the role of a ZSK and then decide to convert it into an SEP? Today I can do this by just adding a DS record for the key. But if we start with rules on what roles can sign what record sets and in what ways, I'd have to flip the SEP bit - which then changes the identity of the key. (Same issue as in revoking keys a la RFC 5011.) > This still leaves open that a compromised KSK can lead to parent DS > changes, but I don't see a way around that without sacrifcing the > requirement that fully automated KSK rollovers using just DNSSEC data > in the zone should be possible. I think you can close that vulnerability by relying on "some other factor" in the key change process. Where is the requirement for "fully automated KSK rollovers using just DNSSEC data" come from? I don't mean a document citation, I mean the basis in reality? I can see the allure but I don't think it is wise. What I have in mind - and this isn't a "has to be this way" - is this kind of a specification. 1. A definition of the CDS record set that conveys the hashes from the child to the parent or a means for the parent to get keys if they so desire. What I don't have a solution for is supporting DS records of unpublished DNSKEYs in zones were the parent wants the keys. Included would be ways to specify hash functions that the parent hasn't implemented, etc., i.e., the ability for the child to be totally autonomous in the management of their zone. I am not overly aggressive parental actions, but there should be support for "true" delegations of authority. 2. From the child side, when a child publishes CDS record(s), a statement of what that means. In some sense it will be dependent on step 1. My preference is that a CDS record is an incremental change request of the parent, others want the set to be the desired state at the end of all operations. Either one is possible, my preference is just "that" at this point. (As far as what key signs the see my previous words.) What's to be left out of the "spec" and addressed in words is that the child might have to alert the parent. 3. Again from the child side, when does it withdraw the CDS record(s) (set). Could be that the child keeps it there until the parent held DS set matches (polling) or some other event happens. I'd default to a zone polling the parent over event driven because removal of records is the forgotten step in most operations. 4. From the parent, words on detection of the record(s) (set), words on how to perform the operations, and then a discussion on letting the child know. Here's where I see a lot of pitfalls in IETF document processing. If the document specifies one way to do detection or another, this will be burned into the RFC. From then on, all those following the RFC would have to deal with compliance questions...so even if I just want to make use of what is in part 1, I'll have to address why part 4 is or is not applicable. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses.
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
