DNS Security, Part VII: Blockchain-based Name Systems and Transparency

Posted by ekr on 07 Feb 2022

DNS security, I just can't quit you (see parts I, II, III, IV, V, VI). In Part VI I talked about blockchain-based name systems, but I forgot to mention one aspect: defense against surreptitious changes. For instance, suppose the attacker doesn't want to take over example.com but just wants to intercept TLS connections to it; for obvious reasons, they don't want it to be common knowledge that that's happening. One could argue that blockchain-based systems makes that kind of thing harder than with conventional systems (DNS + PKI), but I don't think that's really true, for reasons laid out in this post.

The naive version of a blockchain-based DNS system mechanically and inflexibly enforces some specific policy (typically first-come-first-served). This doesn't do a good job of accommodating a number of real-world use cases such as (1) people losing their cryptographic keys or (2) people registering domain names corresponding to someone else's trademark. In the DNS, these are relatively easily handled: if you lose your DNSSEC key, you can just update it as long as you can authenticate to your registrar; if you lose your password, you can probably recover it; if someone registrars your trademark, there's the UDRP. In blockchain-based systems, however, these mechanisms are not available, because everything ties mechanically back to your private key.^[1]

It's of course possible to build a flexible system which incorporates some element of discretion in these situations. The Ethereum Name Service (ENS) sort of contemplates this, though they also don't seem to have defined any real policies for how to handle these cases beyond trusting the system operators. It's not clear how this is better than the existing system of DNS governance: I know ICANN isn't particularly popular, but they do have fairly clear policies for how to handle exceptional cases (not that these cases are actually that exceptional).

The problem is that as soon as you allow this kind of discretion^[2] into the system, it undercuts the basic value proposition of having the names on the ledger: if that discretion can be exercised for legitimate reasons it can also be exercised for illegitimate reasons (e.g., to steal your domain name). The question then becomes whether it's possible to detect and contain that kind of misuse.

How to Transfer Domains #

Before we ask about how to handle these exceptional cases, we first need to look at how you handle the normal case of name transfer. As I mentioned earlier, registration is done just by storing a name/public key pair on the ledger, with the rule being that the first registrant wins. Suppose Alice has registered example.com and wants to transfer it to Bob, what now?

The obvious way to handle this is for Alice to use her key to digitally sign a record transferring the domain and insert it into the ledger. This can just be the same record that Bob would have used to register the domain if he had been first, but signed by Alice. In this case, then, what it means to own the domain is to have an unbroken chain of signatures starting from the original registrant.^[3] Note that you need to bake this rule about transfers into the system early on; otherwise, there is a risk that some relying parties (i.e., clients) won't have been updated and so won't accept the transfer, which is an obvious interoperability problem.

Involuntary Transfers #

From a technical perspective, involuntary transfers are just a natural extension of voluntary transfers. The way this works is that you have some set of keys which can authorize transfers for domains they don't actually own (once again, this has to be baked into the system from quite early on, at least at some level). So, if Bob holds the trademark on "Example", and Alice registers example.com then there might be some (unspecified) procedure that Bob goes through to demonstrate that he really should own example.com and if he prevails, then whoever holds those keys would create a new record on the ledger reassigning example.com to Bob's public key I'm being vague about the details here because AFAICT none of the existing systems seem to have developed any specific procedures along these lines, so we're just talking in the abstract. Note that you can use a similar technique to handle lost keys; these aren't technically involuntary but from a technical perspective, it's basically the same thing because your key is your identity and the original key isn't being used to make the transfer.

Obviously, you can make the precise technical conditions under which a transfer is valid as complicated as you want. For instance, you can require multiple keys to sign (or use a threshold signature scheme), require multiple signatures on different days, whatever. You can even require the record to contain some description of what happens. But at the end of the day the story is the same: there's some process that takes place outside of the ledger machinery that leads some group of people to conclude that a transfer is warranted and then they effectuate the transfer on the ledger.

The key point, however, is that the transfer itself has to be recorded on the ledger in order to take effect. This makes it difficult to surreptitiously transfer a domain name, because everything that happens is public.^[4]

DNS and the WebPKI #

Let's compare this to the situation with DNS. As we saw earlier, because it's a hierarchical system, nothing stops .com from lying about who owns example.com. It can even serve correct records to some people and bogus records^[5] to others (a "split view"). The same thing is true for the WebPKI: a CA can issue a certificate for example.com to the attacker who can use it to impersonate the real owner of example.com, and it's mostly invisible to relying parties. On first glance, this looks like a real advantage for these ledger-based systems, where this misbehavior is inherently visible to relying parties and to everyone else (whether they know enough to act on it is another question). However, I don't think that's really true, because it's possible to add transparency onto these systems.

Let's start with the WebPKI piece. It's certainly true that surreptitious misissuance is possible and the purpose of Certificate Transparency (CT) is to detect just this kind of misissuance. Briefly, CT is a system of append-only ledgers designed to ensure that every valid WebPKI cert is visible on the ledger. This makes it possible to check the ledger for suspicious certificate issuance. The technical details here are a little complicated, in part because CT was created after the WebPKI was already in wide use, but as a general matter the visibility guarantees are pretty similar to those that a ledger base name system provides.^[6] Note that one nice feature of this kind of system—unlike a ledger-based system—is that you can roll it out gradually because processing the transparency data is not required to accept the certificate.

This brings us to the question of the DNS itself. Here too, it's possible to think of adding some after the fact transparency mechanism to prevent parents generating bogus data. At one point there was some interest in "CT for DNSSEC", but apparently not enough to get it off the ground. I wasn't deeply involved in that discussion, but IIRC there were concerns about log scaling and in particular about DoS attacks/spamming the logs. These are real issues but they primarily arise because of the notion that the DNS has to be free(-ish). In the existing ledger systems you just deal with this by charging people (in some cases quite a bit) to store transactions on the log). If you were willing to do that, the problem seems like it could be simplified considerably.

Detecting and Handling Misbehavior #

You may have noticed that I've sort of skipped a step here: all of these mechanisms just record every action, but that doesn't tell you what to do about it, or necessarily even how to detect it. The basic idea here is that one can scan the ledger/CT log and look for transactions which look fishy. There are a number of ways this can happen:

• People can scan looking for their own names.
• People can register for some service that scans looking for names for all of their clients.
• You can just generally scan for suspicious-looking stuff (e.g., why did Google's name just get reassigned?)

This is probably somewhat easier for the blockchain-based systems because the exceptional cases are going to be rare and are clearly marked, so you can just ignore all the others,^[7] but it's certainly possible with a system like CT (CT calls these services "monitors"), and there have already been a number of cases where CT has detected various kinds of misbehavior, including certificates which should never have been issued..

Summary #

None of this is to say that it's not useful to have some transparency mechanism to detect misbehavior, and I agree that it's a nice property of ledger based systems that that's built into the system. My point here, however, is it's not really much an inherent advantage over our current systems because we can add transparency mechanisms to them. We already have such a mechanism built on top of the WebPKI in the form of Certificate Transparency and if we really wanted one for DNSSEC, we could almost certainly find a way to build one. More importantly, we can get these benefits incrementally: preserving the validity of all of our current names while adding transparency on top, which seems a lot easier than starting from scratch with an incompatible system.