-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Dnsop,
On 10/04/2010 07:46 PM, Joe Abley wrote: > We've talked to DNS vendors and although I don't want to foreshadow > their timelines for making code or strategies available, I can tell > you that there is work underway to accommodate 5011 rollover, 5011 > rollover with a client that is disconnected over the transition > window, and day-zero trust anchor bootstrap. No show-stoppers have > been identified in the conversations I have seen. No doubt the > vendors concerned will describe their approach when they are ready. OK, so I have been contemplating a good way to 'ship DNSSEC' as a vendor. The current solutions are trust-history and the draft from the subject line. I have investigated and implemented them. So, we can ship a root TA (or additional key), under our license agreement (BSD license), to facilitate deployment. To implement it the config file needs a tweak by the user. It is not a 'default' today. The tool can output its builtin hardcoded key for inspection. The trust-history proposal has been described previously. The method with which we intend to use the https provided xml file is as follows. After that description I'll compare the two approaches. There is an add-on tool (unbound-anchor, available from svn) that contains the hardcoded keys. It runs before the daemon is started (i.e. at system boot). Initially it provides the key to start. Then it uses RFC5011-tracking. The main daemon then also uses RFC5011 tracking while in operation. If RFC5011-tracking fails because the system was not turned on, then the alternative update path is used, the xml file is fetched, verified, and used to re-instate RFC5011 tracking. The initial-key setup, this means trust anchor files do not exist; the hardcoded root-DS record (from TCR attestions) is tried first, and the certificate verified xml is tried after. To diminish load on iana. To protect the system as well as the iana service, its checks that the 30-days timer from 5011 has really passed before bothering the https server. This should keep the load for iana manageable, and also keep startup time fast (usually only a RFC5011 UDP transaction). (This is not as easy as it seems, in case of missing the ADDPEND announce, a todo item). Thus, it is a pretty simple tool that reads the RFC5011-state on disk (if any), probes DNS, and performs https update if necessary and then writes the updated (or wholly new) RFC5011-state back to disk. It implements a DNS-lookup for the website even while the root anchor is not available. Lots of options to override the cert, key, etc, and for manual checks to be performed if the tool 'fires'. The difficult issues for the cert-update tool, are how to exactly interface with RFC5011 state (state changes that it makes). And what to do when the certificate expires (current tool goes to bogus; thus devices will cease operation at 2028, which I find a bit ... not nice). And code if the root goes to insecure (I think I have this implemented correctly). Comparison of TH (trust history), CU (certificate update). * How long does that baked-in key last? TH: forever. CU: until certificate expires (2028 or so). * Security. TH: uses old KSKs. CU: that cert. TH: dnsop consensus against use of retired keys. CU: the problem is really moved to the certificate itself. * Deployment. TH, no movement. CU: prototype client I just wrote, https service works. * Load on the system: TH: load at rollover time, data in DNS. CU: tries to use DNS in first 30 days, probably peak http 30-days after the roll. * trustpath: TH: trust goes to the operator of the zone KSK. CU: depends on which of the various options that are listed that you choose. Several provide an independent trustpath; we use one that is an independent trust path (the SMIME key). * key rollover. TH: the KSK roll *is* the trust anchor roll. CU: the KSK roll is covered by another key, whose keyroll is not specified. A software-update process? If that is so, you would need to roll out a new certificate (lasting to 2038) within the next 10 years, to keep the system '20 years' ahead, a careful calculation of this sort seems wise. * Handle revocation-back-to-insecure. TH: yes. CU: yes. * Dependency on local clock. TH: yes, otherwise old keys could be abused. CU: yes, same, old keys or the cert expiry time can be triggered. My current implementation of the CU tool prohibits function before 20100715 (when the root was signed), to avoid a downgrade attack if the clock is set before that date. * Initial trust deposition. Both use a trusted software install, that includes the correct key to get things started. * Regular updates. Both use RFC5011 (DNS usage only). * If the machine was offline. TH: handles with key-signs-key data. CU: handles via certificate and https. * If the network cable was not connected for a year: basically out of scope. (i.e. script runs at boot time). Other vendors can speak for themselves, and I note a CSR signing request is available if they use their own certificates. Like Joe says, it looks okay, just have to get trust in the certificate processed, and engage with the port/distro maintainers about configuration and bootscripts. But if you have any comment, I would greatly appreciate it. Or hear other vendors' ideas. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyvEngACgkQkDLqNwOhpPjrhQCfe2Twqbe/wRgULkqdadfg/ZRZ PoYAoLO7ZqxKFMb2rTpgIbt3BSooAt+L =0c+x -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
