Subject: [DNSOP] RISKS and mitigations for draft-jabley-dnssec-trust-anchor

From: Tony Finch <[email-masked]>
Date: Fri, 19 Apr 2013 21:41:22 +0100

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-masked]>  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.

---

From: Steve Crocker <[email-masked]>
Date: Fri, 19 Apr 2013 16:54:36 -0400

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 <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Tony Finch <[email-masked]>
Date: Fri, 19 Apr 2013 22:17:55 +0100

Steve Crocker <[email-masked]> wrote:
> Nice post.

Thanks!

> 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.)

I think robustness is at least as important as paranoia.

I have in mind something like DNS root server operations. It's fine if
D-root renumbers, because a resolver still has 12 other servers it can use
to bootstrap. Similarly, a validator should have several witness keys it
can use to bootstrap, so that it still works after keys are retired.

If you know multiple witness keys then it becomes fairly easy to require a
quorum rather than trust just one of them. The advantage is that you don't
have to make an active choice about who to trust or who not to trust,
which is an enormous usability bonus for mass-market validation.

I'm unsure about the logistics. There are lots of plausible options. How
does each witness decide they are signing the right thing? It would be
nice (efficient) if a client could download a bundle of signatures from
any mirror site, but does that introduce too much coupling? Maybe the
witnesses could cross-mirror each other. But I though mirror sites might
be provided by big CDN services, and witnesses might be interested parties
such as registries, registrars, DNS software vendors, etc. usw. Your
newspaper analogy is another useful model to consider.

Tony.

---

From: Paul Wouters <[email-masked]>
Date: Sat, 20 Apr 2013 12:09:56 -0400 (EDT)

> 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 t…

You have solved the easy human problem. Now do the same for fully
automated computers that are turned on after 10 years.

There is currently one publisher (ICANN pem bundle plus static web page
with certs signed by particular CA). Will that page be there in 10 years?
Where will the other publications be?

A few humans can figure this thing out easilly, and adapt. The problem
of rolling the root key is automation. 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?

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. Rolling the root key now will be pretty
meaningless as a test for deployment issues in the future. And if the
root zone operator wants to test their procedures, they can do so in a
lab.

Paul

---

From: Joe Abley <[email-masked]>
Date: Sat, 20 Apr 2013 12:16:12 -0400

> Where will the other publications be?

The pragmatic answer to this is that ICANN is under contract to support that mechanism, and any successor organisation carrying out the IANA Functions Contract would no doubt inherit the same requirement (changes tending to involve wide technical consultation, and the likelihood of people saying "yeah, that's a great idea, change it" seems slim). See also the ftp URLs for the root hints file, whose locations haven't changed since they were first published there many years ago, before ICANN existed (or before URLs existed, in fact).

I think we can assume that the data.iana.org/root-anchor/ URLs are baked in at layer-9.

Joe

---

From: Jim Reid <[email-masked]>
Date: Sat, 20 Apr 2013 17:59:06 +0100

On 20 Apr 2013, at 17:09, Paul Wouters <[email-masked]> 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. :-)

> 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.

---

From: Tony Finch <[email-masked]>
Date: Sat, 20 Apr 2013 18:09:43 +0100

> automated computers that are turned on after 10 years.

You can be fairly profligate with witness signatures, since they are not going to be downloaded and checked very often, nor when you need a very quick answer. Witness keys should stay in use indefinitely, until they are broken cryptographically or operationally. They should have a good diversity of algorithms and operational practices so they don't all break at once. Over time new witnesses will be added to support newer algorithms. Weaker witnesses will keep signing, to support old code, though new code might only use newer witnesses.

So when a very old validator starts up it should still have a decent chance of being able to get and verify the current trust anchor document. If it turns out that the root KSK uses an unsupported algorithm, the validator does at least know for certain that it has no choice but to go insecure.

Tony.