>> i'd argue that if 194.in-addr.arpa is not registered a DLV registry and >> if in-addr.arpa is not itself signed, then the community of beneficiaries >> of 194's signedness is so small that this cannot be called an emergency. > > More and more people will setup their own trusted keys. We don't neeed DLV > for that.
i'm not sure we're transmissing on the same frequency. can we try that again? if more and more people set up their own trusted keys, then when more and more of those trusted keys roll over, then more and more of the people who have set up trusted keys will have to input replacement trust anchors, usually using "cut and paste" and eventually depending on unsecure e-mail on mailing lists as their cue to do so. draft-ietf-dnsext-trustupdate-timers-04.txt is the IETF's current best guess as to how this might be automated, and nobody (anywhere) thinks anymore than the root zone will be signed (ever), and so it'll be "every TLD for itself". in the context of the current discussion, in-addr.arpa is "like the root". > I'd rather see RIPE test their emergency key rollover procedure now, then > have them wait for a 'real' threat when people actually depend on its > secure status. i actually do love the way you're thinking, even though it's completely wrong. what we're likely to learn from a 194 key rollover event is (a) pretty much nobody had the trust anchor installed, (b) pretty much nobody who installed it will remember that they'd installed it, (c) pretty much no applications will break when the key rolls and the trust anchors don't, since nothing depends on it working, and (d) dnssec is still a solution in search of a problem (and a deployment plan). http://ietcom.oxfordjournals.org/cgi/content/abstract/E88-B/4/1326 has a full PDF available of the paper on DLV i published in IEICE last year. i've also given a presentation on DLV several times including USENIX LISA last year where they MP3'd it (http://www.usenix.org/event/lisa05/tech/mp3/vixie.mp3) and wrote about it in ;login: (volume 32 number 2 page 94). if dnssec needed to scale in its current form, we'd (http://www.isc.org/ops/dlv/) have heard about it. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
