I was thinking a bit about the CDS draft, not specifically it, but the problem it is addressing.
This message was spurred by a comment that "in a key emergency where the private key is exposed" the only way to go forward is to completely stop DNSSEC and then do a re-start from state "0." The rationale for that was, if I had your private key I could sign the DNSKEY set, add keys at will and generate signatures into the future. Thus "forward security" would always be suspect. I don't entirely agree with that. After thinking some, the reason is that any new key in the DNS is, yes, signed by the old key, but also relies on the presence of a "sympathenic" DS record at the parent. This represents a "two factor" approach to authenticating the new key - signed by the current zone administrator and also registered with the parent through some other security barrier. For example, the new key is signed by an old key over the DNSKEY set. And, assuming EPP, then the key has to come through the registration system's security too. Yes, you can game either and maybe even both injection paths, but to be effective you have to game both. Simply put, with just basic security hygiene, it's much harder to game both than to game either one. From this, one of the important ideas is "two factor" authentication. "Three factor" might be even more beneficial, but let's shoot for two first. I think of the CDS proposal as having two components. One is a means to marshall the information from child to parent. The other is the way in which the data is transferred and handled. In concept I wholeheartedly support the former component. It's the latter component that gives me angina. (I.e., heart burn, but I was trying to avoid using heart twice in the same sentence in those ways.) The marshaling is very beneficial, it's much better than the current state of the art of cut-n-paste when the operator of the DNS is not the editor of the registry's contents. Even if the registry wants DNSKEY records, having an indication of the DS desire allows the registry to get the DNSKEY unless the desire is for an un-published DNSKEY's DS record. (Which does happen.) IMHO, I don't support adding DS records based on DNSKEY - I say this not to mean I believe it is wrong but I say it to mean that someone that believes this has to come up with someway to get the un-published DNSKEY from the child to parent to accommodate this OR declare it operationally forbidden (which is also acceptable). But when it comes to the "how" the data is transferred I have a lot of problems. First, the draft says that the CDS has to be signed by the KSK and not a ZSK. This is a problem to me because it's the first time an RRSIG over data is restricted to one kind of key or another. To me that's a precedent setter, and as such needs scrutiny. I understand that the requirement is because the KSK manager and the ZSK manager could be different (and are so for the root zone), but this is a change to the protocol in a way that hasn't been explored. I think that there's something to be learned from the two factor observation though. The most visible key management function where this plays a role is the root. But, it doesn't play a role because the root has no parent and thus no need to marshall the key. (In reality, the keys are marshaled via other means, out of band and play a role in the ICANN KSK ceremonies that happen 4 times a year.) In any other situation, the CDS ought to just be the marshaling and the RRSIG over it just authenticating that the record got from the child to the parent with integrity. The "out of band" environment that gets the parent to insert the DS has got to kick in to provide the second factor. Switching to another environment, the usual case of a registrant in an ICANN-SRM-style zone (shared registry model) using EPP and registrars, this can play out using the following (I switch here because I believe it is a model fot the split KSK ZSK key management system - if they exist other than the root). The new KSK is made and a CDS set is generated, signed, and published in the zone (omitting details on what is in the CDS for now). The key management function then alerts the registrar that there's a new DS needed. Today this is cut and paste and some say that registrars want customers to log in, see ads and then make the request. True or not, this doesn't have to change, just instead of cut and paste, there's a notification button to click. No polling, no looking, no pro-activeness needed by registrar. The second factor here is logging into the registrar portal. For registries that are willing or want to poll their registrants for CDS records, I'd caution that they might not be doing anyone a favor. If the KSK was exposed, then a forged CDS might pass as real and the registrant can loose control of the zone - because only one factor was involved and the one factor was gamed. I'll end this here. I know that CDS isn't at the foremost of minds now. There's no sense in a new draft to "compete" and we no longer have higher bandwidth workshops to go over these ideas. So maybe this will get some others thinking, and whether there's merit to "two factor" approaches to key changes. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
