On Sat, Jan 3, 2015 at 2:44 PM, Michael Sinatra <mich...@brokendns.net> wrote: > > > On 12/26/14 09:16, Michael Richardson wrote: >> Mark Andrews <ma...@isc.org> wrote: >> mcr> It's not a question of: "can we do this", but rather a question of: >> if >> mcr> we do it, then it needs to be done correctly, which means some test >> mcr> cases and test data, and this takes a non-zero amount of time. >> mcr> >> mcr> Could the effort be better spent elsewhere? >> >> > Additionally with DLV we also need to be able to validate which means >> > more than upgrading OpenSSL. It also means getting the ruby libraries >> > upgraded etc. >> >> Yes, I was trying to leave the underlying technical hurdles aside >> (because, I'm sure, when given the mandate, I can deal with them in short >> order) and focus on the political and testability hurdles and intentions for >> this list.. >> >> Given that DLV will be sunset'ed, are new algorithms important to this >> community? > > In a way, I don't really care. I think it's reasonable to sunset ISC > DLV in the way you have suggested. I (unlike many) don't have a strong > opinion about DLV other than it has worked for me at a time when > registrars would not or could not support DNSSEC. That's why it's the > first place I went when I found that my registrar couldn't/wouldn't > support algorithms 13 and 14. > > To respond more to the thread, while I have tested resolvers at being > able to validate ECDSA keys, it's hard to have *others* validate my > zone, unless I have a registrar who will take the proper DS records.
Just wanted to make sure that you'd seen Geoff Huston's ECDSA DNSSEC testing... https://labs.ripe.net/Members/gih/ecdsa-and-dnssec Also a PPT at: www.potaroo.net/presentations/2014-10-12-ecc.pptx Is mostly unrelated to the registrar question, but interesting to understand deployment, etc. W > So > my larger concern revolves around how we can reliably introduce new > algorithms, which is important to keep DNSSEC secure, when most > registrars don't support DNSSEC at all, and none so far seem to be > keeping up with the latest algs. (It's good to hear that GoDaddy will > be doing that; thanks for the info.) > > Thanks also for the info about PairNIC. I didn't realize they supported > DNSSEC--that's good to know. > > Final thought: There are two weak links in DNSSEC. One is the root key, > and the other is the registrars. If the root key gets messed up in some > way, everyone's validation basically fails. If the registrars don't > implement new algorithms, it's basically an algorithm downgrade for > everyone, even if the registries do implement all algorithms. I am NOT > trying to be a troll here, but the nice thing about DLV is that it used > an alternate mechanism to establish a chain of trust that didn't rely on > registrars or the root key. As Mark pointed out, that did force DLV > operators into a CA-type role, which may be less than desirable. > > Again, I think it's reasonable to sunset ISC DLV. But I do think we > should keep somewhere the idea of alternative validation mechanisms that > could be configured somewhat differently than DLV, i.e. as a backup to > the regular top-down validation mechanism. > > michael -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
