I'm going to attempt to reply to a few messages in one. On Apr 22, 2013, at 16:15, Wes Hardaker wrote:
> There is nothing preventing a CDS record from doing both automated > marshaling and accept *or* just automated marshaling. I agree - in the sense that the "science behind it" allows for one marshaling mechanism to be used different ways. What I am leery of is that once an RFC is published saying "here's how you marshall it" and "here's how the data transfer works" the perception is that to "do" CDS at all you have to both use the record and do it that way. I speak from the experience of answering RFPs that ask for comments about compliance with a laundry list of RFCs. Buyers (RFP issuers) rarely show that they've read the RFCs by referencing only the applicable sections to the bid, and commonly an RFP writer will copy another RFP lock, stock and barrel when it comes to things like technical details. So, my "gating requirement" for the proposal is that the document does it's best to say "here's a good marshaling data structure" and separably "here's one way to use it" and preferably "here's another way to use it." This gating requirement is strictly a "how it is written" issue. And, I do think it is very important that the document is very clear so that when it comes to RFP or compliance or even audit time, legal/contractural issues are minimized. On Apr 22, 2013, at 16:19, Wes Hardaker wrote: > So, if it didn't change the what-must-sign it rule, would you come to > support it? It is not so simple. In one of my long-winded, rambling, stream of consciousness messages I suggested that there be no change to "how it is signed" and "how it is validated" rules. Special rules can be written for the provisioning system - an yes, the signer has to know to support that. I firmly believe that a validator (as described in 4033-4035) should have to be altered for the CDS proposal. But I have far less of an objection to having the element that accepts the CDS from the child having special rules - mostly because these do not exist today, there's no code to retrofit, no backwards compatibility concerns. On Apr 22, 2013, at 17:41, Doug Barton wrote: > On 04/22/2013 02:19 PM, Joe Abley wrote: >> >> On 2013-04-22, at 17:17, Wes Hardaker <[email protected]> wrote: >> >>> Wes Hardaker <[email protected]> writes: >>> >>> FYI: I meant to mention that there is a significant number of operators >>> that do actually protect their keys with different levels of protection >>> and keep their KSKs in a "better vault". >> >> That's interesting. Can you cite examples? >> >> The only example I know of is the root zone, which is weird and special for >> a variety of non-technical reasons. Last time I looked neither the BIND9 nor >> OpenDNSSEC toolchains supported offline-KSK operations without a lot of >> hackery. > > Various TLDs discussed their plans to take similar steps at various points in > the past. There is no reason to believe that other sites (particularly large > financials) wouldn't be doing the same. > > That said, I don't see any reason to introduce "ZSK can validate a CDS > record," and lots of reasons to require the KSK(s) to do so. If off-line KSK > users can't use CDS to do their thing, I'm sure they would consider that an > acceptable compromise. Back in the day, (meaning in the late 90's before the first workshops) we (Olafur, Brian, Russ and I) toyed with many ways to do DNSSEC. One was to have off-line keys like KSKs (well before we made the split in the workshops) and to have on-line keys like ZSKs and denote them with "key strength" bits. The idea was that we'd have a protected key for data that needed high assurance and a vulnerable key for data that needed convenience. We quickly realized that this was non-sense as "a chain is only as strong as it's weakest link." In normal operations it just doesn't make sense to split the key management. Now, Joe is right. The root zone is a special case. While "weird" is a flippant word to use here, it seriously deserves a different treatment - and the root zone gets that treatment. What I am saying is, if there are cases of someone thinking that it is worth the time to split KSK and ZSK, I'd urge them to reconsider. It's not terrible but it is over engineering. I'm not inclined to "optimize" for such an use case. I'm for choice in how to operate. But there are limits to what you can support. If the system is too invertebrate-ish, it won't provide any support and will just become a morass of useless tissue. On Apr 22, 2013, at 17:48, Warren Kumari wrote: > Um, I'm probably missing something obvious here, but you cannot use CDS to > enroll in DNSSEC. This means that you'll have to use the original out-of-band > system -- what if we extend Wes's radio buttons to include ZSK / KSK[0]? Ultimately, I'm still uncomfortable with anything that does not use the out-of-band mechanism. At the start of this thread was the question of "what if the secrecy of the KSK private key is lost? How do you go forward?" Conventional wisdom du jure is that the only "gotta do it" reason for a key change is just about that case. All the other reasons are more or less window dressing. (Yes, you could totally lose the private key, but then there's no way to roll out of it "in band.") I can't see how a reasonable approach can be made to work only in-band. Ever. Where reasonable means "has no gaping holes that might actually happen in operations." -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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
