This is a followup to my comments on ICANN's root zone KSK rollover consultation. In the last section, responding to question 7 about "other considerations", I made a number of suggestions for improvements to the trust anchor publication mechanism. http://forum.icann.org/lists/comments-root-zone-consultation-08mar13/msg00013.html
The most important is the last paragraph: : I understand that ICANN would like to include third party signatures on : the root trust anchor publication web site. This would be a very good : thing, since it would allow out-of-band update software to require a : quorum of valid signatures instead of just one. This improves : security, since compromise of a single key does not compromise the : whole process. It improves robustness, since signing keys will be able : to change without breaking existing software that uses those keys for : validation, so long as a quorum of old-enough keys remain in use. Basically I want a machine-verifiable version of this: http://dns.icann.org/ksk/ds19036/ The risk is that the key used to sign the KSK, and the CA used to authenticate the key, are both single points of failure. There is no single point of failure in the quorum-of-witnesses scheme. The keys can all be simply self-signed since individual keys are only slightly trusted; the trust comes from agreement between several independent signatures. Here are some more suggestions. Related to the previous risk, there are some operational and organizational single points of failure in the publication web site - for instance it is vulnerable to DNS and BGP screwups. This can be mitigated using a system of mirror sites. A more serious risk: the current publication scheme is vulnerable to replay attacks. If the KSK is compromised, an attacker might be able to force a victim to download and trust an old version of the trust anchor publication document. To mitigate this the trust anchor document (or its signatures) should have an explicit lifetime. Validators should refresh their copy of the trust anchor document before it expires. They should remember the most recent version they have seen and refuse to downgrade to an old version. They should probably also keep track of which DNSKEYs have been retired and refuse to trust them forever more. There is perhaps an opportunity to improve on RFC 5011, in particular to reduce the time to recover from a compromised KSK without pre-publishing standby keys. If a validator sees a change in the set of KSKs, it fetches and verifies the trust anchor document in order to authenticate the change. This can lead to the validator immediately trusting the new KSK and distrusting the old one. A rollover should take effect globally in roughly the TTL of the DNSKEY RRset - two days for the root at the moment. The old KSK has to remain actively used for signing the DNSKEY RRset during the rollover for a couple of reasons: first, you seriously do not want an attacker to be able to use a bogus DNSKEY RRset to force a validator to attempt a trust anchor update; second, it's desirable to let the validator continue using its existing trust anchor during the update process since that will be relatively slow. I think it makes sense to distinguish between a trust anchor refresh / update, which occurs during continuous operation of the validator, and which is only triggered by the age of the trust anchor document or by a validated change in the DNSKEY KSKs; and trust anchor bootstrap, which occurs when the validator has been offline long enough that its existing trust anchors do not work. In normal operation, failure to validate the root should be treated as an attack or a severely broken local network, and the right reaction is not to attempt an update. Bootstrapping is relatively risky and should only occur when the system is started or wakes up after a long sleep. Tony. -- f.anthony.n.finch <[email protected]> http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
