For the last couple of years, the most common attack vector against the DNS system is the attack against the registrar. Either the attack is on the software itself using weaknesses in the code that could inject DNS changes into the TLD registry, or social engineering the registrar support systems and the attacker receives credentials that in turn allows the attacker to perform malicious changes in DNS. DNSSEC is the common security mechanism that protects the DNS protocol, but by using the registrar attack, any changes will result in a proper working DNS delegation.

To protect against this type of attack, the common method is to regularly perform security audits on the code and to implement better routines for allowing any changes and protecting the customers. However, what is quite new is for TLD registries to offer the registrants a “registry lock” protection. What this registry lock mechanism protects is any unwanted changes for a domain. These types of locks are often implemented in various variants, and often uses a lock in the registry effectively stopping any changes coming from the registrar. The method of locking and unlocking a domain is not common between registries at all, and it is almost without exception a completely manual process where the registrant can lock and unlock their domain after voice calls (with callbacks validation), SMS, e-mail with PGP or any other “secure” method, allowing only the right domain name holder to perform a change. It does not use EPP, or any other standardised protocol, and also often bypasses the registrar.

Registrars that want to offer registry lock to their customers will find themselves in an awkward position, where none of their TLDs use the same method. So the manual interaction needed for handling this is very expensive and could also cause unwanted effects or costs.

In the long run the TLD registry businesses must harmonise the way they implement the registry lock functionality. Harmonising a technical model such as this often leads to a standardisation effort. The protocol commonly used for provisioning changes from the registrar to the registry is EPP. Although the weakness does not lie in the EPP protocol itself, it is easy to conclude that any standardisation effort should involve changes to the EPP protocol.

18 months ago I wrote an internet draft outlining the problems of doing this in EPP. In this document I propose that the registrant can publish a token or key in the TLD registry that becomes the “registry lock”. Having this registry lock in place, any changes coming from the registrar must use this key. It could be done by the registrant signing the change (or providing a one-time password), and just having the registrar to forward the signed EPP message to the registry. The registry then validates the change, comparing it with the key that is the registry lock, and if it validates—performs the change.

Using this model, it would make the registry-registrar-registrant (RRR) model intact. It would require non-trivial changes to the EPP protocol though. And it would make it harder for the registrant to perform any changes (but remember, it is already quite hard for the registrar to do this using the registry lock model we have today)—especially if there is lack of tools. But by standardising an effort like this, tools for the registrant would be readily available.

There is a downside to this. Soon after I published this draft, I was notified by Verisign that they have patented this already, with two different patents. “Shared Registration System Multi-Factor Authentication” as published in the US as US 20100325723 and in Europe as EP2443790A1, and “Shared Registration Multi-Factor Authentication Tokens” is published in US as US 20120174198 and in Europe as EP2659645A1.

On the upside I strongly believe that there are other mechanisms that could be used. The Verisign patents could be broad enough to cover any change that only makes use of changes to the EPP protocol. But there is the possibility to use an out-of-band lookup—and since we are in the DNS problem space, perhaps use DNS with DNSSEC. Maybe we can use tokens published in DNS for implementing two factor authentication to EPP?

With this text, I hope to raise the interest in solving the registry lock problem. How to get started? TLD registries that already have implemented registry lock should have an interest to remove the manual labour of doing the work they do today. The hard part of this is to get registrars to implement changes to their registrar systems. But I am an optimist, and I believe that we can make this happen.