Tony,

Nice post.  This reminds me of some thinking along these lines I did several years ago, which was based on the analogy of how stock market prices are published.  (Things have shifted quite a bit with the availability of real-time feeds on the Internet, so give me some latitude here.)

In the "old days" most people would get closing stock market prices from their newspaper.  Newspapers were not primary authorities, of course, but they were trusted publishers.  Each person could choose which paper to read, and if a particular paper were to screw up the publication of the stock market page, readers would have quickly switched to another publisher.

The application of that scheme to the present issue is to allow multiple "publishers" sign and promulgate the root key.  For automated operation it's best if they all use the same publication format.  Each user could then choose any of the available publishers.  If a publisher were to publish the wrong information, it be evident very quickly and the consequences would be relatively painful.

If someone is paranoid about the possibility of being spoofed, he can compare the results from multiple publishers and/or rotate among the many publishers.  But there's no need for the publishers to coordinate among themselves, except for the standard format, and there's no need for a formal quorum of witnesses.  (I guess if someone wanted to advocate a best practice of using a quorum of witnesses, that's ok with me, but I view that as an added layer, not necessarily required.)

Steve



On Apr 19, 2013, at 4:41 PM, Tony Finch <dot <at> dotat.at> wrote:

> 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  <dot <at> dotat.at>  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
> DNSOP <at> ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop