> On Nov 16, 2016, at 1:56 AM, Mikael Abrahamsson <swm...@swm.pp.se> wrote: > > So if it's manufactured the day before a new key is publically released, when > is the key material it has built in no longer viable to have successful > DNSSEC validation?
Since we haven't done a root KSK roll yet, a general answer to that question isn't possible. But for the upcoming KSK roll, barring any extremely low-probability events, the DS record parameters for the next KSK will be published in the root-anchors.xml file (https://data.iana.org/root-anchors/root-anchors.xml) in early February, 2017, and the actual rollover event (when the new key begins signing the root zone DNSKEY set and the old key no longer signs) occurs on October 11, 2017. That's a nine-month window for the worst-case scenario you referred to of a box being manufactured right before the new key. During those nine months you'll see ICANN folks out and about repeatedly telling anyone who'll listen about the new key. In parallel, we're also reaching out to developers and integrators to get the new key in their pipeline. We have fewer contacts with manufacturers of embedded systems, so if you know any hardware manufacturers who care about the root KSK, please contact me privately so we can contact them. Another way to deal with this issue is for devices to bootstrap the root trust anchor from the aforementioned root-anchors.xml file, which is the canonical listing of current root zone trust anchors. That file is signed by a cert that chains up to the ICANN CA, which currently expires in December, 2029. I realize this suggestion only moves the problem to another level: a device needs to trust the ICANN CA, and eventually that key will roll, as well. But 2029 is a long time away (at the moment). In my opinion, in a perfect world, any software or device with the root trust anchor configured by the developer/integrator/manufacturer would check the root-anchors file upon startup and then use RFC5011 to stay current. Or, as an alternative to RFC5011, just periodically re-check the root-anchors.xml file. Paul Hoffman of ICANN and Jakob Schlyter of Kirei have written a tool called "get_trust_anchor.py" that uses base Python (no additional libraries required) and needs only openssl to retrieve and validate root-anchors.xml; see https://github.com/kirei/dnssec-ta-tools. For background, see Paul's recent DNS-OARC presentation: https://indico.dns-oarc.net/event/25/session/2/contribution/21/material/slides/0.pdf. Matt -- Matt Larson VP of Research, Office of the CTO, ICANN _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
