Key Transparency for DNSSEC?

At the recent IETF meeting in Toronto, there was an interesting discussion in the trans working group on DNSSEC certificate transparency, and there is a (very) preliminary IETF draft (that needs a lot more work):

http://tools.ietf.org/html/draft-zhang-ct-dnssec-trans

This isn’t a new topic. It has been talked about off and on for a number of years. The first time I ran across this was on the “The Right Key” email list in 2012 when measures to detect and counter fraudulently issued PKI (X.509) certificates were being proposed. This ultimately led to the creation of the trans working group, whose main goal is to produce and standardize a transparency system for X.509 certificates, based on the mechanism described in RFC 6962.

Does DNSSEC need a similar transparency system? For X.509 certificates, the threats are well known and documented (I wrote about them a bit in an earlier blog article) - any of the many root certificate authorities, or their intermediates, are capable of issuing a certificate for anyone on the Internet, and it is virtually impossible to know for sure if a fraudulent certificate has been issued. A central, cryptographically verifiable audit log of issued certificates might be able to address this issue (assuming that all CAs participated in it, which is by no means a certain proposition).

For DNSSEC it isn’t obvious that a similar mechanism is needed, and whenever this topic comes up, there is a lot of head scratching and bewildered looks from DNS engineers wondering what the possible threat model is. I must admit, I didn’t foresee the possible attack, until it was described to me in this exchange on The Right Key list by Paul Hoffman and Ben Laurie:

http://www.ietf.org/mail-archive/web/therightkey/current/msg00470.html

If you’d like to read the entire email thread, it starts here:

http://www.ietf.org/mail-archive/web/therightkey/current/msg00452.html

In DNSSEC, the keys for a zone are vouched for by a single parent zone (by means of a signed DS record corresponding to the child’s keys). A zone operator can query the parent’s DS records himself to verify that the correct DS key is being returned. However, what the zone operator cannot do, is to verify that the parent domain is not selectively responding with false DS records to queries from a targeted set of other victims.

To quote from that thread,

“For example, assume the domain name example.newtld. The owner of example has put DS record A in the newtld zone. If the owner of newtld goes rogue and shows DS record B to a limited number of requests (such as to a particular geographic region or set of network addresses), the party with the private key associated with B can spoof example, and the owner of example would not know unless he could see B.”

(Note: for this attack to be useful, in addition to showing the fake DS records, newtld would have to show fake NS records and possibly glue records to redirect the victim to alternate DNS servers with the corresponding DNSKEY records)

If the parent zone is doing this on wide scale, they are likely to get caught and face action. But highly targeted attacks will be very hard to detect. Are these scenarios far fetched? Most DNS top level domains are run by reputable organizations and would likely not risk engaging in such security shenanigans. However, even if we assume they are completely forthright, they are vulnerable to “compelled” attacks by government agencies. In April 2010, Chris Soghoian and Sid Stamm in a paper (“Certified Lies: Detecting and Defeating Government Interception Attacks against SSL”) describe such attacks against SSL/TLS certificates with evidence suggesting that they are actually in use. In light of Edward Snowden’s NSA revelations, these kinds of compelled attacks (legally compelled or otherwise) are more likely than ever. DNSSEC keys and delegation signer records are just as vulnerable to them.

The title of the IETF draft mentioned at the beginning of this article is “Certificate Transparency for DNSSEC”, which is probably a misnomer. The data that would be most valuable to enter into a DNSSEC transparency log are not certificates, but secure entry point keys for zones (e.g. DS records and/or Key Signing Keys). So a more appropriate name might be “Key Transparency for DNSSEC”. DNS zones can contain certificates, or hashes corresponding to certificates (e.g. TLSA, CERT, etc records), however there are many other record types that might contain cryptographic keying material (SSHFP, IPSECKEY, and proposals for others in the pipeline). And why not have an audit log for more mundane non-crypto records too, eg. name to address mappings? Individually logging all of these data types for every zone will likely prove to be an infeasible task.

If we limit the scope of the transparency log to DS records, there are still some very significant technical challenges that need to be solved. One is scalability to the world wide DNS. The Certificate Transparency log is being implemented as an append-only log with a Merkle tree, and a DNSSEC log will likely follow the same approach. Quoting RFC 6962:

“The append-only property of each log is technically achieved using Merkle Trees, which can be used to show that any particular version of the log is a superset of any particular previous version. Likewise, Merkle Trees avoid the need to blindly trust logs: if a log attempts to show different things to different people, this can be efficiently detected by comparing tree roots and consistency proofs. Similarly, other misbehaviors of any log (e.g., issuing signed timestamps for certificates they then don’t log) can be efficiently detected and proved to the world at large.”

Even though DNSSEC is still in a fledgeling state of deployment, we need to design a mechanism that can scale to the entire DNS system and accommodate the expected churn of zone keys (e.g. due to key rollovers etc). A single centralized log may not be able to do this, and alternative models may need to be considered (e.g. limiting the depth of zones that the log will hold; implementing a hierarchy of logs, etc).

Another problem is that a rogue or compelled parent zone can not only return fake DS records, but could also answer authoritatively for names inside the child zone without any referrals to the child zone (a fake in-zone answer). This is harder to protect against, but I can think of a number of possible defenses. At the level of TLDs (top level domains) one possible protection might be to have DNS resolvers treat them as delegation-only and reject all subdomain answers that aren’t referrals. Another (probably more promising) approach is for resolvers to employ a query-name minimization algorithm that only reveals the needed labels of the query name to authoritative DNS servers as they traverse the delegation hierarchy. In fact, there is active work going on in the DNS engineering community on such qname minimization schemes and other privacy enhancing extensions to the DNS.

A DNSSEC transparency log, if deployed, could be useful as an audit channel to periodically detect attacks, and for forensics. Performing checks of the log inline with the DNS resolution process may not be practical because of the probably high performance penalty (with the currently proposed log structure), which means attacks could not be detected in real time.

So is it really worth deploying such a system? I’m not yet sure. In the end, DNS is a hierarchical system, and there is always the possibility of being victimized by your parent zone either by error, incompetence, malice, or coercion. Even if we deploy centralized sets of transparency logs, we’d have to them think about how to prevent them from being compromised or co-erced. There are decentralized (non-hierarchical) naming systems out there, like gnunet, namecoin, etc. But they have the usual problem that they are only really used by a small group of very technically savvy users. We should probably take a more serious look at them. But I think the compelled attack is a very real threat, and it’s probably worth some serious thought about how to deploy practical defenses against it in the global DNS.

The IETF recently published RFC 7258, declaring that pervasive monitoring is an attack for which all IETF protocols should have technical countermeasures. It may also be time for the IETF to standardize mitigations for highly targeted attacks.