On 20 Apr 2013, at 17:09, Paul Wouters <[email protected]> wrote: > Imagine your previous DSL router was doing DNSSEC with the previous root key. > Your current DSL modem dies, and you power on your old one. What will happen?
You go to the nearest shop and spend $20-30 on new CPE because the old one(s) are broken. :-) > Now repeat, and say that the SHA2 family was broken and SHA4 is now the > standard. Your old modem talks SHA2 only. > > I don't think we as a group have ignored this problem - we have just not > found a proper solution yet. I am not sure there needs to be a proper solution. Or that a one size fits all solution is even possible or desirable. This topic is largely a matter of implementation and/or local policy after all. Some generalised motherhood and apple pie guidelines/advice would probably be enough: don't hard-wire the current root KSK as a trust anchor; always design your stuff with the assumption the root KSK must change from time to time; provide some out of band means for your stuff to recover from a missed key rollover; consider designing your firmware to handle changes to the root KSK in a similar way to how it deals with a regular software update, etc. Maybe a document along these lines is needed? We can be fairly certain that the URLs IANA publishes for the root TA are not going to change. Though perhaps that needs to be explicitly stated by someone. So it should be a simple matter of programming to provide some way to slurp that stuff, check it and update the locally held TA. Something comparable to unbound-anchor could do the job. Suppliers of CPE -- vendor, ISP -- might even provide their own copy of that repository in whatever format they choose so their stuff can contact the mothership at regular intervals or after a hard reset. For bonus points that update mechanism could use a secure out of band channel by (say) embedding a cert or public key tied to the IP address of the supplier's repository into the firmware. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
